2026年11月7日博客

PRNext 0.1.21：精简 Flight，优化启动与构建

PRNext

PRNext 0.1.21-alpha 已在 npm 发布。???着重减少可以避免的工作，同时保持应用的渲染结果不变。渲染进程可以在首次动态请求前准备框架，构建可以复用经过验证的小型摘要，而不必反复解析未修改的文件。缓存中的原始类型结果采用紧凑的内部格式，复杂 React 值仍由官方 Flight 解码器处理。

本版本还加强了公共请求、直接连接的代理和本地控制服务之间的边界。这些改进建立在 0.1.20 之上，并未引入跨用户的响应缓存。应用仍需负责授权、数据有效期和自身的部署流程。

在首次动态响应前准备每个渲染进程

显式启用 --prewarm 后，每个渲染进程都会准备框架；替换进程和从空闲状态唤醒的进程也会执行相同准备。初始总预算为 15 秒，同时最多进行两项准备。一个小型内部 RSC 与 HTML 模型会运行官方渲染链路，不导入应用路由，也不读取账户数据。

初始就绪状态会等待准备完成，但应用模块导入、数据库连接和请求数据仍可能增加首次真实渲染的成本。后续替换进程若未完成准备，会记录诊断，并保留普通请求的按需加载方式。按需启动仍是默认行为，失败的应用请求不会因此重放。评估时应测量启动加首次动态响应，而不是把静态文件可访问当作 React 已准备好的证明。

Terminal

npx --no-install prnext start --workers 2 --prewarm

减少同一份 Flight 响应外围的分配

Flight 传输消息封装与转移数组仅在各自响应内部复用，转移后释放对 buffer 的引用。较大的内联启动脚本直接编码到有界 buffer 中。其他数据结构延迟到确实需要时才创建，普通且完整的 HTML 片段则采用直接处理路径。

编码内容、base64 和 CSP nonce 的含义保持不变。取消、读取额度、对外部生产者数据的防御性复制以及响应隔离仍然有效。带引号的属性和有歧义的 HTML 继续走解析器。这些变化减少传输外围工作，并不允许把私人响应留给其他请求使用。

在检查器中查看 Flight 大小与渲染进度

按需启用的检查功能会按路由模式和渲染阶段汇总 Flight 字节、分块和结果，并区分完成、取消、失败及超时样本。观察到相应事件时，还会报告模型和 shell 就绪的里程碑。RSC 与 SSR 可能观察同一份载荷，因此不能把它们的大小或请求数相加。

这些时长包含应用工作与异步等待，并非编码器或解码器的独立 CPU 时间。缺失样本不会被当成零。诊断不保留响应正文、cookie、授权值或原始查询数据。可选的 GC、堆和事件循环指标提供另一种观察角度；关闭时不创建 GC 观察器。V8 默认配置和运维人员显式指定的选项保持不变。

Terminal

npx --no-install prnext start . --inspect
npx --no-install prnext inspect --json

复用构建事实，同时保留发现阶段的检查

重复构建可以复用有类型、有大小限制的 Oxc 摘要，保存后续阶段所需的指令和导出信息。这些不可变摘要不保留源代码文本、AST 或应用闭包。身份和代次检查仍会判断记录是否属于当前输入；缓存缺失或无效时，仍执行正常工作。

当依赖图已被证明不含原生代码时，原生依赖发现也可以复用限定范围的证明。未知副作用、自定义 hook 和变化的输入仍需检查，不会盲目重放不透明的整张图。参考应用和工具还包含选定的依赖更新，其中参考基线包括 Next 16.4.4、Better Auth 1.7.15 和 Redis 客户端 6.3.1。

限制文件工作，并呈现构建阶段

Standalone 追踪文件和框架运行时的复制采用有界并发、确定性的别名处理顺序以及准入预算。复制过程中源文件的变化仍可检测。若操作失败，已开始的写入会先结束，再丢弃临时输出区；上一次发布的构建得以保留。Pages 服务端分块及 source map 在首次写入前就在内存中完成改写。

build --timings 展示 React 构建阶段，帮助区分编译器慢点与文件工作。总时间不包含 CLI 模块启动，嵌套阶段还会重叠，不能简单相加。计时报告不进入部署清单或浏览器资源。

Terminal

npx --no-install prnext build --timings

让 React 继续管理缓存值和 PPR 续接

缓存回调仍在官方 React 渲染器中执行一次，包括其 React.cache 上下文。符合条件的原始类型结果使用紧凑、带版本的内部格式。对象、React 节点、函数和临时引用保留规范的 Flight 路径，普通复杂结果直接使用原始字节。包含 BOM、不完整 UTF-16 或接近渲染上限的字符串和值也保留官方 Flight 处理。

请求私有作用域、标签、TTL 和每次新解码的对象保持不变。这是结果编解码方式的调整，不是新的跨账户缓存。对于原生 PPR，只有重新验证当前产物字节及 SHA 后，才会复用有界、不可变的解析和前缀信息。可变续接状态按请求克隆。嵌套或非直接续接在需要时仍保留既有的规范化流程。

RSC 条目还采用新的键命名空间。升级后不会复用旧结果，最初的调用会重新填充符合条件的缓存，因此评估预热时也应考虑这部分成本。

让已放弃的开发请求退出编译队列

已取消或过期的开发请求不再让其排队中的编译需求继续存活。如果另一个调用方仍需要已经共享的编译，该编译保留自己的生命周期。这样可以避免只为断开的请求继续工作，又不会取消另一个标签页仍需要的构建。

