Next.js App Router
保持应用支持的版本和配置。在适合的情况下优先使用服务器端渲染和直接服务器端读取，在需要的地方保留交互式和实时浏览器行为。
建立上下文
检查 package.json、锁定文件、路由文件夹、next.config.* 和项目说明。识别已安装的 Next.js/React 版本、App Router 与 Pages Router 状态、运行时/部署约束，以及是否启用了 Cache Components。在 monorepo 中，从受影响的应用中解析这些信息。不要仅仅为了适配示例而升级包或启用功能。
在 Next.js 16.2+ 中，优先使用 node_modules/next/dist/docs/ 中捆绑的版本匹配文档（如果可用）。否则，查阅支持版本的官方文档。在线文档可能描述较新的次要版本；在使用前确认 API 版本历史和配置。区分稳定 API、实验性选项、弃用项和项目约定。
选择相关资源
只读取任务所需的资源；当版本或行为不确定时，遵循其官方链接。
| 任务 | 资源 |
|---|---|
| 服务端/客户端边界、组合、序列化 | Server Components |
| 读取、流式传输、浏览器数据、操作、HTTP 端点 | Data fetching |
| 现有缓存模式、Cache Components、私有/远程缓存、失效 | Caching |
| 布局、动态路由、搜索、并行/拦截路由 | Routing |
| 请求重定向/重写和乐观身份验证门控 | Proxy |
| 预期错误、加载、恢复、404 响应语义 | Error handling |
| 元数据导出、继承和 SEO 集成 | Metadata |
| 图片/字体配置和加载权衡 | Assets |
| 增量 Pages 到 App 的迁移 | Migration |
| 计划的主/次要升级 | Version changes |
优先决策
- 保护秘密和用户数据。在数据附近对读取/变更进行身份验证和授权，验证不受信任的输入，确保个人数据不会进入错误共享的缓存。代理和 UI 可见性不足以作为授权。
- 跨版本和渲染模式保持正确性。异步请求 API、缓存前提条件、路由约定和恢复属性依赖于已安装的版本/配置。
- 消除已演示的瀑布流和不必要的客户端代码。并行化独立工作；选择保留有用 UI 的 Suspense 边界。客户端获取仍适用于轮询、仅浏览器状态和交互式更新。
- 根据新鲜度、部署和实测行为调整缓存、预取和资源提示。这些是可选项，而非每个 App Router 应用的必备条件。
对仅服务器端的工作使用 Server Components。在有用的模块边界处添加 'use client' 以实现交互；它不必是叶子节点。对 UI 变更使用 Server Action（如果合适），或对 HTTP 契约（包括浏览器客户端）使用 Route Handler。两者都不能替代授权。
验证实际变更
在可用时运行受影响应用的现有类型检查、lint 和构建命令。测试可能失败的行为：认证后的直接请求、跨用户隔离、变更后的数据新鲜度、硬/软导航、错误和加载。不要将导入、认证辅助函数或持久化只是占位符的片段称为生产就绪。说明已运行和未测试的内容。
对于审核，首先指出可操作的问题及其版本/配置范围。将可选改进与正确性问题分开。对于实现，解释所选的边界/缓存模式、变更的行为和验证。
来源审核是有范围的，而非全面认证。请参阅 SOURCES.md 获取规范链接、适用版本/配置、已检查部分、上游日期和新鲜度政策。仓库的试点审核/评估记录是维护证据，运行时不需要。