Senarai Semak Produksi Next.js 16 Praktikal untuk Pemasangan Vercel

Next.js App Router merupakan satu anjakan paradigma yang signifikan berbanding Pages Router. Walaupun ia sangat berkuasa, model baharunya—terutamanya Server Components dan pengambilan data—memperkenalkan potensi isu baharu dalam persekitaran produksi. Di JRV Systems, kami telah memindahkan beberapa projek klien, dari laman e-dagang hingga ke papan pemuka dalaman, ke App Router. Pengalaman ini telah membantu kami membina satu proses pra-pemasangan yang boleh dipercayai.

Artikel ini adalah senarai semak produksi Next.js 16 dalaman kami, yang telah ditambah baik daripada sesi-sesi nyahpepijat dunia sebenar. Ia memberi tumpuan kepada aspek paling lazim dan berimpak tinggi yang kami dapati sering menyebabkan masalah selepas aplikasi disiarkan secara langsung di Vercel.

Server vs. Client Components: Bila Perlu Guna Yang Mana

Perubahan paling asas dalam App Router ialah model 'pelayan secara lalai' (server by default). Memahami konsep ini adalah langkah pertama untuk membina aplikasi yang efisien.

Server Components (Lalai) Komponen ini berjalan secara eksklusif di pelayan. Ia tidak boleh menggunakan hooks seperti useState atau useEffect dan tidak boleh mengendalikan acara pelayar seperti onClick.

Gunakannya untuk:

• Pengambilan data secara terus (contohnya, mengakses pangkalan data atau API peribadi).
• Mengelakkan dependensi besar daripada dimasukkan ke dalam bungkusan JavaScript sebelah klien. Contohnya, pustaka pemprosesan data atau pemformatan tarikh yang berat boleh dikekalkan di pelayan.
• Mengakses sumber pelayan sahaja seperti pembolehubah persekitaran atau sistem fail.

Client Components (Pilih masuk dengan 'use client') Untuk menjadikan komponen interaktif, anda mesti menambah arahan 'use client' di bahagian atas fail. Ini menandakan ia dan semua komponen anaknya sebagai kod sebelah klien.

Gunakannya untuk:

• Mengendalikan interaksi pengguna (onClick, onChange, dll.).
• Menguruskan state dengan hooks seperti useState, useReducer, dan useContext.
• Menggunakan API khusus pelayar seperti localStorage, window, atau Geolocation API.

Satu peraturan praktikal yang kami amalkan: mulakan setiap komponen sebagai Server Component. Hanya tambah 'use client' apabila anda benar-benar memerlukan interaktiviti atau API khusus pelayar. Pastikan Client Components anda sekecil dan sespesifik yang mungkin—anggap ia sebagai pulau interaktif di dalam halaman statik yang di-render oleh pelayan.

Memahami Tetapan Lalai Caching Baharu

Dalam Pages Router, anda mempunyai sempadan yang jelas dengan getServerSideProps (dinamik) dan getStaticProps (statik). App Router menyatukan ini di dalam API fetch natif, tetapi kelakuan lalainya sering menjadi punca kekeliruan.

Secara lalai, sebarang permintaan fetch dalam Server Component akan di-cache secara automatik tanpa had masa. Ini serupa dengan getStaticProps dan boleh menyebabkan pengguna melihat data lama jika anda tidak berhati-hati.

Untuk mengawal kelakuan ini, anda menggunakan opsyen di dalam panggilan fetch:

• Data Dinamik (seperti getServerSideProps): Untuk memastikan data diambil pada setiap permintaan, gunakan opsyen cache: 'no-store'. Ini penting untuk papan pemuka khusus pengguna atau maklumat masa nyata. fetch('https://api.example.com/data', { cache: 'no-store' });

• Data Disahkan Semula (seperti ISR): Untuk menyimpan data dalam cache bagi tempoh tertentu, gunakan opsyen next.revalidate. Nilainya adalah dalam saat. Ini bagus untuk kandungan yang dikemas kini secara berkala tetapi tidak berterusan, seperti blog atau suapan berita. fetch('https://api.example.com/news', { next: { revalidate: 3600 } }); // Sahkan semula setiap jam

Terlupa menetapkan polisi cache yang betul adalah isu paling kerap kami nyahpepijat untuk klien yang beralih ke App Router. Sentiasa nyatakan secara eksplisit keperluan kesegaran data anda.

Revalidation Atas Permintaan untuk Kandungan Dinamik

