AI 摘要：文章深入分析了在 Node.js 中使用静态环境变量的局限性，特别是在需要快速响应生产环境变化（如调整频率限制、切换特性开关等）时。作者对比了实现动态配置的三种主流技术方案：轮询 (Polling)、Webhooks 和服务器发送事件 (SSE / Server-Sent Events)，并强调了将“代码部署”与“配置更改”解耦的重要性。通过使用动态配置工具，开发者可以实现更快的事故响应、更安全的灰度发布以及更清晰的权责分离。

replane.dev

Dynamic Configuration in Node.js: Beyond Environment Variables | Replane

Environment variables are static. Learn how to implement dynamic configuration in Node.js with realtime updates, type safety, and instant rollback.

AI 摘要：本文深入探讨了 Turbopack 的核心技术——增量计算（Incremental Computation）。通过从 Webpack 等工具中吸取教训并借鉴 Rust 社区的 Salsa 框架，Turbopack 构建了一套基于“值单元（Value Cells）”的细粒度缓存系统。它不仅能自动追踪函数间的依赖关系，实现“按需”重算，还通过创新的“聚合图（Aggregation Graphs）”解决了大规模依赖图下的查询性能瓶颈。此外，Next.js 16.1 正式引入了持久化的文件系统缓存，进一步提升了大型项目的启动和冷启动效率。

1. 核心架构：增量计算（Incremental Computation）
• 传统的打包工具随着应用规模增长，构建速度呈线性下降（$O(n)$）；而 Turbopack 的构建耗时仅取决于变更的大小，而非应用总量。
• 增量计算虽然增加了复杂度和内存开销，但对于大型 Web 应用实现即时反馈（Fast Refresh）至关重要。
• 设计灵感源自十余年的研究，包括 Webpack 的经验以及 Salsa (Rust-Analyzer)、Parcel、Adapton 等系统的启发。

2. 细粒度缓存：值单元（Value Cells）
• 引入 Vc<...>（Value Cells）概念：将每一个执行片段（如读取文件、解析 AST、元数据处理）抽象为类似电子表格的单元格。
• 自动依赖追踪：类似于 SolidJS 的 Signals，当一个函数等待（await）一个 Vc 时，系统会自动建立依赖关系。
• 避免冗余计算：只有当函数真正读取的单元格发生变化时，才会触发重算，而非整个对象发生变化就重算。

3. 变更传播与需求驱动执行（Propagation & Demand-driven）
• 脏值标记（Marking Dirty）：当文件变更时，系统将依赖该文件的函数标记为“脏”，并向上冒泡传播，直到受影响的所有节点。
• 需求驱动（Demand-driven）：即使标记为脏，系统也会推迟重算，直到该数据被当前的“活跃查询”（如浏览器打开的页面）真正需要。
• 结果比对（Equality Check）：如果在传播过程中发现计算出的新值与旧值相等，则停止向上继续传播，从而减少不必要的重算。

4. 大规模优化：聚合图（Aggregation Graphs）
• 性能挑战：在拥有数百万个节点的精细图中，收集错误信息或等待子图计算完成会非常缓慢。
• 聚合层设计：在依赖图之上构建多层聚合图，对下层节点的信息（如错误、警告、状态）进行摘要总结。
• 快速遍历：通过减少需要访问的节点数量，使得系统能够在大规模依赖网络中快速响应全局查询。

5. 持久化存储：文件系统缓存（File System Caching）
• 在 Next.js 16.1 版本中，文件系统缓存已转为稳定版并默认开启。
• 将内存中的依赖图、聚合图及 Vc 结果持久化到磁盘，使得 next dev 在重启后能快速恢复状态。
• 解决了复杂的数据序列化与一致性挑战，显著缩短了大型项目的冷启动时间。

nextjs.org

Inside Turbopack: Building Faster by Building Less

Learn how we built Turbopack with incremental computation to scale development and builds to massive Next.js applications.

AI 摘要：作者回顾入职一个月在 LobeHub 进行的性能与开发体验优化。主要内容包括：替换 react-layout-kit、移除 CSS-in-JS 动态样式以降低渲染与内存开销；优化首屏返回速度并大幅提升消息列表渲染性能；重构 Tooltip、Popover 等基础组件；削减 Electron App 体积约 100MB；改进 i18n 与 IPC 开发体验；并计划未来将 Next.js 迁移至 Vite，以显著降低开发期内存占用。

innei.in

记 LobeHub 的性能和 DX 优化

距离去新的工作差不多一个多月了。这段时间刚入职，其实都挺忙的，而且公司也正在筹划发布 2.0 的版本，所以我加入的时候刚好算是个好时机（忙到起飞）。 这一个月基本都是在冲刺。我发现，我每次换一个公司，刚进去的一段时间都会去做一些项目中的性能优化，以及对一些开发体验不友好的事情，做过多的调教。 尤

AI 摘要：本文全面介绍了 Vitest Browser Mode，这是一种在真实浏览器环境中运行前端测试的新兴技术。它结合了端到端（E2E）测试的真实性与组件测试的隔离性，能够直接利用所有 Web API，无需模拟，并提供可视化的调试界面。作者预测 Vitest Browser Mode 将在未来几年内成为前端工程师必备的测试工具。文章详细阐述了 Vitest Browser Mode 的工作原理、测试编写方式（类比 React Testing Library 和 Playwright）、核心概念、配置方法（推荐使用 Playwright provider）、安装步骤以及如何运行测试，并提供了一个完整的示例。

AI 摘要：本文提供了一份详细的逐步指南，旨在帮助开发者调查并缩减 JavaScript 打包文件的大小，以提高网页性能。作者通过一个实际项目案例，展示了如何使用打包分析器来识别大型或冗余的代码块。文章深入探讨了摇树优化（tree-shaking）的工作原理和局限性，特别是针对 CommonJS 模块和 * 导入模式。此外，还介绍了如何通过识别和移除重复库、以及处理由第三方依赖引入的传递依赖（transitive dependencies）来进一步优化代码体积，最终将示例项目的 bundle size 从 5MB 显著减少到 600KB 左右。

