Bài này nói về Next.js 15 App Router cho phỏng vấn mức senior, map từ Nuxt: Next thêm gì cho React, khi nào Vite React vẫn thắng, bản đồ tư duy Nuxt và chỗ nó gãy, RSC khác SSR, file App Router, fetch, navigation, và middleware Edge. Dành cho engineer đã ship Vue 3 / Nuxt, giờ cần một quyết định dưới ràng buộc thật, không phải tour tính năng.

Đọc 21.1–21.5 trước (nó là gì, khác React, map Nuxt, RSC, App Router). Người phỏng vấn đào 'use client' và “RSC có phải SSR?” nhiều hơn trivia thư mục. Rồi 21.6–21.8 cho fetch (Next 15 mặc định không cache), Link / loading.tsx, và middleware không phải authorization. Nêu rõ ranh giới process và tương đương Nuxt trong một câu.

Tóm tắt: Next.js 15 là framework React cho production: file routing của App Router, Server Component mặc định, fetch trên server, Route Handler, và một đích deploy. React là thư viện UI. Nuxt là tương đương gần nhất: framework Vue cho production trên Nitro.

Vì sao quan trọng: “SSR cho React” là cách junior hay chốt. Người phỏng vấn muốn ranh giới process: cái gì chạy trên server, JS nào được gửi, authz nằm ở đâu, và bạn còn chọn Pages Router năm 2026 không (không: App Router là mặc định).

1. Cách hoạt động: app/page.tsx là Server Component trừ khi bạn thêm 'use client'. Nó có thể await fetch (Next 15: không cache trừ khi opt-in). app/layout.tsx bọc segment. app/api/**/route.ts là Route Handler.
2. React không cho bạn: file router, layout lồng nhau, data phía server mà không cần BFF riêng, loading.tsx / error.tsx, helper ảnh/font/metadata, và middleware.ts Edge. Đó mới là framework.
3. Tương đương Nuxt: pages/ + layouts/ + server/api + useAsyncData. Next tách client/server bằng directive, không dùng tên file .client / .server. Xem bản đồ tư duy.

// app/layout.tsx
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return <html lang="en"><body>{children}</body></html>
}
// app/page.tsx: Server Component mặc định (không use client)
export default async function Page() {
  const res = await fetch('https://api.example.com/hello') // Next 15: không cache
  const data: { message: string } = await res.json()
  return <h1>{data.message}</h1>
}
// Nuxt: pages/index.vue + useAsyncData / $fetch trên server

Điều gì xảy ra: Page chạy trên server, fetch data, rồi gửi HTML kèm một payload RSC nhỏ. Data lần đầu không cần useEffect. Next 15 sẽ gọi API mỗi request trừ khi bạn truyền { cache: 'force-cache' } hoặc option revalidate. Nuxt sẽ fetch tương tự trong useAsyncData.

Lỗi hay gặp

• Triệu chứng: “Next là SSR”. Nguyên nhân: trộn RSC với SSR. Cách xử lý: 21.4, RSC là ai chạy component.
• Triệu chứng: fetch đầu thiếu trên prod. Nguyên nhân: tưởng cache mặc định như Next 14. Cách xử lý: Next 15 fetch không cache.
• Triệu chứng: chọn Pages Router cho app mới. Nguyên nhân: blog cũ. Cách xử lý: App Router.
• Triệu chứng: useEffect load trên app/page.tsx. Nguyên nhân: coi như Vite CRA. Cách xử lý: await trong Server Component.

Tóm tắt: React là thư viện. Next.js là framework với ranh giới process: server chạy component và fetch mà trình duyệt không bao giờ thấy. Vite React trần thắng khi bạn không muốn ranh giới đó: dashboard đã login, không SEO, BFF sẵn.

Vì sao quan trọng: “Chỉ dùng Vite + React được không?” là câu senior thật. Next tốn cache, kỷ luật use client, và ràng buộc host. SPA với BFF đơn giản hơn khi cái giá đó không đáng trả. Nuxt vs Vite Vue là cùng ngã rẽ.

1. Cách hoạt động: Vite React: server chỉ host file tĩnh. Mọi data là fetch phía client hoặc BFF. Next: app/page.tsx đọc cookie, secret, và DB (cẩn thận) trên server được. use client là ranh giới, không phải tối ưu.
2. Chọn Next khi muốn HTML từ server, layout lồng nhau, hoặc giữ token khỏi client. Chọn Vite React khi SEO không quan trọng, API đã có, và team không muốn semantics cache của RSC. Tương đương Nuxt: Nuxt vs vite create vue, cùng ngã rẽ.
3. Next có thể full-stack (Route Handler, Server Action). Nó không thay API thật cho client khác. Xem khi nào chọn Next ở 21.11.

// Vite React: data là chuyện của client
export function Dashboard() {
  const [rows, setRows] = useState<Row[] | null>(null)
  useEffect(() => { void api.rows().then(setRows) }, [])
  if (!rows) return <p>Loading…</p>
  return <Table rows={rows} />
}
// Next App Router: cùng UI, server đã có rows
// export default async function Page() {
//   const rows = await db.rows() // không gửi tới trình duyệt như một fetch
//   return <Table rows={rows} />
// }

