React 仓库搬进 react 组织，19.3 还在修 Flight 流式渲染

门牌换了，仓库号没换

如果你今天还从书签打开 github.com/facebook/react，会发现地址栏自己变成了 react/react。GitHub API 那边更直接：facebook/react 现在返回 301，指向 /repositories/10270250，而 react/react 的仓库 ID 正是 10270250，创建时间仍是 2013 年 5 月 24 日。

同一个仓库号说明这不是新开的镜像或分叉，而是组织归属从 facebook 换到了以项目命名的 react 组织。对日常开发几乎没有影响——旧地址会重定向，git remote 里的 facebook/react 也照常能推拉——但所有硬编码了 owner 的地方都值得过一遍：CI 里拼出来的 raw 链接、依赖 GitHub API 取 issue 或 release 的脚本、按 owner 做白名单的安全扫描规则、以及把 facebook/react 写进文档的贡献指南。这类字符串不会报错，只会慢慢变成 301 链条上的一环。

一条实用建议：git remote set-url origin https://github.com/react/react.git，把重定向省掉。仓库目前 252,265 star，当日新增 248。

三个维护分支同日打同一个补丁

10 月 14 日，19.3.1、19.2.9、19.1.10 三个版本在同一天发布，改的是同一件事：React Server Components 的传输协议改进（#37845 / #37844 / #37843，作者 @unstubbable 与 @eps1lon）。

三个分支同步发同一处修复，是维护期项目的标准动作：19.1 和 19.2 已经进入只收安全与严重缺陷的阶段，但 RSC 的协议层一旦有问题，跑在这两个分支上的生产应用同样受影响，所以不能只修主线。反过来说，一条改动要跨三个分支同步，也说明它触到的是客户端与服务端必须同时升级的那一层——RSC 的 Flight 协议在序列化格式上并没有版本协商的余地，两端对不上就是解析错误。

Flight 这一周的补丁清单

看最近几天的提交，重心非常明确：

• #38128 修复流式 Server Components 中的 hooks 问题（Flight）。
• #38132 修复 useDeferredValue 配合挂起的 hydration 或重试时出现的死循环。
• #38071 让 Fizz 把 crossOrigin 转发给外部 runtime script，此前该属性在 SSR 输出里会丢。
• DevTools 一侧修了三处 facade 检查：非资源类 hoistable 实例的识别、BigInt 值的归一化、单字符串格式化时保留未匹配的 console specifier 字面量。
• CI 侧把大部分任务切到 Node 24，并给 Flight 的 npm 包加了发布校验与浏览器缓存命中检查。

把这些排在一起看，会得到一个和”React 已经稳定成熟”略有出入的印象：RSC 与 Suspense 的组合仍在出真问题——挂起 hydration 与延迟值互相等待导致死循环，这类 bug 只能在特定的流式渲染时序下复现，靠单元测试很难提前拦住。

和之前那篇报道的区别

本站此前报道过 React 基金会的成立，那篇讲的是治理结构；这次的变化发生在代码托管层面——品牌归位到 react 组织，同时 RSC 传输协议在三个维护分支上同步收口。同一项目，不同切面，不构成重复报道。

值得留意的是节奏：一个 25 万 star 的项目，日常提交几乎全部落在 Flight、Fizz、DevTools 这几块，说明 React 当前的维护重心已经从”补齐 API”转向”把服务端渲染这条链路的边界情况磨平”。对使用者来说，这意味着升级到 19.x 后遇到怪问题，先查最近几个补丁版本的 Flight 修复，往往比翻文档更快。

仓库地址：https://github.com/react/react