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 摘要：本文从零开始手工实现 Git 仓库的内部结构与命令逻辑，解释了 git init、git commit、git cat-file 等操作背后发生的机制。作者通过亲手创建 .git 目录与对象，展示 Git 的核心原理如内容可寻址存储（Content Addressable Storage, CAS）、树对象与提交对象、打包与垃圾回收（garbage collection）机制等，帮助读者摆脱“命令黑箱”的依赖，以理解 Git 的本质优雅与简洁设计。

小众软件

从零开始理解 Git｜纯手工打造 Git 仓库｜太长可以不看 - 小众软件

但实际上，这篇文章不是从零开始，它更像是当你已经使用了很久的 git，熟悉各种操作之后，又想再次重新开始，重新理解 git 是什么的内容。 比如：当你输入了 git init 之后，究竟都发生了什么。

@DIYgod: 一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了 太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

AI 摘要：本文由 Cloudflare 首席架构师 Kenton Varda 撰写，针对独立开发者 Theo Browne 公布的基准测试结果展开调查与回应。原测试显示 Cloudflare Workers 在 CPU 密集型 JavaScript 任务中比 Vercel（基于 AWS Lambda）慢至 3.5 倍。Cloudflare 分析后发现，性能差异主要源自调度算法、V8 垃圾回收参数旧配置、OpenNext 框架实现低效及测试方法偏差。经过多项修复与调优，Workers 性能已与 Vercel 持平甚至超越。文中还披露了 Cloudflare 对 V8 与 Node.js 性能改进的贡献，证明其优化不仅服务自家平台，更惠及广泛的 JavaScript 生态。

1. 基准测试背景与问题调查
• 独立开发者 Theo Browne 公布测试，显示 Cloudflare Workers 明显落后 Vercel
• 两者皆基于相同的 V8 引擎，理论上应相近性能
• 性能差异达到 3.5 倍，引发 Cloudflare 团队深入分析
• 指出测试方法主要反映“等待时间”而非“实际 CPU 使用”

2. 平台调度算法与运行时优化
• Workers “warm isolate routing” 策略导致 CPU 密集型请求排队
• 调整调度算法，让系统更快检测并扩展新 isolate，避免阻塞
• 改进后大幅降低延迟波动，提高自动扩展效率

3. V8 (JavaScript 引擎) 垃圾回收 (Garbage Collector, GC) 调优
• 发现旧参数设定限制了“young generation”空间大小
• 放宽 GC 配置让 V8 自调内存区间，性能提升约 25%
• 改进已全球部署，影响所有 Workers

4. 优化 OpenNext 与 Next.js 性能
• 识别大量不必要的内存复制与 Buffer 分配
• 对流式响应 (Streaming) 做性能补丁，减少冗余数据操作
• 提交多个 PR 改进 OpenNext，包括缓存优化、流管道调度、正则重用等
• 针对 JSON.parse reviver 函数的低效执行向 V8 上游提交补丁，提升约 33% 性能

5. Streams 适配与数据传输改进
• Node.js 与 Web Streams API 转换时存在重复缓冲问题
• 改用原生 ReadableStream.from(chunks) 避免多层拷贝
• 调整 ReadableStream highWaterMark，使字节流读取更高效

6. Node.js 三角函数性能修复
• Node.js 未启用 V8 trig 函数快速路径
• Workers 已默认启用，因此跑分更好
• Cloudflare 提交 PR 修复 Node.js 构建配置，使全生态受益

7. 对基准测试方法的反思与改进
• 本地测试中网络延迟影响 CPU 计算评估
• Cloudflare 与 Vercel 所用硬件代际不同，会引入性能噪声
• Next.js 与 React SSR 测试中存在 force-dynamic 与 NODE_ENV 配置错误导致性能偏差
• 建议未来基准采用可控环境与更准确指标（TTLB 而非仅 TTFB）