Điều gì xảy ra: Vite vẽ loading state, rồi hydrate thành rows. Next gửi được HTML của table ngay response đầu và bỏ fetch phía client. Đó là ranh giới process. Nếu Table cần click, nó là Client Component con: use client trên Table, không phải trên page đã load data.

Lỗi hay gặp

• Triệu chứng: SPA Vite viết lại sang Next “cho SEO” với use client mọi page. Nguyên nhân: không có ranh giới process. Cách xử lý: fetch trên server.
• Triệu chứng: secret trong NEXT_PUBLIC_. Nguyên nhân: coi Next như env Vite. Cách xử lý: 21.12 leaking-server-secrets.
• Triệu chứng: “React 19 gồm framework”. Nguyên nhân: trộn React với Next. Cách xử lý: React vẫn là thư viện.
• Triệu chứng: Next cho tool nội bộ chỉ Chrome. Nguyên nhân: mốt. Cách xử lý: Vite React kèm BFF sẵn.

Tóm tắt: Dùng map này để chuyển thói quen Nuxt sang Next 15 App Router. Rồi học ba bẫy chỗ so sánh gãy: middleware Edge, cache fetch, và use client khác file .client. Chỉ map tên thư mục là chưa đủ.

Vì sao quan trọng: “Tương đương Nuxt của X là gì?” là kiểu phỏng vấn chuyển. Senior nêu runtime mặc định, không phải list thư mục. Middleware chạy Node trong Nuxt thì sang Next là Edge. useFetch không phải await fetch. .client.vue không phải use client.

1. Cách hoạt động (bẫy 1, middleware): Nuxt middleware/ là Node, theo từng route, dùng full server được. Next middleware.ts là Edge, một file, API hạn chế, và không phải authorization. Xem 21.8.
2. Bẫy 2 (data): Nuxt useFetch / useAsyncData là composable có refetch. Next await fetch trong Server Component là một request (Next 15: mặc định không cache). Data live trên client vẫn là TanStack Query. cookies() làm route dynamic.
3. Bẫy 3 (ranh giới client): Nuxt .client / .server là tên file. Next use client là ranh giới module: cả file và import của nó thành client. Bạn không truyền hàm từ Server Component vào được. server-only thay .server.

// Bẫy 3: file này là module Client Component
'use client'
export function PayButton({ onPay }: { onPay: () => void }) {
  return <button onClick={onPay}>Pay</button>
}
// Trang server không truyền hàm inline vào PayButton được.
// Truyền id serialise được, hoặc đưa child xuống dưới ranh giới client.
// Bẫy 2: await fetch('...') trong Server Component không phải useFetch.
// Next 15: không cache trừ khi cache: 'force-cache' / revalidate.

Điều gì xảy ra: Đánh dấu file use client thì JS của nó được gửi đi. Trang server cố truyền () => pay() như prop sẽ fail serialise. Nuxt sẽ dùng island .client thay vì directive. Giữ bảng map; nhớ ba bẫy.

Lỗi hay gặp

• Triệu chứng: middleware kiểu Nuxt đụng API Node trên Edge. Nguyên nhân: analogy. Cách xử lý: 21.8; giữ Node trong Route Handler.
• Triệu chứng: chờ refetch useFetch trong Server Component. Nguyên nhân: composable khác request. Cách xử lý: Query phía client.
• Triệu chứng: use client trên page.tsx vì một button. Nguyên nhân: thói quen tên file. Cách xử lý: tách button.
• Triệu chứng: truyền hàm qua prop xuyên ranh giới. Nguyên nhân: serialise. Cách xử lý: id, hoặc để cùng phía client.

Tóm tắt: SSR gửi HTML cho request này. SSG prerender lúc build. CSR/SPA render trên trình duyệt. RSC (React Server Components) chạy component trên server và không gửi JS của nó. Đó không phải SSR. Nuxt có SSR/SSG/SPA; không có RSC.

Vì sao quan trọng: “RSC có phải SSR?” là câu Next bị nhầm nhiều nhất. SSR là HTML cho paint đầu. RSC là ai chạy component và JS của nó có được tải không. Bạn SSR một Client Component được. Bạn dùng RSC mà không cần HTML nếu chỉ stream payload flight. Chọn theo data cần mới cỡ nào và ai được thấy data.

1. Cách hoạt động: SSG: marketing, docs, ít đổi; stale đến lúc rebuild. ISR / revalidateTag: catalog; cửa sổ stale. SSR (dynamic): theo request, cookie, cá nhân hóa; đừng cache HTML của user dưới public key.
2. CSR / SPA island: dashboard sau login, không SEO. Bạn chịu trách nhiệm chuyện loading. RSC: composition mặc định của App Router: data và UI trên server, không JS component cho node đó. Nó không interactive và không phải chiến lược cache.
3. Tương đương Nuxt: ssr: true / routeRules ISR / mode SPA. Không có RSC. Thí nghiệm server component của Nuxt không phải mặc định Next. Partial prerender (shell tĩnh kèm lỗ dynamic) vẫn đang đổi. Nói bức tranh đó, rồi đối chiếu docs hiện tại.

// RSC: file này không use client, không gửi JS component
export default async function Product({ id }: { id: string }) {
  const product = await db.product(id) // ở lại trên server
  return (
    <section>
      <h1>{product.title}</h1>
      <AddToCart id={product.id} /> {/* island client */}
    </section>
  )
}
// SSR vẫn gửi HTML cho Product. RSC bỏ JS của Product.
// AddToCart.tsx bắt đầu bằng use client, JS đó thì được gửi.