1. 初始项目设置 (Initial Project Setup)
• 作者创建了一个故意膨胀的示例项目（其 JavaScript 包大小为 5MB），作为演示如何调查和缩小打包体积的起点。
• 提供项目 GitHub 仓库链接，鼓励读者通过实际操作来验证文章内容。
2. 分析打包大小 (Analyzing Bundle Size)
• 介绍了打包分析器（bundle analyzer）工具的使用，例如 Vite 项目中的 Rollup Plugin Visualizer。
• 解释如何解读打包分析图（treemap），识别出项目中最大的代码块，尤其是供应商（vendor）代码和应用程序自身代码。
• 指出可以通过配置更改可视化模板（template），如使用火焰图（flamegraph），以获得不同视角的分析。
3. 调查流程 (Investigation Process)
• 确定要移除的包 (Step 1: Identify a Package to Eliminate)：通过打包分析图识别出体积巨大且可能存在问题的包，如 @mui 相关的包。
• 理解包 (Step 2: Understand the Package)：快速研究包的功能和用途，以理解其在项目中的角色。
• 理解包的使用方式 (Step 3: Understand the Usage of the Package)：通过代码搜索确定包在项目中的导入和使用模式，特别是是否存在 * 导入所有内容的模式。
• 确认问题 (Step 4: Confirm That This is the Problem)：通过临时注释掉问题包的导入代码并重建项目，验证其对打包大小的实际影响。
4. 摇树优化和死代码消除 (Tree Shaking and Dead Code Elimination)
• 解释摇树优化（tree-shaking）的原理：现代打包工具如何识别并移除未使用的代码（dead code）。
• 通过示例代码展示了 tree-shaking 在原生 ESM 模块中的有效性。
• 揭示了 * 导入模式（ import * as Something from 'library'）会阻止 tree-shaking 对外部库生效，导致整个库被打包。
• 提出解决方案：避免使用 * 导入，改为精确导入所需模块，以确保 tree-shaking 正常工作。
5. ES 模块和非摇树优化库 (ES Modules and Non-tree-shakable Libraries)
• 解释 JavaScript 模块格式（如 ESM, CommonJS）对 tree-shaking 能力的影响。
• 强调 ESM 格式易于 tree-shaking ，而 CommonJS 等旧格式则难以优化。
• 介绍 is-esm 工具，用于检查一个 npm 包是否为 ESM 格式。
• 以 lodash 库为例，展示了非 ESM 格式导致 tree-shaking 失败的问题，即使是精确导入特定函数也无济于事。
• 提供解决方案：使用库提供的精确子路径导入（import trim from 'lodash/trim'）来只引入所需部分，或在功能允许的情况下替换为原生 JavaScript 函数。
6. 常识和重复库 (Common Sense and Repeating Libraries)
• 指出在大型项目中，多个库可能实现相同功能，导致代码冗余。
• 以日期处理库 date-fns、moment 和 luxon 为例，展示了如何识别并移除这些重复的库。
• 强调选择替换库时需考虑 tree-shaking 能力、API 易用性、维护状态以及对打包大小的影响。
• 通过将 moment 和 luxon 的使用重构为 date-fns，显著减少了打包体积。
7. 传递依赖 (Transitive Dependencies)
• 解释传递依赖：当项目直接依赖的库又依赖了其他库时，这些间接依赖也会被打包。
• 介绍 npm-why 工具，用于追溯一个包的所有依赖路径，从而识别其作为传递依赖的来源。
• 以 @emotion 库为例，即使从项目中移除了直接使用，它仍可能通过 @mui 等库作为传递依赖存在。
• 说明移除传递依赖可能需要移除其上游所有依赖，这是一项需要权衡成本和收益的复杂任务。
• 通过将 @mui 组件替换为 Radix UI 组件并替换图标，成功移除了 @mui 及其传递依赖 @emotion。
8. 结果 (The Result)
• 总结了整个优化过程的成果：示例项目的 JavaScript 包大小从 5MB 显著减少到 600.98 KB。
• 指出尽管取得了巨大进步，但仍有进一步的优化空间，例如通过懒加载（lazy loading）处理 tiptap 和 prosemirror 等大型库。

Developerway

Bundle Size Investigation: A Step-by-Step Guide to Shrinking Your JavaScript

A practical guide to analyzing and reducing JavaScript bundle size. Learn bundle analysis, fix tree-shaking issues, remove duplicate libraries, and otherwise optimize your React app's JavaScript size.

AI 摘要：本文是 Node.js 核心贡献者 Joyee Cheung 关于 require(esm) 功能实现细节的深度解析。文章聚焦于该功能在落地过程中，为兼容现有生态系统而必须解决的几个关键互操作性问题：包括如何处理“伪 ESM (faux-ESM)”包的 __esModule 标记、如何通过特殊导出 "module.exports" 支持非对象字面量的 CommonJS 导出、如何引入 "module-sync" 导出条件来支持双包 (dual package) 的平滑迁移，以及如何通过 process.getBuiltinModule() 避免不必要的顶层 await。文章揭示了看似简单的功能背后，为保持生态稳定性和性能所付出的复杂工程努力，并强调了社区协作在推动此类停滞计划中的关键作用。

1. 伪 ESM (Faux-ESM) 的兼容性挑战
• 问题根源：许多为浏览器打包的库在 Node.js 端发布的是转译后的 CommonJS 代码（即“伪 ESM”），它们依赖 __esModule 标记来模拟 ESM 的命名空间行为。
• 兼容性断裂：如果这些包直接迁移到纯 ESM，其现有的转译后消费者通过 require() 加载时将因缺少 __esModule 标记而中断。
• 解决方案评估与选择：在无法直接修改不可变的模块命名空间对象的前提下，评估了多种方案（对象拷贝、Proxy、原型继承、ESM 门面模块），最终选择了通过创建一个内部 ESM 门面模块（使用 export * from 并额外导出 __esModule）的方案，以在保证正确性（保持实时绑定、身份和可枚举性）的同时，将性能开销降至最低（约 2-4%）。

