Next.js 已发布 2026 年 9 月安全更新。对生产项目来说，看到“安全发布”后最重要的动作不是直接执行一次 npm update，而是确认受影响范围、锁定修复版本、重新构建产物，并用可回滚的方式完成部署。
目前给出的摘要没有列出具体 CVE、受影响版本或最低安全版本，因此本文不会猜测漏洞细节。实际操作时，应以该安全公告及对应版本说明中列出的修复版本为准。
先弄清项目实际运行的是哪个版本
不要只看根目录 package.json 中的版本范围。锁文件、工作区和间接依赖都可能导致安装结果与预期不同。
在项目根目录执行：
node --version
npm --version
npm ls next --all
npm explain next
如果使用 pnpm 或 Yarn，可以分别执行：
pnpm list next --depth Infinity
pnpm why next
yarn why next
需要重点记录以下信息：
- 当前实际安装的 Next.js 版本，而不仅是
package.json中的版本范围； - 仓库是否包含多个 Next.js 应用；
- 是否有内部模板或共享包固定了旧版本；
- 生产镜像中的版本是否与主分支锁文件一致；
- Node.js 版本是否满足目标修复版本的运行要求。
如果是 monorepo，应在每个应用的部署边界内检查一次。根目录只出现一个锁文件，并不代表所有应用都使用同一个 Next.js 版本。
把安全升级做成一次可复现的变更
从公告中确认修复版本后，可以通过环境变量执行下面的升级流程。运行前，将 PATCHED_VERSION 替换为安全公告明确给出的版本，不要默认它一定等于 npm 上最新的主版本。
set -euo pipefail
export PATCHED_VERSION="替换为公告指定的修复版本"
if [ "$PATCHED_VERSION" = "替换为公告指定的修复版本" ]; then
echo "请先设置 PATCHED_VERSION" >&2
exit 1
fi
npm install --save-exact "next@${PATCHED_VERSION}"
npm ls next --all
npm run lint --if-present
npm run test --if-present
npm run build
使用 pnpm 时，核心升级命令可以改为：
pnpm add --save-exact "next@${PATCHED_VERSION}"
pnpm list next --depth Infinity
pnpm lint
pnpm test
pnpm build
这里建议使用精确版本，目的是让安全变更在代码审查、CI 和回滚时更容易确认。团队若已有统一的版本范围策略，也可以继续使用，但必须提交更新后的锁文件。
升级提交至少应包含：
package.json
package-lock.json # 或 pnpm-lock.yaml / yarn.lock
不要只修改清单而保留旧锁文件，也不要只在服务器上手工安装新版本。后一种做法会让生产环境与源码失去对应关系。
CI 不只要检查“能否编译”
安全修复可能落在请求处理、路由、构建或运行时逻辑中。仅通过 TypeScript 编译并不足以证明应用可以安全发布。可以在现有 CI 中增加一个明确的版本检查步骤。
下面是一个可改造的 GitHub Actions 示例。假设项目使用 npm，并已在 package.json 中提供测试与构建脚本：
name: verify-nextjs-security-update
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-file: .nvmrc
cache: npm
- name: Install locked dependencies
run: npm ci
- name: Print resolved Next.js versions
run: npm ls next --all
- name: Lint
run: npm run lint --if-present
- name: Test
run: npm run test --if-present
- name: Production build
run: npm run build
合并前还应覆盖项目自己的关键路径，例如：
- 首页、动态路由和 API 路由是否正常；
- 服务端渲染页面是否能够成功返回；
- 登录、会话和权限检查是否符合预期；
- 中间件、重写和重定向规则是否仍然生效；
- 图片、静态资源及 CDN 缓存是否正常；
- serverless、Edge 或 Node.js 部署目标是否都完成验证。
npm audit 可以作为补充信号，但不能替代安全公告中的版本判断。漏洞数据库可能存在同步延迟，而且框架公告中的适用条件通常比一条扫描结果更具体。
修复只有部署后才真正生效
锁文件合并并不等于生产系统已经修复。Next.js 应用通常需要重新安装依赖、重新构建，并部署新的镜像或平台产物。
对于容器化项目，可以在部署后直接核对镜像内的版本：
docker run --rm your-app-image:patched \
node -p "require('next/package.json').version"
Kubernetes 环境中，也可以对新 Pod 进行检查：
kubectl exec deploy/your-nextjs-app -- \
node -p "require('next/package.json').version"
kubectl rollout status deploy/your-nextjs-app
将 your-app-image:patched 和 your-nextjs-app 替换为实际镜像及 Deployment 名称。若生产镜像为了减小体积而没有保留可读取的包元数据，可以在构建阶段把 Next.js 版本写入镜像标签或应用的内部诊断端点。
上线时优先采用分批发布：先让少量流量进入新版本，观察 5xx、启动失败、延迟、路由错误和登录异常，再扩大流量。回滚方案应指向上一份可部署镜像，而不是在生产容器里临时降级依赖。
一份适合团队执行的升级清单
- 阅读 2026 年 9 月安全公告，记录受影响范围和修复版本；
- 枚举仓库及生产环境中所有 Next.js 实例；
- 更新依赖清单和锁文件，不进行无关的大规模依赖升级；
- 运行 lint、测试、生产构建和关键路径冒烟测试；
- 重新构建所有相关镜像、serverless 包及静态产物；
- 通过灰度或分批策略部署，并监控错误率与延迟；
- 在运行环境中验证实际加载的 Next.js 版本；
- 保留上一版本产物和清晰的回滚步骤；
- 升级内部模板，避免新项目继续生成旧依赖。
安全更新追求的是缩短暴露窗口，而不是盲目追求最快合并。最稳妥的节奏是：快速确认影响、创建范围单一的升级提交、自动化验证、分批上线，并在生产环境再次核对版本。