Điều gì xảy ra: Server đọc DB, render HTML của Product (SSR), và không gửi JS component của Product (RSC). AddToCart là island client, hydrate sau. Nhầm hai câu đó là miss. Nuxt sẽ SSR trang và gửi hết JS component, trừ khi bạn tách island.

Lỗi hay gặp

• Triệu chứng: “RSC là SSR”. Nguyên nhân: cả hai chạy trên server. Cách xử lý: phân biệt HTML với JS được gửi.
• Triệu chứng: user A thấy HTML của user B. Nguyên nhân: cache public của trang cookie. Cách xử lý: dynamic / private.
• Triệu chứng: trang static gọi cookies(). Nguyên nhân: vô tình thành dynamic. Cách xử lý: truyền id như param.
• Triệu chứng: map RSC sang server component Nuxt. Nguyên nhân: analogy. Cách xử lý: Nuxt không mặc định kiểu này.

Tóm tắt: App Router lấy folder làm segment: page.tsx, layout.tsx lồng nhau, Server Component mặc định. use client là ranh giới module. Client Component không import được Server Component. Bạn không truyền được prop hàm xuyên ranh giới đó. Tương đương Nuxt: pages/ kèm layouts/ lồng nhau.

Vì sao quan trọng: “use client để đâu?” quyết định bạn còn server hay không. Gắn nó lên layout.tsx hoặc page.tsx vì một button thì cả cây bị gửi. Truyền onPay={() => ...} từ Server Component sẽ fail serialise. Island .client của Nuxt từng là tên file; đây là cắt graph.

1. Cách hoạt động: app/dashboard/layout.tsx bọc app/dashboard/page.tsx và app/dashboard/settings/page.tsx. Layout persist khi chuyển giữa các trang đó. template.tsx thì remount. page.tsx là leaf.
2. Default export không có use client là Server Component: await được, đọc secret, import module server-only. Gắn use client ở đầu file cần event hoặc hook. Tách button ra; đừng đánh dấu cả trang.
3. Composition: Server Component import Client Component được (truyền prop serialise được). Client Component không import Server Component được. Tương đương Nuxt: child .client trong trang server, không phải trang client import component .server.

// app/dashboard/page.tsx: Server Component (mặc định)
import { PayButton } from './pay-button'
export default async function Page() {
  const invoice = await db.invoice() // chỉ chạy trên server
  return <PayButton invoiceId={invoice.id} /> // id serialise được
}
// pay-button.tsx
'use client'
export function PayButton({ invoiceId }: { invoiceId: string }) {
  return <button onClick={() => pay(invoiceId)}>Pay</button>
}
// Đừng: <PayButton onPay={() => pay(invoice.id)} /> từ trang server.

Điều gì xảy ra: Trang vẫn là Server Component. Chỉ PayButton gửi JS. Id đi xuyên ranh giới; hàm thì không. Gắn use client lên page.tsx sẽ đẩy cách dùng db sang client, hoặc fail build vì server-only.

Lỗi hay gặp

• Triệu chứng: use client trên layout gốc. Nguyên nhân: một event handler. Cách xử lý: tách widget.
• Triệu chứng: prop hàm từ server sang client. Nguyên nhân: serialise. Cách xử lý: id hoặc để cùng phía.
• Triệu chứng: Client Component import db. Nguyên nhân: ranh giới quá cao. Cách xử lý: server-only trên db.
• Triệu chứng: dựng lại shell mọi trang. Nguyên nhân: bỏ qua layout lồng. Cách xử lý: layout.tsx.

Tóm tắt: Trong Server Component, await fetch (hoặc DB client). Song song Promise.all; nối await trong layout lồng là waterfall. Next 15 không cache fetch mặc định. Data live trên client là TanStack Query. Tương đương Nuxt: useAsyncData / $fetch trên server.

Vì sao quan trọng: Next 14 cache fetch mặc định; Next 15 thì không. Copy blog đời 14 sẽ bất ngờ trên prod. cookies() / headers() làm route dynamic. useEffect trên trang là thói quen Vite. await nối trong layout lồng là waterfall 21.12.

1. Cách hoạt động: Server Component: const res = await fetch(url). Opt-in cache với { cache: 'force-cache' } hoặc { next: { revalidate: 60, tags: ['x'] } }. Mutate rồi revalidatePath / revalidateTag.
2. Song song: bắt đầu cả hai promise, rồi await Promise.all. Nối: await a rồi await b cần a.id. Layout lồng, mỗi tầng await user rồi dashboard rồi widget, là waterfall tình cờ. Xem 21.12.
3. Fetch phía client: TanStack Query (hoặc SWR) trong island use client cho search live, polling, UI optimistic. Đừng useEffect + useState cho data load đầu mà server đã có. Nuxt: useAsyncData trên server; plugin client cho live.

export default async function Page() {
  const userP = currentUser() // bắt đầu ngay
  const dashP = fetch('https://api.example.com/dash') // Next 15: không cache
  const [user, dashRes] = await Promise.all([userP, dashP])
  const dash = await dashRes.json()
  return <Dashboard user={user} dash={dash} />
}
// Nối chỉ khi b cần a.id. cookies() làm route dynamic.
// Search live trên client: Query trong island use client, không useEffect trên trang này.

