Next.js 计划在 2026 年 9 月 22 日发布一次关键级别的带外安全更新，目标版本为 Next.js 16.3.6 和 15.5.26。这次更新与一个关键上游问题有关，不在常规发布节奏内，因此使用对应主版本的团队应提前完成资产盘点、升级演练和发布窗口安排。
目前已知信息有限，不应根据“关键”二字自行推断漏洞的影响范围、利用条件或受影响组件。更稳妥的做法是：先确认哪些应用正在使用 Next.js，等版本正式进入包仓库并公布说明后，再根据官方信息确定优先级和缓解措施。
先找出真正运行中的 Next.js 版本
不要只检查仓库根目录的 package.json。Monorepo、历史分支、独立部署目录和容器镜像中，都可能保留不同版本。
在单个项目中，可以先执行：
npm ls next --all
node -p "require('./node_modules/next/package.json').version"
第一条命令展示依赖树中的 Next.js，第二条命令输出当前安装到 node_modules 的实际版本。若依赖尚未安装，应先使用与锁文件匹配的包管理器执行安装。
对于包含多个应用的代码仓库，可以在仓库根目录运行下面的 Bash 脚本，列出所有声明了 Next.js 的 package.json：
find . -name package.json -not -path '*/node_modules/*' -print0 |
while IFS= read -r -d '' file; do
node -e '
const pkg = require(process.argv[1]);
const version = pkg.dependencies?.next ?? pkg.devDependencies?.next;
if (version) console.log(`${process.argv[1]}\t${version}`);
' "$file"
done
这只能完成源码侧盘点。还应对照部署平台和镜像仓库，记录以下信息：
- 应用、仓库及负责人；
- 生产环境实际部署的镜像标签或提交号；
- Next.js 主版本与锁文件类型；
- 是否允许在 9 月 22 日附近安排紧急发布；
- 回归测试、灰度发布和回滚是否可用。
版本尚未发布时，不要制造“已修复”的假象
由于公告描述的是计划中的版本，在包仓库出现正式版本之前，不应手工修改锁文件、使用来源不明的补丁包，也不要把仅修改 package.json 的提交视为完成修复。
发布窗口到来后，可以先确认目标版本是否已经可用：
npm view next@16.3.6 version
npm view next@15.5.26 version
命令成功返回对应版本号后，再根据项目所在的主版本选择其中一个升级路径，而不是随意跨越主版本：
# Next.js 16.x 项目
npm install --save-exact next@16.3.6
# Next.js 15.x 项目
npm install --save-exact next@15.5.26
如果团队使用 pnpm 或 Yarn，应继续使用原有包管理器，避免在紧急升级中生成第二种锁文件：
# pnpm，二选一
pnpm add --save-exact next@16.3.6
pnpm add --save-exact next@15.5.26
# Yarn，二选一
yarn add --exact next@16.3.6
yarn add --exact next@15.5.26
执行后应提交 package.json 和对应锁文件，并在干净环境重新安装，确认 CI 与生产构建使用的是同一份解析结果。
把升级验证做成一条可重复的流水线
安全修复需要速度，但不能跳过构建和运行时验证。可以把下面的命令作为最小升级检查基线；其中 test、lint 等脚本应按项目实际情况调整：
set -euo pipefail
npm ci
npm ls next --all
npm run lint
npm test --if-present
npm run build
构建成功并不代表应用行为完全正常。建议至少覆盖：
- 首页及关键动态路由能否正常渲染；
- API Route 或 Route Handler 的成功与失败路径；
- 中间件、重定向、鉴权和会话流程；
- 服务端渲染、缓存及静态资源加载；
- 容器启动、健康检查和关闭流程。
这些项目是升级验证建议，并不意味着当前已知的上游问题一定影响这些功能。待正式安全说明发布后，还应增加针对实际漏洞面的测试。
上线时优先控制暴露时间，同时保留止损能力
对于关键带外更新，理想流程不是“看到版本后直接全量上线”，也不是等待完整常规发布周期，而是提前准备、版本可用后快速验证，再通过灰度降低风险。
可以采用以下发布顺序：
- 在预生产环境使用生产构建参数重新构建，而不是复用开发构建。
- 运行冒烟测试并核对实际安装的 Next.js 版本。
- 先向少量实例或流量发布，观察错误率、延迟、重启次数和关键业务指标。
- 指标稳定后扩大流量，并保留旧镜像用于紧急止损。
- 如果确需回滚，应同步评估恢复到旧版本后重新暴露安全风险的时间，不能把回滚当作长期方案。
还要注意，2026 年 9 月 22 日是计划日期，具体发布时间可能受时区或发布安排影响。自动化任务可以负责检测新版本，但生产升级最好仍保留人工确认，以核对正式公告、包来源和适用范围。
升级前检查清单
- [ ] 已找到所有 Next.js 应用及生产部署版本；
- [ ] 已确认项目属于 16.x、15.x，还是其他版本线；
- [ ] 已为 16.3.6 或 15.5.26 建立升级分支和发布窗口；
- [ ] 未在正式版本发布前伪造锁文件或使用未经验证的包；
- [ ] CI 能完成干净安装、测试和生产构建；
- [ ] 关键页面、接口、中间件和鉴权流程已有冒烟测试；
- [ ] 灰度、监控、回滚及安全风险接受人已经明确；
- [ ] 正式说明发布后，会重新核对受影响范围和额外缓解措施。
这类带外更新最考验的不是一条安装命令，而是团队能否迅速回答三个问题：哪些服务受影响、怎样证明升级有效、出现回归时如何控制损失。现在完成这些准备，才能在目标版本正式发布后缩短暴露窗口，而不是临时在生产环境中寻找答案。