开发 RPC 通知在首次被接受发布后继续作为权威来源。迟到的文件快照不能恢复已被 RPC 清除的诊断。建立 RPC 之前仍支持仅通过文件发送通知的回退方式，同时避免混入旧代次状态。

在开发模式中，连续导航与 Fast Refresh 也会协调各自的 Flight 流。尚未结束的响应可以让位于下一条路由，而不必恢复旧组件树并丢失共享 layout 的状态。这个改动仅用于开发导航的 GET 请求，不会重放数据修改；生产响应和 Server Actions 仍采用严格解码。配置 navigationCache.authCookies 跟踪会话 cookie 后，重新授权仍然优先，一个用户的草稿不会沿用到另一个用户。

Server Action 也可能在已应用更新等待确认时替换页面视图。Fast Refresh 现在会区分这种视图替换与更新本身被取消。真正的错误、取消和网络超时仍按失败处理，不会重新发送 Action。

这项开发集成与 PRNext 验证的 React 版本绑定，使用了 Flight 客户端的实验性选项，但不会在生产模式启用这一行为。

使用相同产物验证 Node 26

Linux CI 增加了 Node 26 的运行时与 HTTP、Chromium、SaaS 消费者和包安装检查，覆盖提升与嵌套安装布局。这里的浏览器覆盖指 Chromium，并不替代 Linux、macOS 和 Windows 的主矩阵，也不会替部署环境选择 Node 版本。

功能覆盖不能直接给出 Node 26 的吞吐量。比较运行时变化时，应使用相同的产物和依赖，再验证自己的应用流程。本次测试使用 Node 22.23.4，不把任何数值性能提升归于 Node 26。

按实际范围理解每项性能结果

这项受控对比在 Linux x64 和 Node 22.23.4 下，比较已发布的 0.1.20 源码与候选源码 7c15132a。每条路由有十二组配对，共 72 个测量窗口，使用两个 worker、可见的两 CPU 和 5 GiB 上限，并绑定这两个 CPU。每个窗口在两秒预热后测量十五秒，SSR、JSON API 和流式响应分别使用八、二、八个连接。

测量窗口内完成了 774,665 个有效响应，计入排空阶段后共 775,089 个。排空阶段的 424 个响应不计入吞吐量，HTTP、传输和验证错误计数均为零。预热单独统计：其窗口内完成 51,123 个响应，计入排空后共 51,552 个。

候选与基线的配对吞吐量比值中位数分别为 SSR 0.9944、JSON API 0.9941、流式响应 0.9978，对应的 p95 比值为 1.0361、1.0056、1.0028。报告中的所有配对区间都包含 1，满足预先固定的吞吐下降不超过 10%、p95 上升不超过 15% 的预算。这些接近基线的结果并不能证明普遍加速。

基线 JavaScript 归档与公开的 0.1.20 完全一致，候选归档与该源码的 Linux 验证归档一致。但两套原生可执行文件都是单独重新构建的，并非历史公开原生归档或 release 验证归档中的确切字节。因此，这项测试比较的是与源码关联的组合，不能单独归因于 JavaScript 改动。

全部 72 个样本的内核和进程观测均经过验证。内存仍是采样值，命名空间隐藏的父级限制和 runner 上的争用不在验证范围内，其他构建及传递依赖也并未全部逐字节认证。这三种合成负载不能证明整体 CPU 或内存下降、生产容量或 SLA。

明确公共来源与本地控制的信任边界

保存的公共来源和可信代理策略现在覆盖开发、持久化服务以及原生多应用入口，包括 HTTP 和 WebSocket 转发。PRNext 会先检查实际建立连接的对端，再接受转发的主机信息或协议。显式配置的规范来源具有优先权；信任一个代理，并不意味着验证了整条客户端 IP 转发链。

图片回退 URL 按 URL 组件构造，授予内部请求例外前还会检查最终规范化来源。编译器和进程管理器的本地 RPC 对双方进行认证，并将新鲜 nonce 与命令、响应的准确字节绑定。消息大小和截止时间仍受限制。这次协议变化要求升级前先停止旧进程管理器。

更换 CLI 前先停止旧进程管理器

如果使用持久化进程管理器，请在替换包之前，用仍已安装的旧 CLI 和同一个 PRNEXT_PM_HOME 检查并停止它。pdown 影响该管理器及共享此目录的全部受管应用，应统一安排维护。仅升级全局 CLI 不会替换每个应用的运行时。请保留源码、lockfile、配置、构建产物和兼容的数据库备份，以便回退。

Terminal

npx --no-install prnext pstatus --json
npx --no-install prnext pdown
npm install @thomas.f/prnext@0.1.21-alpha
npx --no-install prnext check --production --json
npx --no-install prnext build

保持可选原生依赖启用，并让其版本与框架一致。React、React DOM 和 react-server-dom-webpack 保持在 19.3.1；支持的 Node 范围为 ^22.23.4、^24.22.1 或 >=26.12.1。重启目标管理器前，使用新运行时重新构建每个已启用应用。新 CLI 会拒绝不兼容的旧协议，不会静默接管。

PRNext 仍为 alpha，对 Next.js 的兼容性仍是部分覆盖。代表性应用试运行及其自身可靠性目标仍需验证。请使用自己的产品检查登录、切换账户、导航、表单、流式响应、依赖故障和回退。升级 npm 框架不会部署 PRNext Host 或任何外部服务；代码回退也不会撤销数据库写入。