Điều gì xảy ra: Cả hai request bắt đầu trước khi cái nào xong. await currentUser() rồi fetch nối sẽ dính waterfall. Next 15 đụng API mỗi lần trừ khi bạn opt-in cache. Nuxt useAsyncData kèm lazy / Promise.all là cùng ý.

Lỗi hay gặp

• Triệu chứng: catalog cũ sau CMS publish. Nguyên nhân: copy cache fetch kiểu Next 14. Cách xử lý: tags + revalidate, hoặc chấp nhận không cache.
• Triệu chứng: useEffect load trên page.tsx. Nguyên nhân: thói quen Vite. Cách xử lý: await trên server.
• Triệu chứng: layout chờ user, trang chờ dash, widget chờ items. Nguyên nhân: await nối tiếp. Cách xử lý: Promise.all / 21.12.
• Triệu chứng: cookies() trên trang marketing. Nguyên nhân: dynamic tình cờ. Cách xử lý: đừng đọc cookie ở đó.

Tóm tắt: Link navigate phía client và prefetch các route trong viewport. layout.tsx lồng thì persist. loading.tsx bọc segment trong Suspense. error.tsx là error boundary của segment đó. Tương đương Nuxt: NuxtLink, layout, và loading component bạn tự viết.

Vì sao quan trọng: <a href> thuần thì reload và vứt state layout. Prefetch cả admin trên landing marketing đốt băng thông. loading.tsx không chừa chiều cao thì dính CLS. error.tsx không reset lúc navigate thì kẹt shell gãy. Prefetch NuxtLink của Nuxt cũng cùng cơ chế.

1. Cách hoạt động: <Link href="/dash"> prefetch khi hiện (mặc định). Dùng <a> cho external. scroll={false} khi phải giữ scroll. prefetch={false} trên link admin ít khi bấm.
2. loading.tsx là fallback Suspense cho page.tsx của segment đó. Layout lồng vẫn hiện. Ghép với skeleton chừa chiều cao. error.tsx bắt lỗi render trong segment; cần reset bằng navigate hoặc retry.
3. Navigate mềm giữ layout mounted. Reload đầy đủ remount mọi thứ, kể cả state client bạn tưởng là global. Tương đương Nuxt: NuxtLink + layouts/ persist; bạn vẫn phải thiết kế slot loading.

// app/dashboard/layout.tsx persist xuyên /dashboard/*
export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <section>
      <nav><Link href="/dashboard/settings">Settings</Link></nav>
      {children}
    </section>
  )
}
// app/dashboard/loading.tsx: fallback Suspense, chừa chiều cao
export default function Loading() {
  return <div className="dash-skel" aria-busy="true" />
}
// error.tsx: error boundary cho segment này, không phải cả app.

Điều gì xảy ra: Click Settings thì nav vẫn mounted. Trong lúc trang fetch, loading.tsx hiện skeleton đã chừa size để CLS không nhảy. Lỗi trong settings không unmount layout dashboard. <a> thuần sẽ reload shell.

Lỗi hay gặp

• Triệu chứng: state layout reset mỗi lần click. Nguyên nhân: <a href> thay vì Link. Cách xử lý: Link.
• Triệu chứng: landing marketing tải JS admin. Nguyên nhân: prefetch mặc định của link admin đang hiện. Cách xử lý: prefetch={false} / chưa link nó.
• Triệu chứng: spinner làm nhảy trang. Nguyên nhân: loading.tsx không có chiều cao. Cách xử lý: skeleton + aspect-ratio.
• Triệu chứng: lỗi kẹt sau navigate. Nguyên nhân: không reset. Cách xử lý: reset() từ error boundary hoặc một Link.

Tóm tắt: middleware.ts của Next chạy trên Edge, trước khi request vào Node. Nó redirect, rewrite, set header được. Nó không phải authorization: fetch tự chế vẫn tới Route Handler nếu bạn chỉ giấu trang. Nuxt middleware/ là Node, theo route, runtime khác hẳn.

Vì sao quan trọng: “Auth-gate App Router thế nào?” mà chỉ trả lời bằng middleware là fail. Edge không dùng hết API Node. Matcher mà cũng dính /_next hoặc /login là vòng redirect. Route middleware Nuxt import Pinia store thì không port được.

1. Cách hoạt động: Một middleware.ts ở root (hoặc src/). NextRequest / NextResponse. config.matcher chọn path. Redirect user chưa auth tới /login. Bỏ file tĩnh và chính route login.
2. Authz vẫn nằm ở Server Component, Route Handler, hoặc Server Action: đọc session, redirect / 403. Middleware là cổng rẻ: chỉ xem cookie có mặt, kèm header geolocation / A/B. Giới hạn Edge: không full Node, cẩn thận thư viện verify JWT.
3. Tương đương Nuxt: middleware/auth.ts là Node và navigateTo được. Next Edge không useAsyncData hay đụng DB. Guard SPA React chỉ là UX, cùng một cảnh báo. Xem security 10.3 để biết session nằm ở đâu, bằng lời.

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
export function middleware(req: NextRequest) {
  const session = req.cookies.get('session')
  if (!session && req.nextUrl.pathname.startsWith('/dashboard')) {
    const login = new URL('/login', req.url)
    login.searchParams.set('from', req.nextUrl.pathname)
    return NextResponse.redirect(login)
  }
  return NextResponse.next()
}
export const config = { matcher: ['/dashboard/:path*'] }
// Vẫn check session trong Server Component. Đây không phải authz.

