Next.js 已发布 2026 年 7 月安全更新。由于来源摘要没有提供受影响版本、漏洞编号和修复版本范围，团队不应凭经验猜测风险边界；更稳妥的做法是先核对项目实际依赖与官方公告中的版本要求，再完成升级、回归测试和生产发布。
先确认项目真正运行的版本
不要只查看 package.json 中声明的版本。锁文件、工作区依赖和容器缓存都可能让实际安装版本与声明不一致。进入项目目录后，可以运行：
node --version
npm --version
npm ls next react react-dom
如果项目使用 pnpm 或 Yarn，则改用对应命令：
pnpm why next
# 或
yarn why next
同时检查直接依赖和已知问题：
npm outdated next react react-dom
npm audit
npm audit 只能识别其漏洞数据库已经收录的问题，不能替代安全公告。判断是否受影响时，应以公告列出的 Next.js 版本区间、部署模式和缓解条件为准。
用独立分支完成升级
来源摘要没有给出具体安全版本号，因此下面用环境变量代替硬编码版本。运行前，请把 NEXT_SECURITY_VERSION 设置为公告明确标记的已修复版本：
export NEXT_SECURITY_VERSION="<fixed-version>"
git switch -c security/nextjs-july-2026
npm install --save-exact "next@${NEXT_SECURITY_VERSION}"
npm ls next
npm test
npm run build
如果仓库使用 pnpm：
export NEXT_SECURITY_VERSION="<fixed-version>"
pnpm add --save-exact "next@${NEXT_SECURITY_VERSION}"
pnpm test
pnpm build
提交时应同时纳入 package.json 和锁文件。不要只修改版本声明而保留旧锁文件，否则 CI 和生产环境可能继续解析到旧依赖。
升级 Next.js 时还要核对其配套的 React 与 React DOM 要求。若包管理器报告 peer dependency 冲突，应根据目标 Next.js 版本的兼容范围调整依赖，而不是使用 --force 或 --legacy-peer-deps 静默绕过。
增加一组可执行的安全回归检查
安全补丁也可能改变请求解析、缓存、路由或服务端渲染行为。可以这样实践：在 CI 中启动生产构建，并验证公开页面、API、鉴权页面和异常输入。
下面的脚本假设应用提供 /、/api/health 和 /account。请按项目实际路由修改：
#!/usr/bin/env bash
set -euo pipefail
npm ci
npm run build
npm run start -- --hostname 127.0.0.1 --port 3000 > /tmp/next.log 2>&1 &
APP_PID=$!
trap 'kill "$APP_PID" 2>/dev/null || true' EXIT
for _ in $(seq 1 30); do
if curl --fail --silent http://127.0.0.1:3000/api/health >/dev/null; then
break
fi
sleep 1
done
curl --fail --silent --show-error http://127.0.0.1:3000/ >/dev/null
curl --fail --silent --show-error http://127.0.0.1:3000/api/health >/dev/null
status=$(curl --silent --output /dev/null --write-out '%{http_code}' \
http://127.0.0.1:3000/account)
case "$status" in
200|302|303|307|308|401|403) ;;
*) echo "Unexpected /account status: $status"; exit 1 ;;
esac
echo "Next.js production smoke tests passed"
这组检查不能证明漏洞已经不可利用，但能尽早发现升级造成的启动失败、路由异常和鉴权回归。对于使用 App Router、中间件、Server Actions、图片优化、重写规则或自定义服务器的项目，还应覆盖这些实际入口。
发布时避免“升级成功、实例未更新”
如果应用通过容器部署，应从干净环境重建镜像，并在镜像内核对版本：
docker build --no-cache -t my-next-app:security-2026-07 .
docker run --rm my-next-app:security-2026-07 npm ls next
生产发布建议采用灰度或分批滚动方式，重点观察：
- HTTP 5xx、启动失败和容器重启次数；
- 登录、会话刷新、权限校验和重定向；
- 服务端渲染、缓存命中率及响应时间；
- CDN、反向代理与 Next.js 缓存头之间的变化；
- 构建产物是否确实来自更新后的锁文件。
若无法立即升级，可以根据安全公告评估临时缓解措施，但应设置明确的失效日期。WAF 规则、路由禁用或流量限制通常只能降低暴露面，不能代替安装修复版本。
落地清单
一次完整的 Next.js 安全更新至少应包括：确认实际版本、对照公告判断影响、升级到明确修复版本、提交锁文件、执行生产构建、回归关键请求路径、重建部署产物，以及监控上线后的错误和性能指标。
由于当前来源信息非常简短，最重要的边界是不要自行推断 CVE、受影响组件或修复机制。把版本证据、测试结果和部署记录留在变更单中，后续审计时才能说明哪些服务已经完成修复，哪些服务仍需处理。