Español
English
Català
FrançaisQue una aplicació de Next.js funcioni a localhost no determina quin allotjament necessita. Cal comprovar el resultat de construcció i quines funcions espera executar quan arriba una petició. Una exportació estàtica lliura fitxers; una aplicació que necessita lògica de servidor requereix un servei capaç d’executar-la.
Aquest diagnòstic fa servir un exemple original amb l’assaig local acabat i la revisió independent aprovada. Permet comprovar l’artefacte abans de triar allotjament. No acredita un lliurament natiu de Next.js a Hostbrid, suport SSR, totes les funcions, autenticació ni bases de dades.
Si has creat l’aplicació amb v0 i la vols executar fora de Vercel, segueix la guia per allotjar una app de v0, que diferencia la sortida estàtica de Next.js de les funcions que necessiten Node.
Distingeix exportar fitxers d’executar una aplicació
La documentació oficial d’exportació estàtica descriu output: 'export': el build produeix els fitxers que publica un servidor estàtic. No és equivalent a output: 'standalone', que prepara una aplicació per executar-se amb Node.
La presència de Server Components per si sola no demostra que necessitis un servidor en cada petició. En una exportació compatible es poden executar durant el build i produir HTML. El que importa és si l’aplicació requereix informació o feina que no es pot resoldre durant aquella construcció.
Fes un inventari abans de canviar la configuració: rutes el conjunt de les quals no coneixes en construir, galetes de l’usuari, accions de servidor, handlers que llegeixen la petició, regeneració incremental i optimització d’imatges amb el loader predeterminat. La documentació oficial identifica restriccions concretes per a aquestes funcions. Desactivar-les per aconseguir un build correcte pot eliminar comportament necessari; un build que passa no demostra que l’aplicació conservi el que feia.
Una ruta exportada té el seu propi document
En una SPA habitual pot existir un únic HTML que el router interpreta al navegador. Una exportació de Next.js genera documents per ruta. Si totes les peticions es reescriuen indiscriminadament a la portada, /about pot respondre amb un 200 i mostrar la pàgina equivocada.
Una consulta real de publicació a cPanel descriu aquest símptoma en recarregar una ruta. La pregunta mostra la dificultat; les seves respostes no substitueixen la documentació actual ni una prova de la teva configuració.
Comprova com queden les rutes a la carpeta exportada. trailingSlash modifica la disposició dels fitxers: no copiïs regles d’un altre web sense mirar el resultat. Prova l’entrada directa, la navegació des d’una altra pàgina i la recàrrega. En cada cas verifica el contingut i la identitat de pàgina, a més del codi HTTP. Una ruta inexistent ha de continuar sent un error verificable, no una portada disfressada d’èxit.
Decideix quines rutes existeixen durant el build
Les rutes dinàmiques exportades necessiten paràmetres que permetin generar els documents durant la construcció. Si la teva aplicació descobreix identificadors nous només quan rep una petició, no n’hi ha prou amb afegir una llista inventada per silenciar l’error: has de decidir si pots regenerar i publicar el conjunt o si necessites una altra arquitectura.
L’exemple genera /notes/orbita/ i comprova que un slug desconegut retorna un 404 real. En retirar generateStaticParams() de la ruta dinàmica, el build va acabar amb codi 1 i l’error específic de Next.js que indica la incompatibilitat amb output: export. La instal·lació havia passat; un error de xarxa o de dependències no hauria comptat com aquell control.
Resultats de l’assaig local
L’assaig fixa Next.js 16.4.0, React 19.3.0, Node 22.23.3 i npm 10.9.9. Va generar tres documents diferents: portada, /about/ i /notes/orbita/. Se’n van comprovar els bytes per HTTP i sis casos de Chrome a 390 i 1280 píxels, DPR 2, amb entrada directa i recàrrega d’un document nou. El CSS, l’SVG i el JavaScript es van carregar; un comptador va passar de 0 a 1 en prémer i va tornar a 0 en recarregar. Aquest comptador només té estat en memòria: no demostra persistència.
El control negatiu va retornar els bytes exactes de la portada amb HTTP 200 en demanar /about/. El mateix verificador que acceptava la pàgina correcta va rebutjar aquella identitat incorrecta. Així es comprova un error que una revisió basada només en el codi HTTP hauria passat per alt.
La primera execució va fallar perquè el servidor local de l’assaig no descodificava una URL de chunk amb claudàtors. Es va corregir el servidor i es va completar una execució nova. Aquell error de l’assaig es conserva com a evidència; no demostra un defecte del producte d’allotjament.
Les proves locals identifiquen l’artefacte exportable i les seves restriccions. No avaluen la publicació del projecte a Hostbrid ni validen una aplicació que necessita un servidor. Abans de traslladar la teva aplicació, comprova per separat les funcions que fa servir i la identitat de les rutes a l’allotjament triat.
Si l’aplicació necessita un servidor Next.js en lloc de només fitxers, consulta la guia per allotjar Next.js en un VPS. Per comprovar un altre procés Node o Docker, revisa la guia de ports i estat i les capacitats reals del producte abans de contractar. Si tens un frontend amb un backend extern, inventaria aquell servei per separat: exportar el frontend no migra les seves dades ni les credencials.
Reprodueix la revisió comprovada
L’exemple original amb llicència MIT conté l’aplicació i l’assaig. Aquestes ordres fixen la revisió revisada. Necessites Node 22.23.3 amb npm 10.9.9 i Chrome a macOS; consulta el README i fes servir un directori nou per conservar l’evidència.
git clone https://github.com/ocentelles/hostbrid-example-next-static-export.git
cd hostbrid-example-next-static-export
git checkout 5033d51146fa992b1deb8c6080696ed3cc8da91d
node --version
node scripts/run-essay.mjs /tmp/my-next-export-evidence