8. 后续计划与开放协作
• 所有平台级修复已上线，无需用户手动更新
• 将继续优化 OpenNext 与 V8，推动上游框架改进
• Cloudflare 鼓励社区提交性能测试，团队会分析并修复问题
• 长期目标：通过改进开放源代码基础设施提升整个生态性能

FixupX

DIŸgöd ☀️ (@DIYgod)

一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了

太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

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 摘要：本文探讨了如何利用现代 CSS 的 shape() 函数与 clip-path 属性，构建出带有圆角、延展弧线的标签 (Tabs) 样式。文章从早期依赖多元素遮罩的实现方式出发，逐步演示如何使用 shape() 绘制可响应的标签形状，并通过变量 (CSS Variable) 优化灵活度。后续还包含兼容性 fallback、单方向滚动控制 overflow-inline/overflow-block 的技巧，以及对可访问性 (Accessibility) 实现的反思。

1. 背景与旧方案
• 作者回顾早期制作“round-out tabs”的方案，需要为每个标签使用四个额外元素来模拟圆角连接效果。
• 这种方法复杂、难维护且受限于层叠遮罩实现。

2. 使用 shape() 实现圆角标签
• 介绍 shape() 函数与 clip-path 的结合，能直接以绘图指令定义形状，无需额外 DOM 元素。
• shape() 的指令包含 from、curve、vline、hline 等步骤，用以绘制从矩形裁剪出的弧线标签外形。
• 每一步演示曲线、直线和坐标计算，使形状既可固定又可相对灵活。
• 最终实现完整闭合形状，只显示实际的标签区域。

3. 参数变量化与可动态调整
• 将固定数值（如 10px、20px）抽象为自定义属性 (--tabGirth)，以便根据变量调整标签厚度。
• 使用 Knobs 等交互工具实时修改变量值以测试视觉效果。

4. 外观与行为增强
• 添加 hover 与 active 效果，通过 translate 实现微动。
• 解决非换行标签的滚动问题，利用 overflow-inline: auto 与 overflow-block: clip 控制单方向滚动。
• 使用 filter 为 clip 后的形状添加阴影效果。

5. 浏览器兼容性与 Fallback
• 当前仍有浏览器未完全支持 shape()。
• 提供 @supports 条件判定，未支持时以 border-radius 提供圆角退化方案，保证视觉一致性。

6. 可访问性 (Accessibility) 讨论
• 使用 anchor 作为基础标签实现，并在有 JavaScript 时补上 aria 属性。
• 承认目前键盘导航功能不足，提醒开发者参考更完善的无障碍 Tabs 模式。

7. 相关与延伸参考
• 提到 Temani Afif、Ana Tudor 的圆角或内凹标题组件为现代 CSS 造型提供灵感。

Frontend Masters

Modern CSS Round-Out Tabs

Quite a while back I made a set of “round out” tabs, where the literal tab part of the UI would connect to the content below with a rounded edge that flared out as it connected. A bit tricky of a situation, even now!

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.

AI 摘要：作者通过实验发现，虽然 CSS 无法直接为特定字母（如 "E"）单独设置样式，但可以借助 @font-face 的 unicode-range 特性，为某些 Unicode 字符指定不同的字体，实现“伪定向”样式。这种方法能让部分字符使用不同字体或通过字体文件的多彩功能（如 OpenType 的 COLR 表）来实现颜色变化，从而在不添加额外标记的情况下，产生有趣的视觉效果。尽管样式控制有限，但仍展现了 CSS 与字体技术结合的创造潜力。

1. CSS 与字符定向样式的限制与突破
• 通常看来，CSS 无法直接选择文字中的某个具体字符进行样式修改。
• 作者提出一种“秘密方法”，利用字体层面实现针对字符的视觉差异。

2. @font-face 与 unicode-range 的创新用法
• 定义自定义字体 "Different"，并指定某些 Unicode 码位（如 a, e, i, o, u）。
• 使用 font-family 优先级让目标字符采用不同字体，其他字符保留默认样式。
• 在视觉上形成“部分字符变异”效果，而无需额外 HTML 标记或包裹元素。

