Tanner Linsley 那个 AI 驱动的 React 投影实验，现在变成了正式的 TanStack 项目，并且已经在生产中使用。Redact 是一个更小的、与 React 兼容的浏览器端运行时，已经能和 Start、Next.js、Vinext、Vite 配合。
它怎么定位
服务端什么都不变：React 仍然负责 SSR 与 Server Components。Redact 只接管浏览器端的渲染。
体积更小是直接收益。但真正的取舍在渲染模型：Redact 同步渲染，没有 React 的时间切片能力。
时间切片是什么，为什么重要
React 的并发渲染可以把一次大更新拆成小块，中间让出主线程，保证输入响应不被阻塞。这是 React 18 以来最重要的架构能力之一。
放弃它意味着：一次重渲染就是一口气跑完。官方博客也承认，重渲染仍然会延迟输入。
那为什么还要做
因为对大量应用来说，这个问题不存在。一个表单、一个后台列表、一个内容页，渲染量根本不到需要切片的程度。而 React 的运行时体积与调度开销是实打实的成本。
用一句话概括这个取舍：为 90% 的场景砍掉为 10% 场景准备的复杂度。
真正的风险在哪
不是性能，是行为差异。生态里大量库假设了 React 的调度语义：useTransition、startTransition、Suspense 的时序行为。换成同步渲染，这些假设会以很奇怪的方式失效——不报错，但顺序不对。
如果团队里有对 React 内部机制很熟的人，这类问题能查出来；没有的话，会变成难解的玄学 bug。
适合谁
渲染压力明确不大、对包体积敏感、团队对 React 语义有把握的项目。不适合重度交互动画、大型数据表格、复杂状态协同的应用。
一句提醒
这类“更小的替代实现”最大的成本从来不是接入，是长期跟进。React 主线在演进，替代实现要一直追。评估的时候把这份维护成本算进去。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