Điều gì xảy ra: Thiếu cookie trên /dashboard thì redirect sang /login. Matcher bỏ /login nên bạn không loop. Caller gọi /api/secret mà không có cookie vẫn cần Route Handler trả 401. Middleware Nuxt có thể query DB; file Edge này thì không được.

Lỗi hay gặp

• Triệu chứng: vòng redirect. Nguyên nhân: matcher dính /login hoặc /_next. Cách xử lý: siết config.matcher.
• Triệu chứng: “bọn mình auth trong middleware”. Nguyên nhân: chỉ giấu trang. Cách xử lý: check session trong Server Component / Route Handler.
• Triệu chứng: lỗi runtime Edge trên fs / Prisma. Nguyên nhân: API Node. Cách xử lý: chuyển sang Route Handler.
• Triệu chứng: store Nuxt import vào middleware Next. Nguyên nhân: suy tương đương. Cách xử lý: chỉ dùng bit cookie.

Tóm tắt: Server Action là POST công khai mà Next nối từ form hoặc button. use server đánh dấu hàm. Bạn vẫn authenticate, authorize, validate, mutate, rồi revalidateTag. Tương đương Nuxt: POST server/api kèm refreshNuxtData.

Vì sao quan trọng: “Action có an toàn?” là câu phỏng vấn. Chúng trông như RPC. Chúng là endpoint. Check Origin có, nhưng không thay authz trong action. Export helper từ file use server là công khai nó.

1. Cách hoạt động: File hoặc hàm đánh dấu use server gọi được như một POST. <form action={createItem}> gửi FormData. Button phía client gọi cùng hàm được. Next check header Origin. Đó là giảm CSRF, không phải authorization.
2. Trong action: session (cookies), quyền, schema (zod), ghi, rồi revalidateTag / revalidatePath. Return kết quả serialise được. Đừng return process.env. useActionState / useFormStatus là UI pending và lỗi. useOptimistic chỉ là một lần vẽ: server vẫn là nguồn sự thật.
3. Giữ route.ts cho webhook, POST bên thứ ba, và upload streaming. Tương đương Nuxt là handler Nitro kèm refreshNuxtData / refreshCookie. Đừng coi Action thay cho API công khai mà client khác cần.

// app/actions.ts: directive của file là use server
'use server'
import { revalidateTag } from 'next/cache'
import { z } from 'zod'
const Input = z.object({ title: z.string().min(1).max(200) })
export async function createItem(formData: FormData) {
  const session = await getSession() // cookies()
  if (!session) redirect('/login')
  if (!can(session, 'item:create')) throw new Error('Forbidden')
  const parsed = Input.safeParse({ title: formData.get('title') })
  if (!parsed.success) return { ok: false as const, error: 'Invalid title' }
  await db.item.create({ data: { title: parsed.data.title, userId: session.id } })
  revalidateTag('items') // không phải revalidatePath('/blog/[slug]')
  return { ok: true as const }
}
// <form action={createItem}><input name="title" /><button>Save</button></form>

Điều gì xảy ra: Submit POST tới createItem. User chưa đăng nhập thì redirect. Forbidden thì throw. Title sai thì return lỗi serialise được cho form. Ghi thành công thì tag items để trang list làm mới. Hàm là public: ai POST được thì gọi được nếu thiếu authz.

Lỗi hay gặp

• Triệu chứng: ai cũng tạo được. Nguyên nhân: tin Action vì “nội bộ”. Cách xử lý: session + can() bên trong.
• Triệu chứng: list vẫn cũ. Nguyên nhân: revalidatePath với pattern token. Cách xử lý: revalidateTag('items').
• Triệu chứng: helper cùng file gọi được từ trình duyệt. Nguyên nhân: mọi export là endpoint. Cách xử lý: tách file.
• Triệu chứng: secret Stripe trong return Action. Nguyên nhân: return cả row. Cách xử lý: { ok: true } / một DTO.

Tóm tắt: Nói theo bốn lớp cache, rồi nêu rõ major. Next 15 fetch không cache trừ khi bạn opt-in. cookies() / headers() làm route thành dynamic. Sheet này là bản đồ; kiểm cơ chế trên version bạn đang dùng.

Vì sao quan trọng: “Sao trang này cũ / sao luôn dynamic?” là câu on-call. Next 14 cache fetch mặc định; Next 15 đảo ngược. Copy blog viết cho 14 sang 15 thì prod bất ngờ. Tiền và tồn kho cần tag, không phải theo thời gian.

1. Cách hoạt động: Bốn lớp: request memoization (dedupe fetch giống nhau trong một lần render phía server), data cache (giữ fetch xuyên request; Next 15 tắt trừ khi opt-in), full route cache (RSC/HTML đã cache cho route tĩnh hoặc ISR), client router cache (prefetch, tiến/lùi).
2. Đừng đọc cả bảng. Chọn lớp giải thích được bug, rồi nêu rõ cơ chế (no-store, force-cache, revalidate, tags, cookies()). use cache là cache hàm tường minh mới hơn; kiểm trên major của bạn trước khi khẳng định.

