编译器 | 锤子前端

《React 编译器到底做了什么》

Sat, 10 Oct 2026 23:31:54 GMT

《React 编译器到底做了什么》

标签：
#前端工程 #编译器优化 #ReactCompiler #组件内联 #细粒度更新 #状态选择器 #性能基准测试

总结：
作者 Jimmy Miller 通过"边做边讲"的方式拆解 React Compiler 的工作原理：它把组件代码转成基于 memo cache 槽位的低级形式，绕开 Hooks 规则限制自动做记忆化。在此之上，他手工原型化了一系列激进优化（组件内联、Block DOM、列表缓存、Context 选择器、外部 store 选择器等），在 13 项微基准测试中最高取得 51 倍加速，但强调这些都只是探索性原型，不代表 React 官方应该采纳。

文章要点：
1. React Compiler 的输出特征是把 JSX 构造包进 _c() 缓存槽位中，首次渲染写入缓存，后续渲染直接复用，本质上相当于给所有内容自动套上了 memo。
2. 编译产物用的是比 Hooks 更底层的 API，可以在条件返回之后做缓存，绕开"useMemo 不能写在条件分支后"这类 Hooks 规则的限制，作者认为这个啰嗦的形式正是理想的编译目标。
3. 编译器内部先把代码转成 SSA（静态单赋值）形式，再跑大量 pass：有的简化代码（如把 props.method() 拆成属性加载 + 普通调用），有的推断信息，有的做变换优化。
4. 作者尝试组件内联，结果反而更慢（1038 ms 对比编译器的 444 ms），因为内联破坏了 Row 组件自带的缓存边界；说明内联本身只是为后续优化铺路的前置步骤。
5. 借鉴 Million.js 的思路实现 Block DOM（静态/动态分离、按状态 diff 而非树 diff）后，追加 2000 行从 1038 ms 降到 164 ms，内联反而开始带来收益，因为静态边界变得更大了。
6. 列表选择优化借鉴 Solid 的 createSelector：记录选中值变化只影响"旧选中行"和"新选中行"，200 次选择从 250 ms 降到 5.4 ms；Context 细分选择器把 typing 更新场景从 80 ms 降到 11.7 ms。
7. 对 Zustand 这类外部 store，把 === 判断挪进 selector 内部这一小改动就能带来数倍提升，编译器完全可以自动完成这类分析（200 次选择从 311.5 ms 降到 48.9 ms）。
8. 作者反复强调：微基准测试的胜利不等于生产环境该采纳，真正的难点不在原型而在验证——理解真实负载、权衡内存代价、与生态和未来规划对齐；此外 SSR、hydration 等方向尚未触及。

URL：https://jimmyhmiller.com/what-does-the-react-compiler-even-do

Jimmy Miller

Can we Make React Faster using the React Compiler?

I prototyped a number of optimizations as a way to learn more about the React Compiler and got some significant improvements.

《Oxlint 原生集成 React Compiler：Lint 速度提升 3 倍，Rust 工具链再进一步》

Fri, 28 Aug 2026 01:11:29 GMT

《Oxlint 原生集成 React Compiler：Lint 速度提升 3 倍，Rust 工具链再进一步》

标签：
#前端开发 #React #Rust #Oxlint #性能优化 #编译器

总结：

Oxlint 在 v1.79.0 中正式原生集成了 React Compiler 的 22 条 lint 规则，无需 Babel 管道即可在 Rust 层直接运行。这意味着开发者可以在 lint 阶段就捕获 React Compiler 的 bailout（回退）情况，而 lint 任务耗时从约 29.2 秒骤降至 9.1 秒（3.2 倍加速），若去掉其他 JS 插件甚至可达 11 倍。作者强调：使用 React Compiler 时，启用全部 lint 规则是"不可争议的前提条件"，因为一次 bailout 就可能导致性能严重退化（如作者主页动画卡顿）。同时，oxc 的 Rust 版 React Compiler 构建时转换也已接近可用，比原版快约 2 倍。

文章要点：

1. React Compiler 的 Rust 重写已成官方版本 — React 团队近期发布了 Rust 重写的 React Compiler，作为新的 canonical 版本。作者已在 AI 建站工具 Outlyne 中使用近一年，彻底告别手动 useCallback/useMemo。

2. 作者已全面迁移到 oxc 生态 — Rollup → Rolldown、ESLint → Oxlint、Prettier → oxfmt、Jest → Vitest，整体工具链已 Rust 化，但 React Compiler 的 lint 插件一直是瓶颈。