3. 可扩展技巧与字体特性应用
• 利用 size-adjust 属性可微调字体尺度，使字符外观稍有变化。
• 利用 WOFF2 格式中的 COLR 表（彩色字体表），可为字体字符添加颜色图层。
• 举例引用多彩像素字体 Street Fighter II Large 1，实现大写字符的彩色展示。

4. 结论：CSS 与字体结合的创造空间
• 尽管 CSS 本身不支持字符级定向样式，但字体技术为前端视觉设计提供了可能。
• 此实验启发开发者通过字体文件与 CSS 结合，实现独特、微妙的文本艺术效果。

AI 摘要：文章围绕 Lighthouse 的新性能洞察 “Optimize viewport for mobile” 展开，分析移动端点击延迟 (300 ms) 的成因及对用户体验与核心网站性能指标 (Core Web Vitals) 的影响。通过剖析 Qatar Airways 的示例，作者说明 JavaScript 覆盖 viewport 设置会导致移动端性能劣化，并给出优化建议：应使用 <meta name="viewport" content="width=device-width, initial-scale=1"> 与 CSS 媒体查询来实现响应式布局，而非固定宽度或 JS 动态改写，从而避免延迟、提升 INP (Interaction to Next Paint)。最后介绍如何利用 DebugBear 持续监测网页性能与真实用户数据 (RUM)。

1. 概述：Lighthouse 新洞察“Optimize viewport for mobile”
• 取代旧的 <meta name="viewport"> 静态检查，采用动态分析判断页面是否真正移动友好
• 若检测失败，用户点击将产生高达 300 毫秒延迟，严重影响 INP

2. 300 毫秒点击延迟的背景与机制
• 浏览器历史上为保留“双击放大”功能而引入延迟
• 当网站非移动优化时，为兼顾可访问性，浏览器继续保留延迟
• 若 viewport 固定宽度（如 desktop 模式缩小版），则自动启用此延迟

3. 案例分析：Qatar Airways 官网 viewport 问题
• HTML 中声明了标准 viewport：width=device-width, initial-scale=1.0
• 但随后被 JS 在两个断点下改写为固定宽度 width=480
• 因此反过来触发非移动优化逻辑，导致交互延迟、INP 崩溃
• 使用 window.screen.width 而非 window.innerWidth，使得问题在 DevTools 模拟测试中难以察觉

4. 优化方案与最佳实践
• 使用标准 viewport 配置：<meta name="viewport" content="width=device-width, initial-scale=1">
• 避免使用固定宽度或在 JS 中修改 viewport
• 采用 CSS media queries 管理不同尺寸布局
• 通过 viewport 宽度进行断点分布，避免依赖物理屏幕宽度

5. 持续监测与性能保障
• 借助 DebugBear 可设定定期性能测试与性能预算 (performance budgets)
• 提供 Lighthouse 集成、图形对比、阈值报警等功能
• 支持真实用户监控 (RUM)，捕获真实点击延迟与 INP 细节
• 推荐结合模拟测试与生产环境监控，确保页面长期稳定

Debugbear

How to Optimize Viewport for Mobile for Faster Interactions | DebugBear

Optimize viewport for mobile for faster interactions is a new Lighthouse performance insight that helps you detect viewports that are not optimized for mobile.

AI 摘要：本文系统介绍了现代 CSS 颜色系统的演变与新特性，重点包括新版 rgb() 与 hsl() 的语法变化、相对颜色（relative colours）的用法、改进的亮暗主题处理方式、颜色空间（colour spaces）的应用，以及应对更广色域设备的新工具。作者旨在帮助不专注设计的开发者高效掌握现代 CSS 色彩特性，从而提高代码一致性与灵活性。

1. 现代 CSS 写法演进
• 从传统的十六进制与函数写法过渡到更灵活的空间分隔语法
• 新版 rgb() 与 hsl() 可直接包含透明度通道，无需“a”版本
• / 用于区分主色值与 alpha 通道，提高一致性
• 空格分隔语法引入新规范以支持更多色彩函数，如 oklch()、hwb()、color()