// app/catalog/page.tsx: Next 15, fetch này không cache trừ khi opt-in
export default async function CatalogPage() {
  const res = await fetch('https://api.example.com/items', {
    next: { revalidate: 60, tags: ['items'] }, // data cache + tag
  })
  const items: Item[] = await res.json()
  return <ul>{items.map((it) => <li key={it.id}>{it.title}</li>)}</ul>
}
// Sau khi ghi: revalidateTag('items') từ Server Action / webhook.
// Đừng: cookies() trong layout gốc chỉ để đọc theme.
// Tiền / tồn kho: bỏ revalidate theo thời gian; chỉ tag + on-demand.

Điều gì xảy ra: Không có option next thì Next 15 gọi API mỗi request. Tag để một lần ghi làm mới HTML catalog. Request memoization vẫn dedupe cùng URL trong một lần render. cookies() trong layout gốc sẽ biến cả cây thành dynamic.

Lỗi hay gặp

• Triệu chứng: fetch luôn hit trên 15. Nguyên nhân: giả định cache mặc định Next 14. Cách xử lý: opt-in, hoặc chấp nhận dynamic.
• Triệu chứng: cả app dynamic. Nguyên nhân: cookies() trong layout gốc. Cách xử lý: đưa lần đọc xuống.
• Triệu chứng: product vẫn cũ sau revalidateTag. Nguyên nhân: fetch không có tag khớp. Cách xử lý: gắn tag lúc đọc và lúc ghi.
• Triệu chứng: HTML đúng, UI cũ khi Back. Nguyên nhân: client router cache. Cách xử lý: router refresh sau khi ghi.

Tóm tắt: Chọn Next khi SEO, preview mạng xã hội, hoặc data server cạnh UI là quan trọng. Chọn Vite React SPA cho dashboard đã login với API chín. Next dùng như SPA host với use client khắp nơi là chịu dở cả hai bên. Nuxt khác Vite Vue là cùng một ngã rẽ.

Vì sao quan trọng: “Có dashboard đã auth: Next hay Vite?” là ràng buộc product, không phải chuyện résumé. Người phỏng vấn chấm bạn có chịu trả chi phí cache RSC khi chẳng có SEO. Xem thêm 21.2.

1. Cách hoạt động (checklist): 1. URL có cần HTML cho crawler hoặc unfurl? Next (hoặc Nuxt). 2. Đã có BFF và login kín? SPA Vite. 3. Muốn cookies/session nằm cạnh cây? Next. 4. Team sống được với kỷ luật use client? Không thì SPA.
2. 5. Mutation: Server Action colocate trên Next; API REST/GraphQL sẵn thì SPA thắng. 6. Hiring: skill RSC hẹp hơn skill React SPA. 7. Hosting: bucket tĩnh khác Node/Edge. 8. Trộn: marketing public trên Next, app là SPA thì được, miễn hai hũ cookie không rò sang nhau.
3. Tương đương Nuxt: Nuxt khác vite create vue: cùng tám câu. Áp lực résumé không phải lý do chọn meta-framework. Xem 21.2 Next khác React.

// Phác quyết định: nói to ra, rồi chọn
type Pick = 'next' | 'vite-spa'
export function pickFramework(p: {
  seo: boolean
  existingBff: boolean
  closedLogin: boolean
  teamWantsRsc: boolean
}): Pick {
  if (p.seo) return 'next'
  if (p.closedLogin && p.existingBff && !p.teamWantsRsc) return 'vite-spa'
  if (!p.teamWantsRsc && p.existingBff) return 'vite-spa'
  return 'next'
}
// Admin đã login, API chín → vite-spa. Docs + app, cookies → next.

Điều gì xảy ra: SEO thì chọn Next. Login kín kèm BFF kèm team không muốn RSC thì trả Vite. Hàm chỉ là phác thảo, không phải bảng điểm: nói ràng buộc trước. Nuxt khác Vite Vue trả lời bằng cùng các nhánh.

Lỗi hay gặp

• Triệu chứng: SPA Vite viết lại sang Next “cho SEO” với use client mọi trang. Nguyên nhân: résumé. Cách xử lý: giữ Vite, hoặc dùng server cho đúng.
• Triệu chứng: tool nội bộ chỉ Chrome mà dựng trên Next. Nguyên nhân: theo mốt. Cách xử lý: Vite React kèm BFF sẵn có.
• Triệu chứng: hai app, một cookie session bị rò. Nguyên nhân: trộn marketing + app không tách cookie. Cách xử lý: tách host / tên.
• Triệu chứng: “phải học RSC cho admin CRUD”. Nguyên nhân: không SEO, API chín. Cách xử lý: SPA mới là lựa chọn senior.

Tóm tắt: On-call Next gom thành ba nhóm: lệch hydration, data server trong payload Flight, và waterfall await. Đừng gọi mọi thứ là “SSR”. Mỗi nhóm có H4 riêng bên dưới.

Vì sao quan trọng: Người phỏng vấn hỏi “bạn đã đưa bug hydration lên production chưa?”, “secret lộ trong RSC thế nào?”, và “sao TTFB 2s với ba fetch?” Senior có fix mặc định cho từng nhóm, rồi chứng minh.

