Next.js 的 August 2026 Security Release 已经发布。对使用 Next.js 的团队来说，安全版本的价值不只在于把依赖版本号改大，更在于确认应用实际解析到的版本、验证构建与运行时行为，并让升级结果能够持续进入后续发布流程。
先确认项目当前使用的版本
不要只看 package.json。如果项目使用了 lockfile、工作区或间接依赖，最终安装版本可能与声明范围不同。可以在项目根目录执行：
node --version
npm ls next --depth=0
npm outdated next
如果使用 pnpm 或 Yarn，可分别运行：
pnpm why next
yarn why next
这些命令用于确认当前版本、依赖来源以及是否存在可用更新。来源摘要只确认 August 2026 security release 已可用，具体修复内容和受影响版本范围应以该版本的官方公告及项目依赖工具报告为准。
采用安全版本时要检查什么
升级前，先在分支上记录当前构建结果，并保留 lockfile 的变更。一个可改造的 npm 流程如下：
git switch -c chore/upgrade-nextjs-security
npm install next@latest
npm install
npm ls next --depth=0
npm run lint
npm run build
npm audit --omit=dev
next@latest 是一个实践示例，并不等同于来源中指定的安全版本。如果团队需要严格控制变更，应先根据安全公告选择明确版本，例如：
npm install next@<approved-version>
npm install
npm run build
将 <approved-version> 替换为团队审核通过的版本。若项目使用 package-lock.json，应把 lockfile 一并提交；CI 中则应使用 npm ci，确保测试使用提交后的解析结果。
把升级验证放进 CI
安全升级容易在本地完成、在流水线中失效。可以将下面的检查加入 CI 脚本：
name: Next.js security verification
on:
pull_request:
push:
branches: [main]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm ls next --depth=0
- run: npm run lint
- run: npm run build
- run: npm audit --omit=dev
示例中的 Node.js 版本只是可调整的假设，应该替换为项目已经支持并在生产环境使用的版本。若 npm audit 因其他依赖报告问题，不要直接使用 npm audit fix --force 覆盖整个依赖树；先区分 Next.js 相关问题与无关问题，再逐项评估破坏性升级风险。
升级后的重点回归范围
至少验证以下路径：
- 生产构建是否成功，且没有新增的编译或类型错误。
- 页面路由、动态路由和错误页是否仍能正常响应。
- 服务端渲染、静态生成以及客户端导航是否符合预期。
- 中间件、认证、重写和重定向规则是否保持原有行为。
- Image、字体、环境变量和外部 API 调用是否没有被升级影响。
- 容器或托管平台中的启动命令、缓存策略和 Node.js 运行时是否一致。
这些检查不代表来源公告列出的具体修复范围，而是面向生产升级的通用验证边界。安全版本可能只改变少量依赖，但它仍然会经过编译、部署和流量入口，因此不能只依赖安装命令的退出码。
一份可执行的落地清单
- 阅读 August 2026 安全公告，确认受影响版本和推荐版本。
- 用
npm ls next、pnpm why next或yarn why next确认实际解析版本。 - 在独立分支升级
next及必要的 lockfile 内容。 - 运行 lint、构建、关键路由测试和依赖审计。
- 在预发布环境验证认证、中间件、渲染和部署启动流程。
- 合并后观察错误率、响应状态和构建产物，再安排生产发布。
对于直接暴露在公网的 Next.js 应用，升级优先级通常应高于普通功能迭代；但具体紧急程度仍取决于公告中的影响范围、应用是否启用了相关功能，以及团队的发布和回滚能力。