2. CommonJS 特殊导出模式的兼容
• 导出形状不匹配：CommonJS 允许 module.exports 被重新赋值为任何值（如一个类），而 ESM 的默认导出位于命名空间的 default 属性下，这导致迁移后 CommonJS 消费者无法正确获取导出值。
• 特殊导出方案：引入了名为 "module.exports" 的字符串字面量特殊导出。ESM 模块可以通过 export { Klass as "module.exports" } 来显式指定 require(esm) 应返回的值，从而无缝兼容旧的 CommonJS 消费者，而无需改变 ESM 消费者的导入方式。

3. 双包 (Dual Package) 的迁移路径
• 条件导出的演进：为了在支持旧版 Node.js（仅 CommonJS）的同时，为新版 Node.js 提供 ESM，包作者曾使用 "node" 条件指向 CommonJS。
• 新条件的引入：由于生态中已有的 "module" 条件常指向无法在 Node.js 直接运行的打包后代码，Node.js 引入了新的 "module-sync" 条件，专门用于指向可在 Node.js 中同步加载的 ESM 源文件，作为向纯 ESM 包过渡的临时方案。

4. 同步内置模块检测
• 问题背景：在 ESM 中动态检测内置模块（如 node:os ）过去只能通过异步的 import() 实现，这迫使代码使用顶层 await。
• 同步 API 的引入：为解决此问题并方便工具链（如 TypeScript），Node.js 引入了 process.getBuiltinModule() 这个同步 API，允许在 ESM 中同步获取内置模块引用，减少了对顶层 await 的依赖。

5. 底层实现与同步化
• 概念模型：require(esm) 的简化逻辑是同步地获取、链接、评估 ESM 模块，然后返回其命名空间。
• 同步化重构：实际的挑战在于与异步 import 共享的模块缓存和加载流程可能引发竞态条件。随着 Node.js 生态对同步模块加载的坚定依赖，原先为未来异步扩展设计的加载器例程被简化为完全同步，这既消除了竞态，也移除了不必要的异步开销。

6. 模块评估的可重入性保障
• 规范限制：ECMAScript 规范规定，一个正在评估中的 ESM 模块不能被再次评估。
• 循环依赖处理：当模块依赖循环跨越 ESM 和 CommonJS 边界时，Node.js 通过检测并抛出 ERR_REQUIRE_CYCLE_MODULE 错误来防止违规的重入评估。未来的 “Deferring Module Evaluation” 提案可能允许安全地跳过同步重入评估，从而支持此类循环。

AI 摘要：作者分享了在使用 React Compiler 过程中遇到的“静默失败”问题，即编译器在无法优化组件时不会报错，而是回退到标准 React 行为，这可能导致性能下降。为了解决这个问题，作者发现并利用了一个未文档化的 ESLint 规则 `react-hooks/todo`，通过将其设置为错误级别，可以在编译失败时中断构建过程。

AI 摘要：本文由 Vercel 的 Lydia Hallie 撰写，介绍如何利用 Vercel 的 Build Output API 构建一个基于 React 的简易 Web 框架，支持静态渲染（Static Rendering）、增量静态再生（Incremental Static Regeneration, ISR）、服务端渲染（Server-Side Rendering, SSR）、边缘函数（Edge Functions）和自动图片优化等功能。文章不仅讲解框架涉及的文件结构和构建流程，还展示如何将每种渲染模式映射为 Vercel 可识别的输出，从而部署到无服务器（Serverless）和 Edge 环境。虽然该示例为教学版，但完整演示了现代框架实现高性能与可扩展架构的关键思路。

1. 框架目标与核心组件
• 通过 Vercel Build Output API 构建自定义 Web 框架
• 实现静态页面、增量渲染、服务端渲染、边缘渲染和图片优化等现代框架功能
• 所有页面位于 pages/ 目录，并根据配置选择不同渲染策略（static、ssr、prerender 或 edge）

2. 页面设计与优化策略
• Landing Page：通过图片优化与 Edge 缓存提升首页首字节时间（TTFB）
• Products Page：结合静态与动态渲染，利用 ISR 实现自动再生更新
• Popular Page：借助 Edge Functions 根据用户地理位置实现个性化推荐

3. 框架实现细节
• Static Rendering：
• 使用 ReactDOMServer.renderToString 将组件预渲染为 HTML
• 输出文件结构至 .vercel/output/static，生成可 Hydrate 的 JS 包
• Incremental Static Regeneration (ISR)：
• 创建 .func 文件夹与 prerender-config.json 配置缓存过期与再生逻辑
• 增设 fallback HTML 提供渐进体验
• Serverless Functions：
• 每个动态页生成一个 Lambda（serverless）函数，用于按需（re）生成页面
• 利用 .vc-config.json 定义运行时、入口点与上下文
• Edge Server Rendering：
• 在 Edge Runtime 中使用 React 进行服务端渲染
• 动态注入 req 对象以生成个性化内容

4. 自动图片优化（Automatic Image Optimization）
• 自定义 Image 组件，将图片请求代理至 /_vercel/image
• 基于 vercel.config.js 生成 .vercel/output/config.json，统一图片格式（webp/avif）、域名和缓存策略

5. 构建与输出过程（Build Output）
• 遍历所有页面并执行对应的渲染方法
• 拷贝静态资源至 .vercel/output/static
• 自动创建 .vercel/output/config.json 配置文件
• 构建完成后可直接通过 Vercel 部署，享受边缘分发与函数服务

6. 结论
• 框架可作为理解现代渲染机制与 Vercel 部署架构的参考
• 虽非生产版本，但展示了现代框架（如 Next.js）背后的核心逻辑
• 适合框架作者或独立开发者应用 Vercel 的核心特性进行自研集成

