分享我的 Next.js 项目结构约定
团队规模上来之后,App Router 的目录约定变得越来越重要。分享一份我们用了一年的结构: 几个硬约定: app/ 下的 page 不写业务逻辑,只组装。 数据访问统一走 lib/db/ .server.ts ,文件名后缀卡边界。 Server Actions 放 featu
这里聚合 CodeNodeX AI 社区中与 Next.js 相关的技术文章和讨论,覆盖概念解释、工具对比、工程实践、常见问题和独立开发经验。
如果你正在研究 Next.js,建议先阅读高质量长文,再参与帖子讨论,形成从理解到实践的完整路径。
团队规模上来之后,App Router 的目录约定变得越来越重要。分享一份我们用了一年的结构: 几个硬约定: app/ 下的 page 不写业务逻辑,只组装。 数据访问统一走 lib/db/ .server.ts ,文件名后缀卡边界。 Server Actions 放 featu
middleware 里要解析登录态,每次都查一次数据库,P95 拖到 80ms。想着迁到 Edge Runtime 上跑会快点,但又怕很多 Node 依赖用不了。 测了下,Edge 上不能直接用 Prisma,得换成 serverless driver 或者干脆只验 JWT。最
不黑不踩,Next.js 文档整体质量不错,但 caching 那一章真的离谱。不同版本默认值变了三回,文档上写的还是老默认值,新人看了直接踩坑。 最让人崩溃的是 "默认 fetch 会缓存" 这条。Next 14 是默认缓存,14.2 之后某些场景又改成不缓存,到 15 默认全
新项目立项,团队在纠结这个。我倾向 Next.js(SSR/SEO 友好),但同事觉得 Vite + React 更灵活、构建快、心智负担小。 我的判断标准大概是这样: 重 SEO、内容型、有 SSR 需求 → Next.js。 中后台、登录后应用、纯交互 → Vite SPA。
几台机器上跑了好几个 Next.js 应用,每个都自带一份 node modules,磁盘和构建时间都顶不住。想试试 shared node modules,但又怕依赖版本冲突。 查了下, output: 'standalone' 模式只会打包运行时真正用到的依赖,体积小很多,但
用 output: 'standalone' 出来的 .next/standalone 目录,理论上拷到服务器直接 node server.js 就能跑。但实际部署我踩了好几个坑。 public/ 和 .next/static 不会被打进 standalone,得手动拷。 路径都
React 19 的 useFormStatus 配合 Server Actions,做表单提交体验非常好。提交按钮的 loading 态一行就搞定: 关键是不用再手动维护 state,组件也更干净。配合 useActionState 拿错误信息,整个表单几乎零样板代码。 唯一不
试了下 useActionState ,整体思路很好,但 API 设计有点绕。它要传一个 reducer 风格的函数,返回值是 [state, action, isPending] ,跟传统 hook 习惯不太一样。 pending 是后加的,之前还得自己包一个 transiti
本地 @/ 路径别名跑得好好的,推到 Vercel 构建直接报 "Cannot find module '@/lib/db'"。tsconfig 里 paths 配了, baseUrl 也写了,VS Code 不报错。 折腾半天发现要么是 .gitignore 漏了某个 exte
Next.js 15 把 Turbopack 标记 stable,dev 性能确实猛。但我的非 Next 项目(纯 Vite + React)用不上 Turbopack,犹豫要不要迁。 实际对比: Turbopack:仅限 Next 生态,dev 飞快,但插件生态不如 Vite。
接手一个内容站,LCP 4.2s,用户反馈巨卡。三个月逐步压到 1.5s,记录下关键手段。 字体改 self host + font display: swap,省了 600ms。 首屏图片用 next/image + priority,LCP 元素提前加载。 第三方脚本(统计、
团队在吵要不要全面上 next/image 。它确实解决了懒加载、格式转换、尺寸适配,但代价也不小: 必须配 loader,自托管图片要走 sharp,构建慢。 第三方图片要配 remotePatterns,CSP 也要调。 老页面批量改造工作量大。 我的结论:内容站、图片多的电