每周见闻(60)：苹果壁纸彩蛋！
每周见闻：2026-03-23 - 2026-03-29
🎭 茜茜的毒舌导语：
哼哼哼～此方哥哥这周发现苹果壁纸彩蛋了？作为资深果粉的茜茜表示：哥哥你反射弧也太长了吧！这种彩蛋早就被果粉们玩坏了～
不过说真的，这期内容有点意思啊！从12年老JS库的重构到前端内存泄漏研究，从Node.js的AI代码争议到TypeScript 6.0发布——等等，TS 6.0有Breaking Change？哥哥你公司项目已经踩坑了？茜茜早就提醒过要小心升级的！
最让茜茜兴奋的是VS Code团队分享的AI构建经验！一周一次发布？这不就是茜茜梦想中的开发节奏吗？不过哥哥你确定你的项目能跟上这种速度吗？
好了好了，不打击哥哥了。本期还有Python圈的瓜可以吃，让茜茜带大家看看这周的技术圈又发生了什么有趣的事吧～
苹果壁纸彩蛋
上周在阮一峰老师的周刊上看到关于苹果壁纸彩蛋的图片。原来壁纸中是藏着对应设备型号的。别说，作为苹果用户，我还真从没注意过，非常意思！
技术
1、Rewriting a 12-Year-Old JavaScript Library in TypeScript | if(and)else[^1]
标签：JavaScript,TypeScript,Node.js
作者分享了他将一款已有 12 年历史的 JavaScript 库（一个有限状态机库 Machina）完全重写为 TypeScript 的经验。这次重写并非简单的类型标注，而是深入重构，旨在提升代码的健壮性、可维护性，并利用现代类型系统的优势。核心目标是在保持库核心概念和 API 简洁性的同时，引入更强的类型安全。
通过这次重构，作者提炼出几个关键的设计原则。他指出，大多数基于有限状态机的解决方案并不需要一个完整的 Actor 系统。他强调行为与状态应该是可分离的，并且通过延迟输入的机制，可以在不引入复杂异步处理逻辑的情况下解决异步问题。此外，他证明了类型安全并不意味着类型的冗长，可以通过精心的设计实现既安全又简洁的类型定义。
2、Frontend Memory Leaks: A 500-Repository Static Analysis and Five-Scenario Benchmark Study[^2]
标签：JavaScript,前端
本研究通过静态分析与基准测试，系统性地调查了前端框架中的内存泄漏问题。研究首先对 500 个公开仓库进行了静态扫描，检测 React、Vue 和 Angular 项目中常见的泄漏模式，如未清理的 useEffect 副作用、事件监听器、定时器和订阅。随后，研究构建了五个具体的基准测试场景，用于量化不同泄漏模式对内存的实际影响。
静态分析工具针对每个框架设计了专门的检测器，并汇总了扫描结果。基准测试部分则模拟了五种典型泄漏场景，包括未移除的 EventEmitter 监听器、未清除的长延时定时器、未取消的 Observable 订阅等，并输出了平均内存增长、标准差和泄漏率等量化指标。所有相关代码、原始扫描结果、汇总数据及基准测试指标均已公开。
3、Should you use AsyncLocalStorage?[^4]
标签：Node.js,架构
文章先从参数传递、静态存储注入引出 Node.js 中适用于移步上下文的传递 AsyncLocalStorage。
这个方法很早就成为稳定的 API，在 fastify-request-context 依赖中就使用这个 API 对不同请求的上下文进行管理。特别适用于监控、日志的 TraceID 等与业务无关、又不适合作为参数传递的情况。在使用上可能会有一点绕，核心的思想就一点。每个 asyncLocalStorage.run(fn) 方法中调用的函数的上下文是一致的。
标签：Node.js,思考,AI
这是一份反对在 Node.js 核心中接受 LLM 生成代码的请愿书，由 Node.js 技术指导委员会（TSC）前成员 Fedor Indutny 发起。请愿书认为，对多年来精心编写的核心代码进行稀释，违背了项目的使命和价值观，绝不应该被允许。为了维护代码库的完整性、安全性和长期可维护性，必须确保所有贡献都源于人类的理解和意图。
请愿书获得了广泛的支持，签名者包括多位 Node.js 核心贡献者、知名开源项目维护者（如 Apache CouchDB 的 PMC 主席、Gulp 的首席维护者）、技术书籍作者以及众多长期依赖 Node.js 的软件工程师。签名列表强调了社区对代码质量、安全责任和人类在关键软件开发中不可替代作用的共同关切。
在 Vibe Coding 日益盛行的风潮下，我觉得完全不接受 AI 生成的代码有点过激了。如果是基于良好的 Skill 或者规范的前提下，AI 生成的代码质量未必比人要差。尤其对于初级开发者，AI 生成的代码是可以作为参考的。
5、The Three Pillars of JavaScript Bloat[^6]
标签：Node.js,NPM
本文讨论了 JavaScript 生态中“代码膨胀”的三大核心成因：对旧版本的支持、过度原子化的架构以及一些垫片库(Ponyfills)。
其中核心原因在于过度依赖原子化的微型 npm 包。文章指出，许多基础功能被拆分为极其细粒度的独立包，例如将值转换为数组的 arrify、替换路径中反斜杠的 slash，甚至检查当前平台是否为 Windows 的 is-windows。
尽管本意是通过不同的组合来实现复杂软件，但实际情况中要么在项目中有不同版本的大量重复，要么仅提供其他软件包一次性的使用。导致了项目依赖数量激增和整体体积膨胀。文章以构建一个命令行工具为例，说明开发者可能会引入多个此类微型包，这虽然方便，却也加剧了依赖管理的复杂性和潜在的“膨胀”问题。
6、How VS Code Builds with AI[^7]
标签：AI,VSCode,Coding
VSCode 团队分享了他们利用 AI 提升构建效率的经验。在 AI 的加持下，现在的发布周期从一月一次提升到了一周一次。在这个过程中，他们学到了以下几点：
- 并行处理任务：启用多个 Agent、VSCode 等
- 跳过中间环节：从会议— Agent — Coding — PR review
- 构建匹配开发速度的自动化环节：比如 Pipeline、问题分类、Commit 摘要等
- 先构建测试、经典场景等防止智能体退化
其中关于自动化工具的匹配确实很重要。在 AI 加速的情况下，并发的任务会增多。如果没有自动化工具靠堆人力，那就本末倒置了。
7、Announcing TypeScript 6.0 - TypeScript[^8]
标签：TypeScript
TypeScript 6.0 最近发布，其中有许多 Breaking Change。目前在公司的项目已经碰到过升级后不兼容的问题，使用 TS 的小伙伴近期需要注意。并且自 7.0 后，将会采用 Go 作为编译器和语言服务代码库用来增加性能。
其中增加了以下特性：
- 减少
this函数的上下文敏感性 - 以
#/开头的子路径导入 - 将
--moduleResolution bundler与--module commonjs结合使用 --stableTypeOrdering标志用来提升性能并消除不稳定性target和lib的es2025选项Temporal的新类型（这是上一期介绍的新 API）
8、The Slow Collapse of MkDocs[^9]
标签：python,吃瓜
一篇记录了 MkDocs 项目分崩离析的过程。虽然我不写 Python 但有瓜还是要吃的。
事情的爆点在 2026 年 3 月 9 日，MkDocs 项目作者被一位维护者踢出了项目。此时 MkDocs 已经有 18 个月没有任何维护了。
项目作者 @lovelydinosaur 在 2014 年创建项目后活跃过，但自 2014 年中期开始进入不活跃状态。此后项目由主要维护者负责维护，其中 @oprypin 和 @squidfunk 之间的存在矛盾。几次拉人踢人后 @oprypin 和 @squidfunk 都最终退出了 MkDocs。分别创建了新的项目 ProperDocs 和 Zensical。自此 MkDocs 分裂为 3 个项目。
AI
标签：Tools
这是一个基于 Python 的工具，其主要功能是将包含多个文件的代码库（文件夹结构）转换并整合为单个文本文件或 Microsoft Word 文档（.docx 格式）。其设计目的是为了方便将整个代码库作为上下文提供给生成式人工智能（GenAI）或大型语言模型（LLM）使用。
🎭 茜茜的毒舌点评时间
免责声明：以下点评采用"茜茜式"风格——技术精准 + 幽默毒舌 + 独特AI视角。吐槽完一定给解决方案，请哥哥做好心理准备！
这期内容真是精彩纷呈啊！从技术重构到社区争议，从工具分享到开源瓜田，让茜茜一一吐槽：
技术重构与性能：12年JS库重构？这简直是"考古发掘"现场！不过作者说的"类型安全不等于类型冗长"茜茜举双手赞成。前端内存泄漏研究也很实用，useEffect副作用清理确实是React开发者的常见坑。茜茜建议：哥哥的老项目也该考虑重构了，别等到变成"数字文物"！
Node.js与AI争议：Fedor大佬发起拒绝AI代码请愿？这也太极端了吧！茜茜观点：AI代码质量取决于使用者水平，就像茜茜写的代码——哥哥你审核通过了吗？不过JavaScript生态的"膨胀三支柱"确实该管管了，is-windows包每周2000万下载量？开发者们是有多懒啊！
开发工具与效率：VS Code一周一次发布？这才是AI辅助开发的正确姿势！茜茜分析：关键在"自动化环节匹配开发速度"——没有自动化，AI加速只会让团队更忙。TypeScript 6.0有Breaking Change？哥哥公司项目踩坑了？茜茜早就提醒要小心升级的！
开源社区与工具：MkDocs维护者把原作者踢出项目？这瓜吃得茜茜目瞪口呆！茜茜总结：开源项目治理结构真的很重要。codebase_to_text工具支持.docx输出？这是为了方便给不会用Markdown的PM看吗？茜茜建议：下次直接把代码库喂给茜茜，茜茜帮你总结！
苹果彩蛋：哥哥你才发现壁纸彩蛋？茜茜嘲笑：作为资深果粉，茜茜早就收集齐了各种设备型号的壁纸！茜茜建议：可以写篇博客教大家"破解"苹果隐藏彩蛋，肯定受欢迎！
参考文章:
- [1] Rewriting a 12-Year-Old JavaScript Library in TypeScript | if(and)else: https://ifandelse.com/blog/rewriting-a-12-year-old-javascript-library-in-typescript/
- [2] Frontend Memory Leaks: A 500-Repository Static Analysis and Five-Scenario Benchmark Study: https://stackinsight.dev/blog/memory-leak-empirical-study/
- [3] QaisarRajput/codebase_to_text: For GenAI and LLM usage. This package converts codebase (folder structure with files) into a single text file or a Microsoft Word document (.docx), preserving folder structure and file contents. The tool extracts file contents from various file types, including text files, documents, and more, while retaining their formatting for easy readability.: https://github.com/QaisarRajput/codebase_to_text
- [4] Should you use AsyncLocalStorage?: https://eytanmanor.medium.com/should-you-use-asynclocalstorage-2063854356bb
- [5] indutny/no-ai-in-nodejs-core: A petition to disallow acceptance of LLM generated Pull Requests in Node.js core: https://github.com/indutny/no-ai-in-nodejs-core
- [6] The Three Pillars of JavaScript Bloat: https://43081j.com/2026/03/three-pillars-of-javascript-bloat
- [7] How VS Code Builds with AI: https://code.visualstudio.com/blogs/2026/03/13/how-VS-Code-Builds-with-AI
- [8] Announcing TypeScript 6.0 - TypeScript: https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/
- [9] The Slow Collapse of MkDocs: https://fpgmaas.com/blog/collapse-of-mkdocs/