Vercel

Build your own web framework - Vercel

Build your own web framework that deploys to edge and serverless infrastructure.

AI 摘要：Bun 宣布被 Anthropic 收购，将作为 Claude Code、Claude Agent SDK 等产品的核心基础设施。Bun 保持开源与 MIT 许可证，团队与路线图不变，继续专注于高性能 JavaScript 工具和 Node.js 兼容性建设。此次加入为 Bun 带来长期稳定性与更充足资源，也让团队处于 AI 编码革命的前线，加速产品迭代，助力 AI 驱动的开发模式未来。

1. 加入 Anthropic 的背景与不变之处
• Anthropic 收购 Bun，旨在让其成为 Claude Code 与未来 AI 编程工具的运行基础。
• Bun 将继续开源（MIT 许可）、在 GitHub 公开开发，保持原团队管理与代码维护。
• 路线图不变，持续聚焦高性能 JavaScript 工具与 Node.js 替代能力。

2. 与 Anthropic 合作后的变化
• 更紧密参与 Claude Code 与 Claude Agent SDK 的性能优化，让工具更快更轻。
• 获得 AI 工具一手开发动态，Bun 能优先适配未来 AI 编程需求。
• 加速发布周期，强化生态深度。

3. Bun 的起源与演进
• 起点是开发浏览器 voxel 游戏时的性能瓶颈，促生对编译与运行时系统的探索。
• 从 esbuild 移植 JSX/TypeScript 编译器到 Zig，用 JavaScriptCore 构建自有运行时。
• 2022 年发布 Bun v0.1，集打包器、编译器、运行时、测试与包管理于一体。
• 后续版本：
• v1.0（2023 年）正式稳定，融资并扩张团队；
• v1.1 补齐 Windows 支持；
• v1.2 强化 Node.js 兼容与扩展数据库客户端；
• v1.3 加入前端开发服务器、Redis/MySQL 驱动，生产应用激增。

4. AI 编码工具的崛起与契合
• 2024 年后 AI 编码工具突飞猛进，Bun 的单文件可执行特性非常适合 CLI 与 Agent 分发。
• Claude Code、FactoryAI、OpenCode 等关键 AI 工具均基于 Bun。
• 团队自用 Claude Code 实现自动提交与错误修复，提升开发效率。

5. 可持续性与发展方向
• Bun 至今无直接营收，原计划构建云产品，但 AI 生态发展已重塑商业逻辑。
• 加入 Anthropic 避免了 VC 变现压力，转而获得长期稳定支持与核心地位。
• 与其在未来 AI 开发趋势之外摸索，不如进入中心参与制定。

6. 未来展望与愿景
• 目标成为 AI 时代的标准运行时，让 Bun 承载“AI 驱动软件开发”的基础层。
• Anthropic 为其提供长期资源、战略支持与招聘扩展。
• 持续对社区开放、保持 Node.js 兼容、加速工具链性能提升。
• 预期形态类似「Claude Code <> Bun」关系，类比于「Chrome <> V8」等组合。

Bun

Bun is joining Anthropic

Bun has been acquired by Anthropic. Anthropic is betting on Bun as the infrastructure powering Claude Code, Claude Agent SDK, and future AI coding products & tools.

yousa (@y0usali): 我把前几天在Trae的分享整理成了文字稿
「https://yousali.com/posts/20251124-how-to-coding-with-ai/」
这篇文章写给已经在或准备在真实生产项目里用 AI Coding 的后端 / 全栈工程师和技术管理者。
它不会教你「按钮在哪里」「哪个 prompt 最神」，而是想在大约 15 分钟里，帮你搞清楚三件事：
哪些任务交给 AI 最「划算」；
怎么让项目本身变得更「AI 友好」，提高一次命中率；
当生成不再是瓶颈时，工程师应该如何设计验证流程，把时间花在真正值钱的地方。

AI 摘要：作者总结三年 AI 编程经验，指出 AI 写代码的时代关键不在「准不准」而在「值不值」。文章从个人与团队两个视角分析了 AI 生成代码的最佳使用场景（高重复、低风险、易验证）、如何构建「AI 友好」项目，以及工程师心态从「写代码」到「验代码」的转变。核心结论是：生成已不再是瓶颈，验证才是新的核心；AI 的上限取决于给它的上下文（Context）。标准化与自动化是让 AI 值得信赖的关键，而工程师应成为定义任务与设计验证系统的「总工程师」。

1. 两种声音与早期弯路 —— 从试验到思考
• AI 编程存在两极化认知：「神迹」与「玩具」并存。
• 初期盲目尝试，成功靠运气，暴露问题在于目标定义不清。
• 结论：关键在于明确「让 AI 干什么」，而非讨论「准不准」。

2. 从关注准确率到计算性价比 —— 「甜点区」的发现
• 引入「效率增益」公式衡量 AI 协作的价值。
• 四类高性价比任务：高重复、高耗时、低风险、易验证。
• 案例：模块化模板 + few-shot 示例提升生成质量。
• 心态转变：接受 AI 错误，注重系统级可靠性。
• 工程协作比喻：把 AI 当成「聪明但不熟悉项目的实习生」。

3. 团队视角的优化 —— 让项目更「AI 友好」
• 数据显示企业中 20%–30% 新代码由 AI 生成，但效率提升有限。
• 关键差异在于：项目是否标准化与自动化。
• 标准化**：统一接口规范、术语表、文档说明，让人机共享上下文。
• 自动化：降低验证成本，AI 助力 pre-commit、自动测试、CI/CD 等流程。
• 实践公式：讲清规则 → AI 辅助执行 → 人专注高价值审查。

4. 工程师的心理负担与注意力管理
• 高频切换任务使「注意力成本」爆炸，人类像「上下文很小的 LLM」。
• 心流（flow）被碎片化交互打断，导致疲惫与效率下降。
• 自救方法：时间分层、AI 时分复用、三分钟原则、沟通卫生与单线专注。
• 重点转移：保护注意力等于提升系统整体吞吐。