3. 旧方案的痛点：Babel 管道拖慢 lint 3 倍 — 此前通过 Oxlint 的 JS 插件支持运行 React Compiler linter，需要先跑 Babel 再跑 Compiler 核心构建 AST，导致 lint 任务耗时从 9 秒暴涨到 29 秒。

4. Oxlint v1.70.0 起引入原生支持 — 新增 nursery 规则 react/react-compiler，直接在 Rust 中运行 React Compiler，无需 Babel。v1.79.0 正式发布 22 条 Compiler 驱动的规则，覆盖 React 规则的验证。

5. 推荐配置：correctness + 枚举剩余规则 — 启用 correctness 类别可覆盖 12 条规则，再手动列出其余 10 条。若启用 restriction 类别则自动再纳入 5 条，suspicious 纳入 4 条，perf 纳入 1 条。

6. 速度实测：3.2 倍到 11 倍提升 — 原生规则下 lint 从 29.2s → 9.1s；若同时去掉无原生替代的 JS 插件（如 perfectionist），可进一步降至 2.6s，实现 11 倍加速。

7. 构建时转换也在推进中 — oxc 已合并原生构建时 transform，但 Rolldown/Vite 曾因二进制体积增加 17% 而暂时回退。oxc-transform-react v0.0.1 已发布，比原版 Rust Compiler 快约 2 倍，source map 已修复，支持 fast refresh，作者已在生产环境测试。

8. 迁移门槛极低 — 只需 lint 层面改动，不影响构建步骤。可用 npx @oxlint/migrate 自动迁移 ESLint flat config，或让 LLM 帮忙。甚至可以先并行跑 Oxlint 和 ESLint，只替换 React Compiler 插件就能提速。

9. 一个常见陷阱：props 重新赋值 — function MyComponent({ value }) { value = value ?? fallback; } 这种写法会让整个组件被 Compiler 跳过（bailout），导致性能退化。建议用解构重命名解决，同时开启 eslint/no-param-reassign 规则。

10. 作者的底线原则 — "React Compiler without linting all bailouts considered unsafe"（不 lint 所有 bailout 的 React Compiler 视为不安全）。一次 bailout 曾导致其首页动画 placeholder 卡顿、视觉破碎。

URL：
https://blog.master.dev/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/

blog.master.dev

React Compiler Linting Just Got a Rust-Native Speedup in Oxlint

Update! This is a re-written version of this recently-published post about linting code bound for the React Compiler with Oxlint. Oxlint just published a new guide to this, so this post reflects that new information. The React team made a big splash recently…

《Python 3.15的JIT编译器重回正轨》

Wed, 18 Mar 2026 11:21:29 GMT

《Python 3.15的JIT编译器重回正轨》

标签：#Python #JIT #CPython #性能优化 #Faster_CPython #编译器 #开源社区

总结：

Python 3.15的JIT编译器开发取得突破性进展，在失去主要赞助商后通过社区协作成功实现性能目标。目前macOS AArch64平台比解释器快11-12%，Linux x86_64快5-6%，提前完成预定目标。文章强调了团队建设、任务分解和幸运的技术决策（如追踪记录解释器和引用计数消除）对项目成功的关键作用。

文章要点：

- **性能目标提前达成**：Python 3.15的JIT在macOS AArch64上比尾调用解释器快11-12%，在Linux x86_64上比标准解释器快5-6%，提前一年多完成目标
- **从困境中重生**：Faster CPython团队2025年失去主要赞助商后，通过社区托管模式维持开发，作者曾怀疑JIT项目能否成功
- **降低"巴士因子"风险**：团队计划在JIT的前端（区域选择器）、中端（优化器）、后端（代码生成器）各配备2名活跃维护者，目前中端已有4名贡献者
- **任务分解吸引新人**：将复杂优化问题拆分为简单任务（如"优化单条指令"），提供详细可操作的指导，让无JIT经验的C程序员也能参与，共11人参与核心重构
- **关键技术决策**：Brandt建议改用追踪式前端，Mark建议双分派表机制，意外地将追踪解释器性能从慢6%提升到快1.x%，并将JIT代码覆盖率提升50%
- **引用计数消除优化**：消除每条Python指令的分支操作，这一优化易于并行化且适合教学，是3.15版本的主要优化方向
- **基础设施支撑**：Savannah Ostrowski一人搭建了等效于整个基础设施团队的CI系统，每日性能测试帮助快速发现回归问题

文章URL：

https://fidget-spinner.github.io/posts/jit-on-track.html

Ken Jin’s Blog

Python 3.15’s JIT is now back on track