Edge Runtime vs Node Runtime,怎么选?
Next.js 里每条路由都能选 runtime,Edge 快、便宜、全球分布,但 API 受限;Node 慢但全功能。怎么选一直纠结。 我的判断: middleware、纯转发、轻量计算 → Edge。 重业务、用到 Node 库(Prisma、Sharp、pdf)→ Node
Posts
像论坛一样发起讨论,适合问题、观点、工具推荐和经验交流。
Next.js 里每条路由都能选 runtime,Edge 快、便宜、全球分布,但 API 受限;Node 慢但全功能。怎么选一直纠结。 我的判断: middleware、纯转发、轻量计算 → Edge。 重业务、用到 Node 库(Prisma、Sharp、pdf)→ Node
CDN 缓存一直是个迷,最近终于把 middleware 和 headers 那一套摸顺了。关键是用 NextResponse.next() 加自定义 headers。 配合 ISR,效果是:边缘缓存 60s,过期后回源同时返回旧数据 600s。命中率高,回源率低。 但要注意:
revalidateTag 思路很好——给 fetch 打 tag,写完数据后按 tag 失效。但用了一年发现有挺多坑。 最坑的是 tag 是全局的,不同路由用了同名 tag 会一起失效。后来约定 tag 带命名空间,比如 posts:list 、 posts:detail:${
用 next/font/local 加载本地 woff2,本地好好的,build 时报 "Cannot find module" 或者 "Failed to find font"。 排查下来是路径问题。文档说路径相对于当前文件,但实际上是相对于项目根目录(也有人说看版本)。最后统
App Router 的 intercepting routes + parallel routes 做模态框,理论很美,实际上首屏从外层路由跳进模态路由时经常闪一下,或者刷新直接进纯页面。 试过的解法: parallel route 的 default.tsx 必须写,否则 4
Link 默认会 prefetch 链接目标,列表页一屏几十个 link,prefetch 把带宽和 CPU 都吃满了,低端机明显卡。 试了下 <Link prefetch={false} ,列表页首屏反而快了一截。hover 时还是会 prefetch,体验没差太多。 现在的策
基于 App Router 做了一套中后台模板,沉淀了几个比较好用的约定。 每个资源模块是 app/(dashboard)/[resource]/ 下的标准三件套:list / detail / form。 表格列定义抽到 features/[resource]/columns.
'use client' 加在哪个层级,一直没标准答案。加太靠上,整棵子树都变成客户端组件,RSC 的好处没了;加太靠下,文件爆炸。 我现在的原则: 叶子交互组件(按钮、输入框、下拉)单独标 'use client' 。 容器组件尽量保持 server,把 client 组件当
一个内部中后台,纯 SPA,没用 Next.js。Vite + React Query + Tailwind,整套组合用下来非常顺手。 React Query 的缓存策略省了巨多状态管理代码, staleTime 配合 keepPreviousData 做分页表格体验极好。配合
小项目选数据请求库,SWR 和 React Query(TanStack Query)二选一,纠结很久。 简单对比: SWR:体积小,API 简单,够用。 React Query:功能全(mutations、devtools、乐观更新),生态大。 我的结论:< 5 个接口用 SW
项目里两种风格混着用,想统一一下。Server Actions 写起来简洁,但有些场景感觉 API route 更合适。 我的分类: 站内表单、提交后刷新当前页 → Server Actions。 给前端 SDK、移动端、第三方调用 → API route。 需要复杂中间件(限流
在 Server Component 里用 next/headers 的 cookies() 读登录态,本地 dev 正常,部署后偶发读不到。 排查发现是: cookies() 在 Next 15 是 async 了,要 await(已经改)。 跨域 cookie 没带 Same