5. 稳定的两条工程原则
• 原则一：生成已非瓶颈，验证是核心
• 聚焦测试、监控、回滚机制。考核应基于 Bug Lead Time 而非代码量。
• 原则二：上下文为王（Context is King）
• 上下文完整度决定 AI 产出质量。
• 推广路径：统一规范 → 写进仓库 → 自动化验证。
• 单句箴言：AI 写代码的水平 = 你提供上下文的水平。

6. 给三类读者的建议
• 新手：从小型任务切入，先找「值不值」感受。
• 重度用户：从优化上下文与验证流程入手。
• 管理者：亲自尝试，引导从「个人提速」走向「团队工程化」。

AI 摘要：本文介绍了通过将动画关键帧 (@keyframes) 设计为可重用的 Keyframes Tokens，来实现动画系统的标准化与可维护化。作者说明了动画重复定义与全局作用域冲突带来的问题，提出以集中式样式表、命名空间、可定制的 CSS 自定义属性（custom properties）和设计 tokens 的方式来统一所有动画。文中展示了 fade-in、slide-in、zoom、spin、pulse 等动画的动态实现，并讨论了动画叠加、组合 (animation-composition)、可访问性 (prefers-reduced-motion) 与实际项目实施策略。核心思想是：让动画像颜色、字号、间距一样成为可管理的系统资源。

1. 动画混乱的根源
• 各组件独立创建重复的 @keyframes，导致代码冗余。
• CSS keyframes 属于全局作用域，容易被后加载样式覆盖。
• 修改或统一动画需全局搜查，影响维护效率。

2. 统一的解决方案：Keyframes Tokens
• 将动画关键帧集中存放在共享样式表中，形成唯一数据源。
• 利用命名空间（如 kf- 前缀）避免命名冲突。
• 借助 CSS 自定义属性实现动态参数化，支持多场景适配。
• 使动画定义与其他 design tokens（颜色、间距等）协同管理。

3. 构建基础动画库
• Fade In：定义基础淡入动画并统一调用。
• Slide In：通过自定义属性 --kf-slide-from 控制入场方向。
• Zoom：用 --kf-zoom-from/to 实现双向缩放。
• Spin/Pulse：封装连续动画，可控制旋转幅度、脉冲强度。
• Bounce/Elastic：展示复杂缓动（easing）动画封装方法。

4. 动画组合与冲突处理
• 可将多种动画组合，如 fade+slide 或 zoom+pulse。
• 对同一属性冲突时使用 animation-composition: add; 合并动画效果。
• 适当使用动画时间错位（stagger）提升视觉节奏。
• 说明 transform 与单独变换 (translate/scale) 的执行顺序差异。

5. 无障碍与减弱动效（Reduced Motion）
• 利用 prefers-reduced-motion 提供无动画或柔和过渡版本。
• 对需要仍然变换属性的动画定义瞬时完成（instant-in）版本。
• 保留必要动效但平滑化运动，提升可访问性。

6. 实施策略与最佳实践
• 渐进引入：从常见动画（fade、slide）着手。
• 命名规范：统一前缀标识 token 动画。
• 文档化：在 token 文件添加注释说明用途与参数。
• 灵活性与简洁性：仅暴露必要自定义属性。
• 融入设计体系：将 keyframes tokens 视为 design language 的一部分。

Smashing Magazine

Keyframes Tokens: Standardizing Animation Across Projects — Smashing Magazine

Animations can be one of the most joyful parts of building interfaces, but without structure, they can also become one of the biggest sources of frustration. By consolidating and standardizing keyframes, you take something that is usually messy and hard to…

AI 摘要：本文系统阐述了如何制定一套有效的网站性能监测策略，从 Google 的核心指标 Core Web Vitals（包括 LCP、CLS、INP）出发，结合合成测试（Synthetic test）与真实用户监测（Real User Monitoring, RUM），构建可持续的性能优化循环。作者提出“识别 → 诊断 → 监控”三步法，强调在持续对比与回溯的过程中找出性能瓶颈，利用工具如 DebugBear 完成检测与验证，实现网站在用户端和技术端的双重优化。

1. 网站性能指标基础
• 无单一定义性能标准，推荐从 Google Core Web Vitals 入手，包括 LCP（Largest Contentful Paint）、CLS（Cumulative Layout Shift）、INP（Interaction to Next Paint）。
• 除核心指标外，还需分析技术层面指标（如服务器响应时间、页面体积），并可利用 User Timing API 自定义关键加载节点。

2. 合成数据与真实用户数据（Synthetic vs Real User Data）
• 合成测试环境可控，便于重现和分析性能问题。
• 真实用户监测基于实际访问数据，可洞见不同用户群体的真实体验。
• 建议双管齐下：Synthetic 提供细节层面的技术分析，RUM 补全真实使用场景的覆盖。

3. 三步法优化流程
• Identify（识别）：通过用户数据发现加载缓慢页面，优先处理高访问量且体验差的页面。
• Diagnose（诊断）：分析瓶颈点，按指标类型分别使用 RUM 或 Synthetic 工具定位问题来源，如 LCP 图像加载、INP 交互事件延迟。
• Monitor（监控）：建立持续检测机制，监测变更效果并在性能回退（Regression）时即时响应。

4. 深入分析阶段
• 负载时间调试：Synthetic 数据帮助精确定位加载瓶颈，可做实验验证优化方案。
• 交互延迟诊断：RUM 数据揭示实际用户交互的慢响应来源，例如脚本阻塞或后台任务负载。

5. 性能回退检测与应对策略
• 合成数据回退：通过前后 Test 对比结果，定位资源变更带来的性能波动，例如新增图片竞争带宽。
• 真实用户回退：需区分访客来源变化（如广告流量）与技术改动，通过分析 LCP/INP 子部分（subparts）锁定性能劣化来源。