Incremental Static Regeneration (ISR) sangat berkuasa, tetapi menunggu pemasa tamat tempoh tidak selalunya ideal. On-demand revalidation membolehkan anda membersihkan cache secara manual untuk halaman atau tag data tertentu, memberikan kemas kini segera.

Ini biasanya dilakukan melalui laluan API selamat yang dicetuskan oleh webhook dari CMS Tanpa Kepala (Headless CMS) atau sistem backend. Untuk seorang klien e-dagang di Malaysia, kami melaksanakan satu sistem di mana alat pengurusan inventori mereka memanggil webhook setiap kali tahap stok berubah. Webhook ini mencetuskan laluan API Next.js yang melaksanakan revalidatePath:

revalidatePath('/products/[slug]', 'page')

Ini dengan serta-merta membina semula halaman produk tertentu dengan maklumat stok baharu. Pengguna melihat kemas kini itu serta-merta tanpa perlu memasang semula keseluruhan laman. Anda juga boleh menggunakan revalidateTag untuk membatalkan cache beberapa halaman yang berkongsi tag data yang sama, yang mana ia sangat efisien.

Empat Isu Produksi Lazim yang Telah Kami Nyahpepijat

Selain daripada caching, beberapa isu lain kerap muncul dalam persekitaran produksi.

1. Ralat Hidrasi (Hydration Errors): Ini berlaku apabila HTML yang di-render di pelayan tidak sepadan dengan apa yang di-render oleh React di klien. Punca paling lazim ialah penggunaan API khusus pelayar (seperti window.innerWidth) dalam komponen yang tidak ditandakan dengan 'use client', atau memaparkan kandungan secara bersyarat berdasarkan nilai yang hanya wujud selepas halaman dimuatkan dalam pelayar.

2. Pendedahan Pembolehubah Persekitaran yang Salah: Satu kesilapan klasik. Hanya pembolehubah persekitaran dengan awalan NEXT_PUBLIC_ tersedia dalam kod yang menghadap pelayar (Client Components). Kunci sebelah pelayan seperti DATABASE_URL atau STRIPE_SECRET_KEY tidak sepatutnya mempunyai awalan ini. Mengakses pembolehubah tanpa awalan dalam Client Component akan menyebabkannya menjadi undefined, yang membawa kepada ralat masa jalan.

3. Saiz Bungkusan Klien yang Besar: Adalah mudah untuk secara tidak sengaja mengimport pustaka besar ke dalam Client Component, menyebabkan saiz JavaScript yang dihantar kepada pengguna menjadi kembung. Kami sentiasa mengesyorkan penggunaan pakej @next/bundle-analyzer untuk memvisualisasikan saiz bungkusan anda sebelum pemasangan besar.

4. Gelung Tidak Terhingga dalam Server Components: Menggunakan fetch dengan cache: 'no-store' atau revalidate: 0 di dalam layout atau halaman yang juga mengesahkan semula dirinya sendiri kadangkala boleh mencipta gelung permintaan di Vercel, terutamanya jika ia melibatkan header atau cookie. Berhati-hati dengan pengambilan data dinamik dalam layout yang dikongsi.

Semakan Akhir Sebelum Siaran Langsung

Sebelum anda menjalankan vercel --prod, lalui senarai semak terakhir ini:

• Audit panggilan fetch: Adakah setiap fetch mempunyai polisi caching yang eksplisit (no-store atau revalidate) yang sepadan dengan tujuannya?
• Semak sempadan 'use client': Adakah Client Components anda sekecil dan sesasaran yang mungkin?
• Periksa saiz bungkusan: Jalankan penganalisis bungkusan untuk mengesan sebarang pustaka yang besar secara tidak dijangka di sebelah klien.
• Sahkan pembolehubah persekitaran: Pastikan semua pembolehubah yang diperlukan telah ditetapkan dalam tetapan projek Vercel anda dan NEXT_PUBLIC_ digunakan dengan betul.
• Uji webhook: Jika menggunakan on-demand revalidation, cetuskan webhook anda dan sahkan bahawa kandungan dikemas kini seperti yang dijangkakan.

Next.js App Router menawarkan cara yang lebih berkuasa dan terperinci untuk membina aplikasi web, tetapi ia menuntut pendekatan yang lebih berdisiplin terhadap pengambilan data dan pengurusan state. Senarai semak ini membantu memastikan pelancaran anda berjalan lancar dan boleh diramal.