1. Cách hoạt động: Mở H4 khớp incident. Lệch hydration là HTML first-paint khác first render phía client. Lộ secret là mọi thứ bạn đưa xuyên ranh giới RSC. Waterfall là await nối tiếp trong layout lồng.
2. Rule chung: nêu rõ ranh giới process. Nuxt có cùng ba nhóm (ClientOnly / payload / useAsyncData nối tiếp). Nguyên nhân riêng React nằm ở các H4. Vue 5.2.11 là topic hydration anh em.

// Ba nhóm: mở H4 khớp, đừng debug “SSR”
// 1. Hydration: HTML server phải khớp chữ với first render phía client
//    <span>{createdAt.toLocaleDateString()}</span>  // locale có thể khác
// 2. Secret: props tới Client Component nằm trong payload Flight
//    <Panel user={user} />  // user.emailHash có thể là leak
// 3. Waterfall: layout lồng await nối tiếp làm TTFB phình
//    await user; await dash; await items  // bắt đầu việc độc lập cùng lúc
// Chứng minh: build prod cho (1), tìm trong response RSC cho (2), flame server cho (3).

Điều gì xảy ra: Comment là bản đồ triage, không phải fix. Nhóm 1 là lệch chữ. Nhóm 2 là payload bạn Ctrl-F được. Nhóm 3 là timeline server. Mỗi H4 có example chạy được.

Lỗi hay gặp

• Triệu chứng: gọi mọi bug Next là “SSR”. Nguyên nhân: không phân nhóm. Cách xử lý: hydration / payload / waterfall.
• Triệu chứng: suppressHydrationWarning trên layout. Nguyên nhân: giấu clock. Cách xử lý: H4 hydration.
• Triệu chứng: row Prisma làm prop Client. Nguyên nhân: cho tiện. Cách xử lý: H4 secret.
• Triệu chứng: mỗi layout lồng một await. Nguyên nhân: “một fetch một file”. Cách xử lý: H4 waterfall.

Tóm tắt: Hydration đòi first render phía client khớp chữ với HTML server. toLocaleDateString(), Date.now(), Math.random(), và localStorage lúc render phá điều đó. Chung với Vue 5.2.11; nguyên nhân riêng React là locale, HTML không hợp lệ, và extension.

Vì sao quan trọng: Overlay “did not match” trên layout format new Date(), hoặc theme đọc localStorage lúc render, là incident production. suppressHydrationWarning trên cả cây thì giấu bug. ClientOnly của Nuxt là lối thoát anh em: dùng cho map, không dùng cho clock.

1. Cách hoạt động: Server phát HTML. React đi HTML đó và first render phía client. Lệch chữ thì vứt node và render lại. Format ngày với locale tường minh (hoặc chuỗi ISO đã serialize). Theme: cookie trên <html> (server thấy được) hoặc script inline trước paint, không localStorage trong render.
2. suppressHydrationWarning cho một text node clock, không phải layout. HTML không hợp lệ (<p><div>) bị browser viết lại; cây React thì không. Trông như bug của bạn. Extension browser inject DOM cùng một class. Chứng minh bằng bản production; HMR nói dối.
3. Tương đương Nuxt: payload kèm ClientOnly / <client-only>. Vue 3.4+ data-allow-mismatch là phẫu thuật. Xem hydration Vue 5.2.11.

// Bẫy: HTML server "en-US 10/08" khác client "vi-VN 08/10"
export function CreatedAt({ iso }: { iso: string }) {
  // ❌ locale và timezone theo máy, không theo request
  // return <time>{new Date(iso).toLocaleDateString()}</time>
  // ✅ serialize trên server với locale tường minh
  const text = new Intl.DateTimeFormat('en-GB', {
    timeZone: 'UTC', dateStyle: 'medium',
  }).format(new Date(iso))
  return <time dateTime={iso}>{text}</time>
}
// Theme: gán class trên <html> từ cookie, không localStorage lúc render.
// suppressHydrationWarning: một text node (clock live), không bao giờ layout.

Điều gì xảy ra: Cả hai máy format iso bằng en-GB và UTC, nên chữ khớp. toLocaleDateString() cũ dùng locale của server khác laptop. Class theme từ cookie nằm trong HTML server; localStorage thì không.

Lỗi hay gặp

• Triệu chứng: overlay trên clock ở header. Nguyên nhân: toLocaleDateString() trong layout chung. Cách xử lý: locale tường minh.
• Triệu chứng: theme nháy rồi lệch. Nguyên nhân: localStorage lúc render. Cách xử lý: cookie trên <html>.
• Triệu chứng: warning chỉ trên prod. Nguyên nhân: tin HMR. Cách xử lý: next build && next start.
• Triệu chứng: suppressHydrationWarning trên <body>. Nguyên nhân: giấu cả cây. Cách xử lý: một text node, hoặc sửa từ nguồn.

Tóm tắt: Mọi thứ bạn đưa vào Client Component hoặc return từ Server Action nằm trong payload user đọc được. NEXT_PUBLIC_ là công khai. import 'server-only' làm fail build nếu file client import module đó. Tương đương Nuxt: runtimeConfig.public khác private.

Vì sao quan trọng: “Secret lộ trong RSC thế nào?” muốn payload Flight, không phải “đừng dùng env vars”. Đưa row Prisma vào <Panel user={user} /> thì serialise mọi cột. Xem thêm secret trong Vite và Nuxt.

