我用 Claude Code 写 Next.js 的工作流
分享下我现在的日常流程,不一定最优,但用着顺手。 新功能先让它在 plan 模式下出方案,我确认后再 apply;Server Action 这种容易出错的,强制它先写一个测试用例再写实现;样式部分我手写,不让它碰 Tailwind 类名(它审美不太行)。 最后一步永远是跑 pn
这里聚合 CodeNodeX AI 社区中与 Next.js 相关的技术文章和讨论,覆盖概念解释、工具对比、工程实践、常见问题和独立开发经验。
如果你正在研究 Next.js,建议先阅读高质量长文,再参与帖子讨论,形成从理解到实践的完整路径。
分享下我现在的日常流程,不一定最优,但用着顺手。 新功能先让它在 plan 模式下出方案,我确认后再 apply;Server Action 这种容易出错的,强制它先写一个测试用例再写实现;样式部分我手写,不让它碰 Tailwind 类名(它审美不太行)。 最后一步永远是跑 pn
把一个 Pages Router 项目分批迁到 App Router,前后折腾了快半年。最大的感受是:缓存边界和 "use client" 这两件事,文档轻描淡写,实际占了 80% 的坑。 中间遇到过几次经典翻车: 客户端组件里直接 fetch ,被默认缓存导致数据不刷新。 pa
看了不少文章,还是没完全 get 到 RSC 的核心价值。表面说是 "组件在服务端跑",但 SSR 不也能在服务端跑组件吗? 我自己理解下来,主要差在两点:RSC 是 "按组件粒度" 决定跑在哪,并且它能直接访问数据源,不用再走一层 API。组件树里零 JS 下发到客户端这点确实
App Router 里用 useSearchParams 拿 query 参数,本地 dev 没事,prod 一打开就报 hydration mismatch,浏览器控制台一片红。 查了一圈说是它会让页面退化成客户端渲染,需要包一层 <Suspense 。包了之后报错没了,但首
针对响应式布局在“修复只在真实浏览器出现的问题”里的落地问题,本文用键盘操作记录检查越界修改,并邀请社区比较不同取舍。
用合成案例讨论组件契约:当“将人工流程变成可验证脚本”碰到模型总是改到无关文件,如何留下键盘操作记录并保留人工决策点。
这条Web 开发种子内容关注缓存失效的工程闭环,覆盖“将人工流程变成可验证脚本”中的越界修改、验收门槛和失败恢复。
团队里在推 RSC 直接调 Prisma 查数据,省掉一层 API route。但我心里一直有个疑问:这样写会不会把数据库 schema 间接带到客户端 bundle 里? 我试了下,只要不在 client component 里 import 那些查询函数,Prisma 的代码
项目里把表单提交全换成了 Server Actions,整体真香,但坑也不少。最大的爽点是省了 API route、省了手写 fetch,form 提交后直接拿到新数据重渲染。 不爽的地方: 错误处理有点别扭, useActionState 的返回值结构要自己约定。 上传文件场景
一个内容站,详情页用 ISR, revalidate 设成 60 秒。大部分页面 OK,但有些带多个 tag 的聚合页经常好几分钟都不更新。 后来发现是 CDN 层的 s maxage 把它兜住了,ISR 这边其实早就重新生成了,但边缘节点没回源。把 Cache Control
Next 15 的缓存四件套——Data Cache、Full Route Cache、Router Cache、Request Memoize——文档看完了还是分不清。经常出现 "改了数据但页面没变" 或 "登录态串了" 的情况。 我自己总结了一个粗暴的判断法: 跨请求共享的数
动态路由 [slug] 这块, generateStaticParams 决定哪些路径在 build 时预生成, dynamicParams 控制其它路径能不能按需生成。这俩参数配合起来我一直没整明白。 试出来的结论: dynamicParams: true (默认):没列出来的