6. 综合结论
• 单次测试仅是起点，持续的性能监控体系才能确保长期高效。
• 工具如 DebugBear 可整合 Synthetic 与 RUM 数据，实现可视化性能追踪与优化决策。

Smashing Magazine

Effectively Monitoring Web Performance — Smashing Magazine

There are lots of tips for [improving your website performance](https://www.debugbear.com/blog/improve-website-performance?utm_campaign=sm-10). But even if you follow all of the advice, are you able to maintain an optimized site? And are you targeting the…

AI 摘要：本文系统解析了 JavaScript 中 Source Map 的内部机制，从 TypeScript 构建流水线到 Source Map 的 JSON 结构与 Base64 VLQ 编码，作者逐步展示了浏览器如何通过这些映射信息，将压缩后的生产代码还原回开发者可读的源文件位置。

1. 引言：Source Map 的作用
• 解释 Source Map 如何连接构建后的 “生产代码” 与原始源文件
• 举例说明浏览器在 DevTools 中如何利用 Source Map 还原源码位置

2. TypeScript 构建管线（Build Pipeline）
• 概述现代 JavaScript 构建的三个阶段：转译 (Transpilation)、打包 (Bundling)、压缩 (Minification)
• 展示原始 TypeScript 源文件示例（add.ts / fibonacci.ts / main.ts）
• 强调每个阶段 Source Map 保持了源代码映射关系

3. Source Map 文件结构
• Source Map 为 JSON 格式，通常以 .js.map 结尾
• 字段详解：
• version：版本号（通常为 3）
• file：对应的生成后文件名
• sourceRoot：源文件路径前缀
• sources / sourcesContent：原始文件路径和内容
• names：标识符数组（变量与函数名）
• mappings：压缩映射字符串（核心内容）
• 指出 mappings 字段使用 VLQ 编码进行空间压缩

4. 理解映射机制：VLQ 编码 (Variable Length Quantity)
• mappings 字符串由逗号与分号组成，分号分行、逗号分列表示段（segment）
• 三种 segment 格式：
• 单值：仅表示生成列位置
• 四值：完整的源映射
• 五值：包含原始名称索引（变量或函数重命名时使用）
• 说明相对位置编码（delta encoding）原理——通过存储偏移量而非绝对位置实现高压缩率

5. VLQ 编码的工作原理
• 每个数字通过以下步骤编码为 Base64：
1. 编码符号位（sign bit）区分正负数
2. 拆分成 5 位数据块+1 位延续标志 (continuation bit)
3. 使用 Base64 字符表映射（A–Z, a–z, 0–9, +, /）
• 举例说明数字 7 如何被编码为 “O”
• 总结其节省空间与高效解析的优点

6. 实例解读与调试意义
• 通过 add.js.map 的 decode 过程展示行列映射
• 演示如何由压缩代码精确反查到原始 TS 源文件行列
• 强调 Source Map 在前端调试、错误定位和代码回溯中的核心地位

Do more with less. | Polar Signals

The Inner Workings of JavaScript Source Maps

A deep dive into how JavaScript source maps work under the hood, with examples showing how all the pieces fit together.

AI 摘要：本文介绍了一种名为 “Stacking” 的开发工作流，用于优化传统的 Git 分支与代码评审流程。它通过将大型改动拆分为多个相互依赖的、小而独立的 PR，实现并行开发与评审，显著减少等待时间与合并冲突。文章还提及多种自动化工具，可帮助开发者轻松管理 Stacked PRs，从而在团队协作中显著提高代码质量与生产效率。

1. 开发与评审的痛点
• 传统代码评审流程耗时长，对开发者与评审者都是负担。
• 分布式团队受时区影响，沟通与迭代周期延长。
• 在等待评审期间，作者被迫停滞，影响特性迭代与开发效率。

2. 为什么需要 Stacking
• Stacking 将开发和评审流程并行化，可在上一个 PR 尚未合并前继续开发下一步工作。
• 通过拆分大型改动为多个小型、依赖性的 PR，减少复杂度，使每次评审更聚焦。
• 改动间的依赖关系清晰，能更安全地选择性合并各 PR，保持项目演进的灵活性。

3. 手动 Stacking 的困难
• 每个分支都需递归 rebase（再基化），遇上上游改动时需层层同步，极为繁琐。
• Git 原生命令行（CLI）对该流程支持有限，手动处理冲突成本高，容易出错。

4. 支持 Stacking 的工具生态
• GitHub 集成方案：具有 CLI、VS Code 插件与 Web UI，可同步管理栈式 PR。
• 开源 CLI 工具：如 ghstack、git-branchless 等，提供抽象化的 stack 操作流程。
• Meta 的新版本控制系统含原生 Stacking 支持。
• Git 新选项 --update-refs 为 stacking 流程带来更多便利。

5. 采用 Stacking 的价值
• 推动开发者以更模块化的思维进行编码，提升代码可读性与长期可维护性。
• 有助于团队快速理解、学习或回滚更改。
• 不论语言、架构、仓库结构（polyrepo/monorepo），Stacking 均可适用。
• 一旦熟悉该模式，多数开发者会主动维护 5–10 个 PR 栈，形成高效的持续开发节奏。

AI 摘要：本文介绍了由 Vercel 提供的 next-devtools-mcp 套件，它利用 Next.js 16+ 的内置 MCP (Model Context Protocol) 端点 /_next/mcp，让 AI 编码助手（如 Claude、Cursor、Gemini 等）直接访问开发服务器的实时运行数据，包括构建错误、运行错误、TypeScript 类型检查、页面路由、Server Action 定义、日志与配置，从而显著提升调试与代码生成的智能化水平。

1. Next.js 16+ 的内置 MCP 支持
• 自 Next.js 16 起，框架内置 /_next/mcp 端点，可暴露实时的项目状态信息。
• 该端点支持 next-devtools-mcp 包进行自动发现与对接，无需额外配置。

2. 安装与集成方式
• 针对不同 AI 编辑器（Claude Code、OpenAI Codex、Google Gemini）提供简易的 npx 安装命令。
• 其他编辑器可通过在项目根目录添加 .mcp.json 文件实现集成。
• 重启开发服务器后，next-devtools-mcp 自动发现并连接 MCP 端点。

3. 实时错误访问与改进
• 在传统环境中，开发者只能复制错误日志手动传给 AI；
• 使用 MCP 后，Claude 等助手能自动获取错误堆栈、类型及关联代码文件；
• AI 可即时分析、修复并验证结果，大幅减少人工往返操作。

4. 内置工具与功能说明
• get_page_metadata：返回路由、组件与页面结构信息。
• get_project_metadata：暴露项目配置与依赖。
• get_server_action_by_id：查询特定 Server Action 定义。
• get_logs：访问开发服务器日志。
• nextjs_docs：查询官方文档并提供版本相关代码参考。
• upgrade_nextjs_16：运行 Next.js 16 升级代码改造。
• enable_cache_components：配置缓存组件并执行预检。
• browser_eval：通过 Playwright 集成运行浏览器测试。

5. 版本兼容与限制
• Next.js 16+ 获得完整支持，包括实时错误、状态与日志访问。
• Next.js 15 及更低版本仅支持部分功能，如升级脚本与文档查询。

1. 发布概况
• Vitest 在过去一年内从每周 700 万下载增长至 1700 万，社区影响力显著提升。
• 经过近一年的开发，Vitest 4.0 正式发布。
• 该版本包含若干重大变更（breaking changes），需参考迁移指南进行升级适配。

2. Browser Mode 稳定
• Browser Mode 结束 Beta 阶段，正式进入稳定版。
• 支持在真实浏览器中运行组件测试，不再局限于 JSDOM 等模拟环境。
• 使用相同的 Vitest API，无需修改测试代码。
• 基于 Playwright 等 provider 实现执行环境，但不替代现有 E2E 工具，仅改变测试运行方式。

3. 新增功能与改进
• 视觉回归测试 (Visual Regression Test)：在 Browser Mode 下进行组件截图与参考图对比，用于检测视觉变化。
• Playwright Traces：生成可在 Trace Viewer 中分析的跟踪文件，辅助调试。
• 报告系统 (reporter) 更新、类型感知钩子 (type-aware hooks) 等多项改进。

4. 版本变更与迁移
• 此次为主版本升级，包含不兼容改动。
• 官方提供迁移指南：Migration guide。

5. 未来计划与社区
• 团队将重点优化性能和 Browser Mode 体验。
• 报告问题可通过 GitHub Issues 提交。

void(0)

Announcing Vitest 4.0

Vitest 4.0 is released with Browser Mode being marked stable, Visual Regression testing support, and Playwright Trace support. The Vitest team will focus on performance improvement in the upcoming quarter. This major release includes breaking changes.

AI 摘要：本文详解了作者多年实践总结出的 React 项目结构化思路，以「逐层演进」为主线，从单文件组件到分页驱动(Page-driven)架构，展示了如何通过结构分层与命名规范，实现 React 应用在复杂度与团队协作下的平衡。文章强调不存在唯一正确方案，读者应根据项目规模与团队习惯灵活调整。

1. 单文件阶段（Single React File）
• 初始项目通常包含一个 src/App.js 文件。
• 所有组件起初可写在单文件中，便于快速原型开发。
• 随项目增长，应将可复用组件拆分，以减少冗余和嵌套复杂度。

2. 多文件阶段（Multiple React Files）
• 抽离可重复使用的组件为独立文件，如 List 和 ListItem。
• 通过文件导出（export）定义组件的“公共接口”(API)。
• 使用文件扩展名策略（.js/.jsx/.ts/.tsx）统一文件规范。
• 建议仅对可复用组件拆分，不要过早抽象。

3. 文件夹化阶段（From Files to Folders）
• 随组件复杂度增加，将相关技术关注点（测试 test、样式 style、类型 type、工具 utils）集中在组件文件夹。
• 采用“一个组件一个文件夹”的结构，如 src/list/ 或 src/app/。
• 使用 index.js 作为模块对外出口（即“barrel 文件”），控制组件的公共 API。
• 讨论命名规范（如 .spec.js、.module.css）与层级深度（避免超过两级嵌套）。
• 建议尽量避免过深目录，用功能聚合代替结构嵌套。

4. 技术型文件夹（Technical Folders in React）
• 当项目达到中等规模，应区分“组件类”与“技术类”逻辑。
• 在 src/ 中增设按技术职能划分的文件夹：
• components/：组件逻辑
• hooks/：自定义 React Hooks
• context/：应用全局状态
• services/：通用服务（格式化、错误追踪、请求封装等）
• 服务示例通过 Intl API 实现日期格式化并由模块封装暴露。
• 推荐使用路径别名（alias，如 @/services/...）避免相对路径混乱。
• 指出 barrel 文件的利弊——简化导入但可能削弱 tree-shaking。

5. 功能型文件夹（Feature Folders in React）
• 大型项目中，按“业务领域（Feature）”划分文件夹，以聚合其内所有组件与逻辑。
• 结构区分：
• feature/：业务特定代码（如 user、post、payment）
• components/：跨 feature 可复用的 UI 组件
• services/hooks/context：依旧保留为全局可重用逻辑
• 每个 feature 内可包含对应 components/、services/ 等子文件夹以划分技术关注点。
• 帮助团队并行开发、限域依赖，提高可维护性与灵活性。

6. 页面驱动结构（Page Driven Structure）
• 当应用存在多页面（特别是 Next.js 或 Vite + React），建议围绕 pages/ 或 app/ 文件夹组织。
• 每个页面对应入口点 (page.tsx)，并链接相关 feature。
• 在同页面内是否嵌套 feature/取决于其复用度与作用域；鼓励保持一致的目录结构。
• 比较 Next.js 的文件路由与客户端路由在结构设计上的差异。
• 最终形成具有多层抽象但一致规则的工程化结构，支持扩展与团队协作。

7. 总结与启发
• 无绝对正确的文件结构，应随项目自然演化。
• 遵循“按复用程度而分层”，“按技术职能而归类”，“按业务边界而划分”的原则。
• 五步推进法可帮助开发者在项目复杂化时保持组织清晰。

www.robinwieruch.de

React Folder Structure in 5 Steps [2025]

React Folder Structure in 2025 for large React projects. The guide walks you through a file structure from small to large project ...

AI 摘要：Vite+ 是在 ViteConf 上发布的全新统一工具链（unified toolchain），旨在整合构建、测试、格式化、代码规范检查和库打包等开发环节，解决 JavaScript 工具碎片化与性能瓶颈问题。它在 Vite 基础上新增 vite new、vite test、vite lint、vite fmt、vite lib、vite run、vite ui 等命令，并基于 Rust 实现完整编译链以实现极致性能。Vite+ 将采用 “source-available” 的商业许可策略，对个人及开源用户免费，对企业采取付费订阅模型，目标是构建可持续的前端生态。

1. Vite+ 简介
• 来源于 Vite，同样可从 npm 安装；作为简体升级版，整合更多开发命令。
• 目标是提供统一的前端工程体验，使复杂项目的开发、测试与构建更加高效。
• 与 React、Vue、SvelteKit 等框架无缝兼容，并可直接用于单体或 monorepo。

2. 核心特性与命令集
• vite new：生成新项目或为 monorepo 生成代码模块。
• vite test：由 Vitest 驱动，兼容 Jest API，支持浏览器测试、分片和可视化回归测试。
• vite lint：集成 Oxlint，支持类型感知检查，性能比 ESLint 快百倍。
• vite fmt：即将发布的 Oxfmt 格式化工具，兼容 Prettier，提供更多换行与格式控制能力。
• vite lib：用于构建库，集成 tsdown 与 Rolldown，自动生成类型声明。
• vite run：智能缓存的任务执行器，无需显式配置即可获得细粒度缓存。
• vite ui：图形化开发工具，展示模块解析、打包与摇树分析等信息。

3. Rust 驱动的底层实现与性能优化
• 全链路由 Rust 重构实现，包括 parser、resolver、transformer、minifier、bundler。
• 高度性能调优，并被 Framer、Linear、Atlassian、Shopify 等公司采用。
• 暴露 parse 和 transform API，便于二次开发。

4. 解决的问题：JavaScript 工具生态的碎片化
• 多项目多团队导致依赖不一致、安全审核复杂与工具迁移成本高。
• Vite+ 旨在提供统一、协同的工具基础架构，减少配置、调试与迁移成本。
• 通过一致的命令与生态整合，提升开发协作效率。

5. 商业化与开源策略
• 将采用 “source-available” 策略：个人、开源、小型团队免费使用；企业需订阅授权。
• 收费部分将反哺 Vite+ 及其基础开源项目（Vite、Vitest、Rolldown、Oxc）。
• 承诺上述基础项目始终保持 MIT 开源许可。
• 目标是在维持社区信任与生态创新的前提下，探索开源项目的可持续商业模式。

6. 计划与参与方式
• 预计 2026 年推出公开预览版。
• 招募早期试用用户，可访问 viteplus.dev 参与测试。
• 官方希望社区共同塑造 Vite+ 的发展方向。

void(0)

Announcing Vite+

Introducing Vite+, a unified toolchain for JavaScript.

AI 摘要：本文指出传统手动编写 REST API 的方式存在重复、易错和效率低等问题，建议开发者在 2025 年采用基于 schema 的声明式 (declarative) API 架构。文章通过对比 Express + yup 的旧式流程与 tRPC + Zod 等现代框架的 schema 驱动方案，展示了后者在类型安全、自动文档生成和开发效率上的明显优势。文末总结，这一趋势代表了 API 开发范式的转变：不再从零搭建 REST，而是借助框架实现「单一事实源 (Single Source of Truth)」的自动化、类型安全和可维护性。

1. 传统 REST API 的问题
• 以 Express + yup 为例，展示编写一个 POST /users 接口的流程需要多次定义相同结构（TypeScript 接口与验证 schema），违反 DRY 原则。
• 手动设置中间件、类型转换、错误捕获、更新文档等步骤繁琐且易出错。
• 代码重复导致类型不同步、文档过时等潜在风险。

2. 基于 schema 的声明式解决方案
• 引入 tRPC + Zod：仅需定义一次 schema，即可自动推导类型、内建验证、生成文档。
• 省去中间件与显式类型转换，错误由框架统一处理。
• 实现「一份定义，三方同步」：类型、安全与文档共用同一 schema。

3. 行业框架的趋势与示例
• Hono：以标准 Web API 语法结合 zValidator 内置验证，简化 Express 式编写。
• Fastify：通过 schema 改进性能，将类型安全转化为运行时效率，并生成 JSON Schema。
• NestJS：通过装饰器 (decorator) 方式实现 declarative 验证与类型推断，无需手动配置。

4. 对比与优势总结
• 开发速度：传统方案冗长且易同步出错，schema 驱动模式定义一次即可。
• 安全性与可靠性：旧式依靠手动转换，schema 模式实现端到端类型安全。
• 文档维护：旧方式需手写 OpenAPI，schema 模式可自动生成实时文档。

5. 结论与未来趋势
• 手工编写 REST API 已成为反模式，schema 驱动的 declarative 模型是未来标准。
• 关键价值在于「写更好的代码」，而非「写更少的代码」。
• 单一 schema 即为验证层、类型系统与文档源，使开发更快、更安全、更可维护。

LogRocket Blog

Stop writing REST APIs from scratch in 2025 - LogRocket Blog

Writing REST APIs by hand is a thing of the past. Frameworks like tRPC, Fastify, and Hono eliminate boilerplate with schema-driven design, improving speed and safety.