Frontend & Mobile Engineering Weekly：Next.js 紧急修复两处 RCE，pnpm 12 正式发布

这周需要立即处理的事情很明确：自托管 Next.js 项目先检查版本并升级。工具链这边，pnpm 12 结束 RC，Flutter 3.47 也到了第二个 hotfix；两者都适合开始进入正式升级评估，但升级前要看清各自改动的边界。

Next.js 在 8 月 25 日提前发布了原定次日进行的安全更新，16.3.3 和 15.5.24 (opens in a new window) 修复两处 Critical 级别漏洞。第一处是 Windows 文件系统上的路径处理问题，影响运行在 Windows 上的部分 Pages Router 和 App Router 部署；第二处位于 Image Optimization 的 AVIF 处理链，攻击者在能够让服务端处理恶意 AVIF 时可能实现未认证远程代码执行。加拿大网络安全中心随后也发布了安全公告 (opens in a new window)，要求受影响版本尽快升级。

这次不能只看服务器是不是 Linux。Windows RCE 有明确的平台限制，但 AVIF 问题来自图片处理路径，自托管 Linux 服务如果使用 Next.js Image Optimization 处理不可信 AVIF，同样需要升级。Next.js 15.5 应至少到 15.5.24，16.3 应至少到 16.3.3；更老且落在受影响范围内的版本，需要按官方支持分支安排升级，而不是尝试长期靠代理规则绕过。

托管平台的实际暴露面可能不同。例如 Netlify 说明其平台不走受影响的 Next.js AVIF 优化代码路径，Windows 问题也不适用，但仍建议升级到修复版本 (opens in a new window)。对团队来说，版本升级是第一步，随后还应确认生产环境究竟由谁负责图片处理：Next.js 自身、CDN、平台 Image CDN，还是自建服务。这个答案决定了以后类似上游原生依赖漏洞应该由哪一层负责响应。

Reddit 的 Next.js 社区在补丁发布当天很快开始集中讨论这两处漏洞，但社区信息没有增加新的影响范围；目前应以官方 advisory 和部署平台说明为准。

pnpm 12.0.0 (opens in a new window) 在 8 月 26 日结束 RC 阶段，三天后又发布了 12.1.0。12 的变化不少，其中对已有项目最容易产生实际影响的仍是 Git dependency：GitHub、GitLab、Bitbucket 上同一仓库的 github:owner/repo、git+https、git+ssh 等写法现在按“仓库身份”处理，并统一通过 canonical HTTPS URL 解析，lockfile 不再记录这些托管平台的 SSH URL。

如果仓库依赖私有 Git package，而且 CI 过去依靠 SSH deploy key 工作，升级时应专门验证安装链路。不能因为 package.json 里仍写着 git+ssh 就假设 pnpm 12 会继续按旧方式连接。需要 SSH 的环境可以通过 Git URL rewrite 处理，但这属于机器和 CI 配置，最好明确写进基础设施，而不是继续依赖包管理器的隐式行为。

另一个容易被忽略的变化发生在 RC 末期：pnpm-workspace.yaml 中无法识别的设置不再静默忽略。过去 minimumReleaseAge 一类策略字段如果拼错，安装仍可能继续，只是策略实际上没有生效；12 会把这种配置错误暴露出来。这个行为对 CI 是好事，但也意味着老仓库第一次升级可能先遇到配置清理。

12.1.0 又调整了 pnpm login / adduser 的 token 和 scope 存储行为，并开始保存经过验证的远程构建产物。pnpm 12 已经可以进入真实项目的升级分支，不过 Monorepo、私有 registry、私有 Git dependency 和自定义 .npmrc 较多的仓库，不适合只跑一次 pnpm install 就合并。至少比较 lockfile、--frozen-lockfile、CI 认证和 workspace 全量 build/test。

Flutter 在本周发布 3.47.2 hotfix (opens in a new window)。这一版修复了几项很具体的平台问题：Swift Package Manager 开启后 iOS/macOS 构建失败、Xcode 27 下 add-to-app Swift package 构建失败、Windows external texture 绘制崩溃、Linux touch event 内存泄漏，以及 libpng 安全更新。Windows hot reload、桌面 --build-name / --build-number 传递和 symbolizer 也有修正。

如果项目已经在 3.47.0/3.47.1，升级到 3.47.2 的理由比较充分，特别是用了 SwiftPM、Windows external texture 或桌面端的项目。仍在 3.44 的项目则不能把 3.47.2 当成普通 patch：3.47 本身包含最低 Apple 平台版本、Material/Cupertino 拆分、桌面 Impeller 等更大的迁移边界，原有升级回归清单仍然需要执行。