2. 相对颜色（Relative Colours）

• 允许从已有颜色生成新颜色，通过语法 rgb(from #ff0000 r g b) 实现
• 可结合自定义属性（CSS variables）动态调整不透明度或亮度
• 帮助快速生成同系浅色、深色变化，便于主题一致管理
• 可用于构造组件风格如提示框（toast），只需修改基础色

3. 改进的亮暗主题（Theming）
• 传统方法需在媒体查询与主题类中重复定义变量
• light-dark() 函数允许在单条声明中同时定义明亮与暗色配色
• 结合 color-scheme 可根据用户系统偏好自动切换
• 支持组件级别的独立 color-scheme 控制，增强设计灵活度

4. 颜色空间（Colour Spaces）
• 颜色空间决定浏览器如何计算与过渡颜色
• 支持在 linear-gradient() 中指定颜色空间，如 oklch、lab、hwb
• 新空间可避免传统 sRGB 中的颜色过渡失真
• “longer hue” 参数用于控制渐变方向，生成更自然或彩虹式渐变

5. 扩展色域与精准配色
• 介绍 color() 函数与广色域（wide gamut）空间 display-p3 的使用场景
• 适用于与品牌色或印刷标准（如 Pantone）匹配需求
• 浏览器会自动降级不支持的色域，保证兼容性

6. 展望与总结
• CSS 色彩能力远超以往，包括即将介绍的 color-mix()、oklch() 等函数
• 开发者无需成为设计师，也能直接在代码层面进行色彩管理与调和

Piccalilli

A pragmatic guide to modern CSS colours - part one

Whether you've got a firm grasp on modern CSS colour capabilities, or you're thinking 'I struggle to understand why I should use modern CSS colours at all', then the first part of this article series, by Kevin Powell, is for you.

AI 摘要：React 团队发布 React Compiler 1.0，这是一个稳定且可在生产环境中使用的构建时优化工具。它可自动分析 React 组件与 hooks 的数据流与可变性，实现自动记忆化，从而减少渲染次数并提升性能。该编译器适用于 React 与 React Native，与 Babel、Vite、Next.js、Expo 等生态紧密集成，并提供增量迁移指南和内置 lint 规则以强化 “Rules of React”。此次发布标志着历时近十年的工程成果落地，开启 React 新的性能优化时代。

1. 背景与发布概况
• React Compiler 1.0 正式发布，可在 React 与 React Native 中使用。
• 支持与 Expo、Vite、Next.js 等集成，默认在新项目中启用。
• 历经十年研发，从 Prepack 到 HIR（高阶中间表示 High-Level Intermediate Representation）的多次重构。

2. 编译器原理与功能
• React Compiler 作为构建时优化工具，在 Babel 插件阶段分析 AST（抽象语法树 Abstract Syntax Tree）。
• 通过自动记忆化优化组件与 hooks，可在条件渲染后仍实现 memoization。
• 拥有验证与诊断机制，通过数据流分析发现潜在违反 Rules of React 的代码。
• 与 eslint-plugin-react-hooks 集成，为开发者提供静态规则检测支持。

3. 安装与使用方式
• 支持 npm、pnpm、yarn 等安装方式：babel-plugin-react-compiler@latest。
• 改进了依赖分析算法，支持可选链与数组索引依赖。
• 提供 Playground 与文档供开发者测试优化效果。

4. 性能表现与生产验证
• 已在 Meta Quest Store 等大型应用投入使用。
• 实测初始加载与页面切换性能提升 12%，部分交互速度提升 2.5 倍。
• 性能提升同时保持内存中性，证明优化可靠。

5. 兼容性与 Lint 集成
• 兼容 React 17+，React 19 可直接启用编译器特性。
• ESLint 规则合并入 eslint-plugin-react-hooks@latest，替代独立插件。
• 强化了 setState、ref 等模式检测，防止渲染循环和 unsafe 渲染行为。

6. 与 useMemo / useCallback 的关系
• 默认由编译器自动进行 memoization，大多数情况下无需手动使用 useMemo/useCallback。
• 对需要精准控制依赖的场景仍建议保留或使用手动记忆化。

7. 新项目与渐进式迁移方案
• Expo SDK 54+ 默认启用编译器，Vite 与 Next.js 模板可直接启用。
• 提供渐进迁移指南，帮助旧项目分阶段集成 React Compiler。

8. swc 与构建工具支持
• 支持 Babel、Vite、Rsbuild 等构建工具，swc 插件仍在实验阶段。
• Next.js 15.3.1+ 可显著提升构建性能，Vite 通过 vite-plugin-react 启用编译器。
• 正在与 oxc 团队合作，为未来 rolldown 支持做准备。

9. 升级与版本管理建议
• 未来版本可能改变 memoization 策略，需保持端到端测试。
• 建议固定编译器版本（--save-exact）以避免意外行为变化。
• 强调遵守 Rules of React 以确保编译器优化安全有效。

react.dev

React Compiler v1.0 – React

The library for web and native user interfaces

AI 摘要：本文通过实例展示如何将 GSAP 动画库与 WebGL 着色器（Shaders）结合，以构建沉浸式网页交互视觉。作者从基础的 HTML 布局与 Three.js 场景搭建开始，逐步扩展至通过 GSAP 动画驱动着色器 uniform 参数，实现包括灰阶渐变、点击波纹、鼠标揭示遮罩、点击与按压的流体扭曲、以及基于滚动的动态模糊等复杂 GPU 动效。文章强调 JavaScript 动画时间线与 GLSL 实时渲染逻辑的联动，让网站视觉能以自然、物理感与交互性呈现。

1. 基础设置与 HTML/CSS 结构
• 构建页面容器与隐藏溢出内容，准备 GSAP Draggable 和 ScrollTrigger 绑定。
• 在 Three.js 环境中创建 Stage 类，负责 Renderer、Camera、Scene 管理。
• 使用 GSAP ticker 同步渲染循环，实现动画与渲染一致更新。

2. WebGL Stage 与平面载入
• 使用 TextureLoader 创建平面 (PlaneGeometry)，加载 DOM 中的图片纹理。
• 将 DOM 元素与 Canvas 中的物体同步，通过正交相机的坐标转换函数转换屏幕坐标到世界坐标。
• 替换标准材质为 ShaderMaterial，导入自定义 vertex/fragment shader。

3. 点击波纹与灰阶渐变效果（Ripple + Grayscale）
• 使用 GSAP Observer 监听点击事件。
• 点击后修改 shader uniform uGrayscaleProgress 在彩色与灰阶之间平滑过渡。
• 添加鼠标点击点 uMouse uniform，使过渡从点击中心扩散。
• 加入顶点波动（Ripple）动画，在 vertex shader 中用正弦函数生成波形变形。
• 结合 GSAP Timeline 同步控制灰度和波纹周期。
• 管理多平面状态，实现点击切换与反向第二动画效果。

4. 纹理遮罩揭示（Texture Reveal Mask Effect）
• 引入双纹理 (uTexture, uTextureBack) 并使用 uMixFactor 控制混合。
• 通过鼠标 hover 事件，使用 Raycaster 定位交互对象。
• 在 fragment shader 中基于鼠标坐标生成圆形遮罩，平滑混合两张纹理。
• 悬停时 reveal 动画开启，离开时渐出还原。

5. 点击按压揭示（Click & Hold Mask Reveal）
• 通过 GSAP Observer 监听 onPress/onRelease/onMove，管理按压持续状态。
• 使用异步 Timeline 表现“按住充能—释放复位”的动画逻辑。
• shader 中使用噪声函数 (noise) 与 uTime 动态扰动 mask，制造液态波动感。
• 实现交互中的纹理扭曲、流动与时间关联视觉。

6. 动态模糊轮播（Dynamic Blur Effect Carousel）
• 结合 GSAP Draggable 与 ScrollTrigger 使轮播支持拖动与滚动同步。
• 计算每个平面到屏幕中心的距离，根据距离动态更新 uBlurAmount。
• 在 shader 中使用多重 Kawase 模糊算法，混合多层模糊采样和平滑区间。
• blur 与 scroll 动态联动，创造景深般的焦点模糊效果。

7. 总结与启发
• GSAP 为动画时序与交互逻辑提供流畅控制。
• Shaders 提供像素级视觉自由度与 GPU 实时渲染性能。
• 在 Web 前端中实现生动视觉，展现设计与技术融合的趋势。

AI 摘要：本文由 Prettier 作者 Vjeux 亲述该工具从萌芽到成为 JavaScript 世界事实标准的全过程。他回顾了从学生时代对代码格式要求的启蒙，到在 Facebook 亲历代码风格冲突，并探索各种格式化方案（如 gofmt、dartfmt）失败的原因；最终，他与合作者 James Long 等人推动 Prettier 诞生。文中详述了算法思想（基于 Philip Wadler 的 A prettier printer）、工程推进与开源协作、在 Meta 的落地推广、以及如何彻底终结开发者的格式化争论。最后反思了开源维护的经济困境与对未来开发者工具的展望。

AI 摘要：文章讨论 width: stretch 与 height: stretch 这两个新加入 CSS 标准的属性值。作者回顾其历史背景，说明它如何统一了过去 -webkit-fill-available 与 -moz-available 的实现，并探讨了它与 box-sizing: border-box 的区别、动画特性（animatable）以及当前的浏览器支持情况。文章指出，虽然 stretch 功能简单，但它解决了长期以来 width: 100% 受内边距影响导致溢出的问题，为布局控制带来了更直观、更可靠的选择。

1. stretch 的由来与标准化
• Chromium 浏览器自 2025 年 6 月起支持 stretch，统一了非标准属性 -webkit-fill-available 与 -moz-available。
• 在 @supports 出现之前，开发者难以根据浏览器正确选择对应实现。
• 这一特性被开发者 Dave Rupert 在 Bluesky 平台上重新发现，引起社区关注。

2. stretch 的工作机制
• 行为类似 width: 100%，但忽略 padding，因此不会因内边距造成溢出。
• 从技术上看，stretch 控制元素的 margin box 以匹配包含块的尺寸。
• 对比 box-sizing: border-box ：虽然二者可达相似效果，但 stretch 更语义化且更灵活。

3. 为什么考虑使用 stretch 而非通用 box-sizing
• 使用通配符选择器 * 设置 box-sizing: border-box 无法涵盖所有伪元素。
• 维护完整伪元素列表既繁琐又易错，而 stretch 可减少这类问题。
• 对某些场景而言，开发者可能希望保持 100% 不包含 padding 的默认行为。

4. 动画与过渡特性
• box-sizing 无法被动画化，但 stretch 可与 100% 间平滑过渡。
• 需启用属性 interpolate-size: allow-keywords 才能插值动画。
• 未来可通过 calc-size(stretch, size) 精确控制插值行为。

5. 浏览器兼容性与渐进增强方案
• 当前仅 Chromium 系列 (Opera 122+、Chrome/Edge 138+、Android 140+) 支持。
• 可通过 @supports 设置自定义属性 --stretch，为 Firefox 与 Safari 提供兼容实现。
• 一旦全面支持后，可直接使用 width: stretch。

6. 总结与开发者建议
• stretch 是一种小而实用的布局增强功能，提升工作流质量。
• 即使继续使用 box-sizing 也无妨，但理解并尝试新特性有助于优化设计思维。
• 多一种写法，意味着多一种选择，更贴合个人或项目的编码哲学。

CSS-Tricks

We Completely Missed width/height: stretch | CSS-Tricks

The TL;DR is that stretch does the same thing as declaring 100%, but ignores padding when looking at the available space.