1. Cách hoạt động: Server Component đọc được process.env.DATABASE_URL. Một khi giá trị đó thành prop, return, hoặc chuỗi NEXT_PUBLIC_ bị inline, nó là công khai. Đánh dấu module secret bằng import 'server-only'. Chỉ truyền { id, name }, không phải cả row ORM. Session nằm trong cookie httpOnly, không dump vào store phía client.
2. Nguyên nhân: NEXT_PUBLIC_STRIPE_SECRET; return process.env từ Action; log row vào error boundary phía Client; nhét PII lên prop Client “cho tiện”. Tìm key trong response RSC (payload Flight) trước khi gọi trang là an toàn.
3. Tương đương Nuxt: runtimeConfig private khác runtimeConfig.public / NUXT_PUBLIC_. Composable return cả config thì đổ hết vào window.__NUXT__. Cùng thói quen: grep payload.

import 'server-only'
export const dbUrl = process.env.DATABASE_URL! // không được vào module client

export type UserDto = { id: string; name: string }
export function toUserDto(row: { id: string; name: string; emailHash: string }): UserDto {
  return { id: row.id, name: row.name } // không emailHash, không row Prisma
}
// Client: <Panel user={toUserDto(row)} />
// Đừng: <Panel user={row} /> hoặc return process.env từ Action.
// NEXT_PUBLIC_* bị inline vào bundle trình duyệt: chỉ key publishable.
// Chứng minh: tìm DATABASE_URL và emailHash trong body RSC / Flight.

Điều gì xảy ra: server-only làm fail build nếu file use client import dbUrl. toUserDto bỏ emailHash trước khi vào payload Flight. Tìm trong body RSC mới là kiểm chứng, không phải hy vọng lúc review.

Lỗi hay gặp

• Triệu chứng: Stripe sk_ trong bundle. Nguyên nhân: NEXT_PUBLIC_STRIPE_SECRET. Cách xử lý: rotate, rồi server-only.
• Triệu chứng: hash email trong body RSC. Nguyên nhân: đưa row Prisma. Cách xử lý: toUserDto.
• Triệu chứng: Action return process.env. Nguyên nhân: debug. Cách xử lý: { ok: true }. Check Origin không giấu nó.
• Triệu chứng: server-only sau đó nằm sau use client. Nguyên nhân: refactor. Cách xử lý: build phải fail; đừng bỏ qua.

Tóm tắt: Waterfall là việc nối tiếp không cần phải chờ. Layout lồng, mỗi cái một await, làm TTFB phình. Chỉ waterfall khi data phụ thuộc thật; việc độc lập thì Promise.all hoặc stream một lỗ bằng Suspense. Tương đương Nuxt: useAsyncData nối trong layout lồng.

Vì sao quan trọng: “Sao TTFB 2s trên trang với ba fetch?” muốn đồ thị phụ thuộc, không phải “dùng Promise.all khắp nơi”. Next 15 fetch không cache, nên layout nối không được cache hit miễn phí. Shell RSC rỗng kèm năm useEffect fetch là Next dùng như SPA.

1. Cách hoạt động: await getUser() trước nếu orders và notifs cần user.id, rồi Promise.all phần còn lại. Bắt đầu việc con ở parent (Promise.all / preload) hoặc dựa vào request memoization để fetch cùng URL của child trong lần render này là miễn phí. Stream lỗ không critical bằng <Suspense> thay vì chặn cả trang.
2. layout.tsx lồng, mỗi cái await widget dashboard riêng, là chỗ TTFB phình kinh điển. Giới hạn concurrency: đừng Promise.all 10k id. fetch không cache của Next 15 làm chuyện này lộ; cache mặc định Next 14 thì giấu.
3. Tương đương Nuxt: useAsyncData / useFetch nối trong layout lồng, khác Promise.all kèm đảo lazy. Cùng đồ thị. Xem 21.6 cho các pattern fetch mà H4 này không lặp.

export default async function DashboardPage({ id }: { id: string }) {
  // Lỗi hay gặp: nối tiếp, getOrders không cần getNotifs xong
  // const user = await getUser(id)
  // const orders = await getOrders(user.id)
  // const notifs = await getNotifs(user.id)
  const user = await getUser(id) // cần nếu cái khác cần user.id
  const [orders, notifs] = await Promise.all([
    getOrders(user.id),
    getNotifs(user.id),
  ])
  return <Dash user={user} orders={orders} notifs={notifs} />
}
// Widget không critical: <Suspense fallback={<Skel />}><Widget /></Suspense>
// Fetch con cùng URL trong lần render này được memoize: vẫn bắt đầu ở parent.

Điều gì xảy ra: User là phụ thuộc thật. Orders và notification bắt đầu cùng lúc sau khi có user.id. Bản nối trong comment trả TTFB vì getNotifs phải chờ getOrders. Lỗ Suspense quanh widget thì shell vẽ trước.

Lỗi hay gặp

• Triệu chứng: TTFB là tổng ba fetch. Nguyên nhân: layout lồng mỗi cái await. Cách xử lý: Promise.all ở parent.
• Triệu chứng: “nhưng fetch được cache”. Nguyên nhân: thói quen Next 14 trên Next 15. Cách xử lý: mặc định không cache; hãy nhìn đồ thị.
• Triệu chứng: Promise.all 10k. Nguyên nhân: không giới hạn. Cách xử lý: batch.
• Triệu chứng: RSC rỗng, năm fetch client. Nguyên nhân: thói quen Vite. Cách xử lý: await shell trên server.