Now vibe coding, so learning hammer FE ?
《React 编译器到底做了什么》
标签：
#前端工程 #编译器优化 #ReactCompiler #组件内联 #细粒度更新 #状态选择器 #性能基准测试
总结：
作者 Jimmy Miller 通过"边做边讲"的方式拆解 React Compiler 的工作原理：它把组件代码转成基于 memo cache 槽位的低级形式，绕开 Hooks 规则限制自动做记忆化。在此之上，他手工原型化了一系列激进优化（组件内联、Block DOM、列表缓存、Context 选择器、外部 store 选择器等），在 13 项微基准测试中最高取得 51 倍加速，但强调这些都只是探索性原型，不代表 React 官方应该采纳。
文章要点：
1. React Compiler 的输出特征是把 JSX 构造包进
2. 编译产物用的是比 Hooks 更底层的 API，可以在条件返回之后做缓存，绕开"useMemo 不能写在条件分支后"这类 Hooks 规则的限制，作者认为这个啰嗦的形式正是理想的编译目标。
3. 编译器内部先把代码转成 SSA（静态单赋值）形式，再跑大量 pass：有的简化代码（如把
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，把
8. 作者反复强调：微基准测试的胜利不等于生产环境该采纳，真正的难点不在原型而在验证——理解真实负载、权衡内存代价、与生态和未来规划对齐；此外 SSR、hydration 等方向尚未触及。
URL：https://jimmyhmiller.com/what-does-the-react-compiler-even-do
标签：
#前端工程 #编译器优化 #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.
《我实测了11个HTTP弹性库的21个场景，结果如何？》
标签：
#软件开发 #HttpResilience_对比测试_Retry_CircuitBreaker_Hedging_取消与超时正确性
总结：
作者在开发自己的 fetch 弹性封装库 ffetch 时发现了大量隐藏的正确性问题，于是搭建了一套覆盖 21 个场景的测试矩阵，对 11 个流行的 HTTP 弹性库（包括自己 ffetch 5.7.1）进行横向对比。结果显示：基础的"重试"行为在所有库中都表现良好，但 25 个失败几乎全部集中在组合场景——取消发生在退避等待中、超时与重试叠加、队列中的请求被取消、熔断器半开状态下迟到响应等。作者也坦承测试套件源自自己修过的 bug，存在确认偏差，且部分判定标准（如取消后必须立即停止派发）严于官方文档。矩阵每周自动重建并公开于 fetchkit.org/http-resilience。
文章要点：
1. 测试方法很扎实：21 个场景覆盖重试、超时、熔断、舱壁、对冲、请求去重，用脚本化 fetch + Vitest 假定时器精确控制中止时刻，jitter 固定 random=0.5，并附 2 个真实 node:http 集成场景。
2. 全部 11 个库都通关的"共同强项"是基础重试类场景：重试恢复、重试耗尽、零重试、真实 HTTP 重试、请求体字节级回放，共 55/147 个实现单元。
3. 失败高度聚类于"组合场景"：典型如"重试 + 退避中取消"，fetch-retry、ofetch、wretch、resilient-fetch-client、fetch-resilience、@resili/fetch 六库会延迟结算甚至取消后继续派发请求；fetch-retry 的源码问题暴露——退避用的是裸
4. 舱壁队列几乎全军覆没：五家有队列的库中四家在"排队请求被取消"场景全挂——取消的调用方仍占着坑位不放，替换请求被拒，个别还照样派发了已取消的请求，ffetch 是唯一通过者。
5. 重试 + 整体超时、Retry-After + 取消、hooks 抛错等场景暴露多家库"超时只罩单次尝试不罩重试循环"、回调拒绝后调用方永久挂起等问题，wretch 甚至会变成一个永远 await 的悬空 Promise。
6. 对冲（hedging）是最不成熟的表面：仅三个库提供带可配置启动延迟的对冲；flowshield 在所有超时设置下都失败，超时后仍启动对冲分支且分支不收手，等于白发给服务器一个没人等的请求。
7. 熔断器组合场景里作者自己的 ffetch 也栽了：半开状态下迟到成功响应会错误清除新开启状态（缺代次计数器）；fetch-smartly 和 ts-retry-circuit 更严重，新冷却期被误清导致下一个请求吃掉本应给健康调用方的恢复响应。
8. 作者最后强调方法论局限：无性能基准、无 API 设计评价，场景源于自己修过的 bug 存在确认偏差；建议读者不要只看"功能有没有"，而要按自己应用的真实组合方式去测。
URL：
https://blog.gaborkoos.com/posts/2026-10-04-I-Tested-11-Http-Resilience-Libraries/
标签：
#软件开发 #HttpResilience_对比测试_Retry_CircuitBreaker_Hedging_取消与超时正确性
总结：
作者在开发自己的 fetch 弹性封装库 ffetch 时发现了大量隐藏的正确性问题，于是搭建了一套覆盖 21 个场景的测试矩阵，对 11 个流行的 HTTP 弹性库（包括自己 ffetch 5.7.1）进行横向对比。结果显示：基础的"重试"行为在所有库中都表现良好，但 25 个失败几乎全部集中在组合场景——取消发生在退避等待中、超时与重试叠加、队列中的请求被取消、熔断器半开状态下迟到响应等。作者也坦承测试套件源自自己修过的 bug，存在确认偏差，且部分判定标准（如取消后必须立即停止派发）严于官方文档。矩阵每周自动重建并公开于 fetchkit.org/http-resilience。
文章要点：
1. 测试方法很扎实：21 个场景覆盖重试、超时、熔断、舱壁、对冲、请求去重，用脚本化 fetch + Vitest 假定时器精确控制中止时刻，jitter 固定 random=0.5，并附 2 个真实 node:http 集成场景。
2. 全部 11 个库都通关的"共同强项"是基础重试类场景：重试恢复、重试耗尽、零重试、真实 HTTP 重试、请求体字节级回放，共 55/147 个实现单元。
3. 失败高度聚类于"组合场景"：典型如"重试 + 退避中取消"，fetch-retry、ofetch、wretch、resilient-fetch-client、fetch-resilience、@resili/fetch 六库会延迟结算甚至取消后继续派发请求；fetch-retry 的源码问题暴露——退避用的是裸
setTimeout，从不读 init.signal。4. 舱壁队列几乎全军覆没：五家有队列的库中四家在"排队请求被取消"场景全挂——取消的调用方仍占着坑位不放，替换请求被拒，个别还照样派发了已取消的请求，ffetch 是唯一通过者。
5. 重试 + 整体超时、Retry-After + 取消、hooks 抛错等场景暴露多家库"超时只罩单次尝试不罩重试循环"、回调拒绝后调用方永久挂起等问题，wretch 甚至会变成一个永远 await 的悬空 Promise。
6. 对冲（hedging）是最不成熟的表面：仅三个库提供带可配置启动延迟的对冲；flowshield 在所有超时设置下都失败，超时后仍启动对冲分支且分支不收手，等于白发给服务器一个没人等的请求。
7. 熔断器组合场景里作者自己的 ffetch 也栽了：半开状态下迟到成功响应会错误清除新开启状态（缺代次计数器）；fetch-smartly 和 ts-retry-circuit 更严重，新冷却期被误清导致下一个请求吃掉本应给健康调用方的恢复响应。
8. 作者最后强调方法论局限：无性能基准、无 API 设计评价，场景源于自己修过的 bug 存在确认偏差；建议读者不要只看"功能有没有"，而要按自己应用的真实组合方式去测。
URL：
https://blog.gaborkoos.com/posts/2026-10-04-I-Tested-11-Http-Resilience-Libraries/