本周新开的 GitHub issue 也暴露了两个尚未进入 3.47.2 changelog 的 Web 风险。#191800 (opens in a new window) 给出了 CanvasKit 下 HTML image-backed ui.Image 被释放后，已录制 ui.Picture 可能显示黑图的可复现案例，报告确认 3.47.0 和 3.47.1 受影响；cached_network_image 默认 Web HTML image 模式也在报告的影响范围内。#191976 (opens in a new window) 则报告了一个 --wasm 下可复现的 Chrome 崩溃案例。两者目前都只能视为已报告、可复现的特定场景，不能扩大成“Flutter Web 3.47 不稳定”的结论。

对于 Flutter Web 项目，升级 3.47 后如果使用 cached_network_image、自定义图片 codec、CanvasKit 或 Wasm，建议把长列表图片缓存回收和 CustomPainter 滚动场景加入回归测试。移动端项目不需要因为这些 Web issue 暂缓 3.47.2。

Node.js 24.20.0 LTS (opens in a new window) 于 8 月 26 日发布。这次没有需要大多数前端项目立即改代码的 breaking change，但有几项值得基础设施和 CLI 工具作者关注：AsyncLocalStorage 增加 using scope，Permission Model 新增 permission.drop 和 --permission-audit，loader 加入 package maps，Node test runner 增加 context.log()，JSPI 也在 Wasm 侧启用。

普通 Web 项目如果已经固定在 Node 24 LTS，可以按常规 minor upgrade 处理。真正有价值的是权限模型逐渐从“限制进程能做什么”补到“审计和主动放弃权限”：对运行插件、脚本、代码生成器或 Agent 工具的 Node CLI，这比业务前端更值得跟进。不过这些 API 刚进入 24.20，不需要为了它们主动改造现有沙箱方案。

本周的 JavaScript Weekly 把 Bun 1.4 放在头条。Bun 1.4 实际发布于 8 月 20 日，不属于本周事件，但它和本周另外两个信号放在一起看更有价值：pnpm 12 正式版继续扩大 runtime、registry 和构建产物管理范围；Laravel 官方 starter kits 在 8 月 28 日开始采用 Vite+，把原来分散的 build、lint、format 等工具进一步集中到统一 CLI。

Vite+ (opens in a new window) 目前仍处于 beta，因此 Laravel starter kit 的采用更适合作为生态信号，而不是成熟度证明。新项目可以评估它减少 ESLint、Prettier、Vitest 等独立配置的收益，已有大型项目暂时没有必要为了“统一工具链”重写现有工程配置。工具数量减少确实能降低配置面，但 lint rule、formatter 行为、插件兼容和 CI 可观测性是否同样成熟，还需要真实项目验证。

Bun 1.4 (opens in a new window) 也继续扩大这种边界：除了 runtime、package manager、bundler 和 test runner，又加入 image、headless browser、Markdown、cron、PTY 等原生 API，并大幅增加 Node.js compatibility test。官方给出的性能和内存数据来自自己的 benchmark，适合用来决定“值不值得测”，不能直接当成迁移后的生产收益。社区里也有维护者反馈 1.4 解决了过去的 Node compatibility 问题，同时仍有人指出部分原生 API 与原库行为存在差异。

对长期项目，我仍倾向于把这类一体化工具当成替换候选逐项验证，而不是一次性接管全部工具链。新项目的试错成本低，可以更积极一些。

iOS Dev Weekly 8 月 28 日的第 765 期 (opens in a new window) 把一个近期很现实的问题放到了开头：不少维护多年 iOS App 的团队正在集中从 UIApplicationDelegate 迁移到 UISceneDelegate，因为 27 SDK 已经把 scene lifecycle 变成硬性要求。这不是本周才出现的平台政策，但随着 Xcode / SDK 27 的发布时间接近，存量项目开始真正处理历史生命周期代码。

Flutter 3.47 已经提供 UIScene migration 支持，但原生 SDK 较多的 Flutter App 仍值得检查 AppDelegate 中的 push、deep link、支付、登录和第三方初始化逻辑。纯 Swift/UIKit 项目则应尽早把生命周期迁移和 Xcode 27 升级拆开验证，避免发布前同时处理编译、启动和业务回调问题。

这周优先级最高的是 Next.js 安全更新：只要项目落在受影响版本，先升级，再根据 Windows 部署、Image Optimization 和托管平台判断实际暴露面。pnpm 12 已经结束预发布阶段，可以进入升级评估，但私有 Git、registry 和 workspace 配置需要专项验证。

Flutter 3.47.2 适合已经进入 3.47 系列的项目跟进，SwiftPM 和桌面 external texture 用户尤其应该升级。Web 端新出现的图片缓存和 Wasm issue 目前证据边界比较清楚，相关项目加回归测试即可，不需要扩大成整个 3.47 系列的阻断项。