2026-第三十周

该周报主要为各个地方内容的汇总整理

技术

为了性能，该使用哪个 React Native 动画库？

本文通过构建 60 个盒子同时动画的测试环境，在 Android 90Hz 设备上对比了 React Native 三种动画库（Animated、Reanimated、Ease）在触摸、状态更新、手势拖动和循环动画四种场景下的性能（帧率、内存、CPU 占用），并给出了选型建议，最后补充了 Reanimated 的 Bundle Mode 可大幅降低内存开销的更新。

• 🎯 测试环境：Android 90Hz 设备，New Architecture，Release 构建，60 个盒子同时动画，使用 Maestro 自动化驱动，确保可重复。
• 📊 四种动画类型：触摸弹出、状态更新（平移 + 渐变）、手势拖动、45 秒循环旋转（60 盒子）。
• ⚡ 触摸与状态：三种库都依赖原生驱动，JS 线程几乎空闲（CPU≈4-5%），Ease 帧率最高，Animated 和 Reanimated 差距不大。
• 🖐️ 手势拖动是关键分水岭：Animated 使用 JS 线程逐帧设置值，JS CPU 飙至 29% 且 25% 帧丢失；Reanimated 全程在 UI 线程，JS 几乎空闲（2.9% CPU）；Ease 需每次 React 重渲染，JS CPU 13%。
• 🌀 循环动画：Reanimated 每个节点每帧运行 useAnimatedStyle，主线程 CPU 高达 62%，帧丢失最多；Ease 和 Animated 更轻，Ease 帧率最高。
• 💾 内存对比：Reanimated 默认比 Animated/Ease 多约 50MB（主要在 native heap 140MB vs 98MB）。但启用 Bundle Mode 后，内存降至与对手相当，节省约 100MB。
• 🔧 选型建议：手势拖动必选 Reanimated（保持 JS 空闲）；其他场景（触摸、状态、循环）推荐 Ease（最轻、低 CPU）或 Animated（无额外依赖）；切勿用 JS 驱动的 Animated.setValue 做拖动。
• ⚠️ 60 节点的限制：测试特意惩罚每节点开销，真实场景单个英雄元素时 Reanimated 的 UI 线程负担基本消失，仍是交互最佳选择。
• 🔄 Bundle Mode 更新：仅需修改 babel 配置和 Metro 配置，即可实现约 45% 内存降低，且不影响帧率和 CPU，强烈建议启用。但首次构建需先运行一次 bundle 以生成 worklet 文件。

管理的绝对状态

本文批判前端生态中“状态管理”一词的滥用，指出多数流行库（如 Redux、MobX 等）仅实现状态传播，缺乏时间维度和冲突解决能力。真正的状态管理需要内置向量时钟等机制，以支持有序更新和协作。文章推荐 Y.js、Zero、Fluid 等真正管理状态的系统，它们能实现离线优先和实时协作，呼吁开发者升级认知。

• 🗣️ React 生态中“状态管理”实为概念混乱，这些库只是状态传播工具，并非真正管理。
• 🕰️ 真正的状态管理必须内建时间与顺序概念（如向量时钟），才能正确处理变更与冲突。
• 📦 列举多个流行库（React、Redux、MobX、Zustand 等），它们均不具备时间感知能力。
• 💡 对比真正状态管理系统：Y.js（CRDT）、Zero（同步协作）、Fluid（微软 OT）等，支持离线与实时。
• 🔄 采用这些系统可自然实现离线优先和实时协作，是前端开发的未来方向。
• 🤔 建议开发者正视当前“状态管理”的不足，转向更合适的工具与模式。

Web Locks API - Web API | MDN

Web Locks API 允许在多个标签页或 Worker 中运行的脚本异步获取锁，协调资源共享，防止冲突。锁基于来源（origin）隔离，支持独占和共享模式，并提供诊断和死锁防护功能。

• 🔒 核心功能：脚本可异步获取锁，执行任务后自动释放，确保同一时间只有一个执行上下文能访问共享资源。
• 🌐 跨标签页协调：通过锁名称（如 "my_net_db_sync"）实现领导者选举，仅一个标签页执行同步操作。
• 📝 使用方式：调用 navigator.locks.request() 传入锁名称和异步回调，锁在回调完成后自动释放。
• ⚙️ 可选选项：支持 mode（独占/共享）、ifAvailable（非阻塞获取）、steal（抢占锁）、signal（通过 AbortSignal 超时取消）。
• 🔍 诊断监控：navigator.locks.query() 可查询来源的锁状态，包括持有和等待的锁及其模式，便于调试。
• 🚫 死锁防护：避免嵌套或无序请求锁，可通过超时或良好顺序策略防止死锁，仅影响锁本身，不影响浏览器或其他脚本。
• 🛠️ 接口：Lock 提供锁名称和模式，LockManager 通过 navigator.locks 获取，用于请求和查询锁。
• ✅ 兼容性：自 2022 年 3 月起广泛可用，需安全上下文（HTTPS），支持 Web Workers。

我不再解构一切——马特·史密斯

作者反思了过度使用解构赋值的习惯，指出解构虽能简化代码编写，但可能增加阅读时的认知负担，因此现在更注重代码的可读性而非简洁性。

• 📝 解构并非万能：作者过去习惯对所有对象进行解构，但发现这导致后来阅读代码时难以追踪变量来源，需要“逆向重构”原始对象。
• 🧩 保留对象上下文：例如 project.status 比单独解构的 status 更清晰，因为对象名称提供了额外上下文，避免混淆。
• 🔄 减少不必要的重复：对于简单属性传递（如 <Article title={post.title} />），直接使用对象属性比先解构再传递更直观。
• 🗂️ 延迟解构：在函数参数中，先保留 props 对象，待需要时再解构，便于查看组件接收了哪些属性。
• 🎯 为变量赋予意义：只有当解构能创造有意义的新变量（如 billingAddress）时才使用，而非仅为节省字符。
• ✅ 保留解构的适用场景：局部、聚焦的场景（如事件处理 const { currentTarget } = event）或短生命周期对象（如数组映射）仍适合解构。
• 💡 核心原则：解构前自问“移除对象是否让代码更易理解，还是仅仅更短？”——优先考虑可读性而非简洁性。

工具

GTKX 1.0 RC1：面向 GNOME 栈的灵活 React 平台 | GTKX

GTKX 1.0 RC1 是对框架的彻底重写，从 React reconciler 转变为通用平台，支持 TypeScript 直接驱动 GLib 和 GObject，绑定由本地机器根据 GObject-Introspection 实时生成，React 模型类似 React DOM，同时提供高级组件库、单线程核心、OpenGL 独立包、完整工具链、测试库和 AI 辅助文档，本次 RC 包含大量破坏性变更，迁移路径清晰。

• 🚀 发布候选版本，核心从 React 调和器扩展为通用 GObject 平台，支持 TypeScript 驱动 GLib 和 GObject
• ⚙️ 绑定不再预编译，改为通过 CLI 在本地根据系统安装的 .gir 文件自动生成，始终匹配实际 GTK4 版本
• 🧩 React 模型类似 React DOM，使用 createRoot().render() 启动，GTK 应用本身作为组件，JSX 组件可任意嵌套
• 📦 高级组件（ListView、GridView、ColumnView、DropDown、Menu 等）移入独立包 @gtkx/components，CSS 引擎重构支持嵌套选择器
• 🧵 原生核心从双线程 Neon 重写为单线程 napi-rs，GLib 主循环运行在 Node 线程，无需跨线程通信
• 🎮 OpenGL 支持移至独立包 @gtkx/gl，基于 Khronos 注册表生成，覆盖 OpenGL 4.6 核心特性
• 🔧 CLI 工具完善：代码生成、文档生成、带热重载的开发服务器、GResource 资产管道、类型化 GSettings schema
• 🧪 测试库 @gtkx/testing 大幅增强，提供完整测试函数、Widget 匹配器、自动化清理、用户事件 API，@gtkx/vitest 支持每工作线程无头 Wayland
• 🤖 AI 辅助：@gtkx/mcp 服务器支持 AI 助手浏览项目 API 参考，文档站点新增指南、教程和 API 参考
• ⚡ 破坏性变更：所有导入路径改变，启动方式改为 createRoot() + <GtkApplication>，配置从 package.json 移到 gtkx.config.ts，最低 Node.js 版本要求 24
• 🚀 RC 已发布，使用 npm create gtkx@rc 初始化，要求 Linux、GTK4 开发库、GLib、Adwaita 及 Node.js 24+
• 🗺️ 最终版本发布前收集反馈，通过 GitHub Discussions 或 Issue 提交迁移问题与绑定意外

GitHub - piscinajs/piscina: 一个快速、高效的 Node.js 工作线程池实现 · GitHub

Piscina 是一个高性能的 Node.js 工作线程池库，支持多种任务调度、灵活的线程管理和丰富的功能特性。

• ⚡ 支持线程间快速通信，适用于固定任务和可变任务场景
• 🔧 提供灵活的线程池大小配置，支持最小/最大线程数限制
• 📊 内置运行时间和等待时间统计，包含平均值、百分位数等详细指标
• 🛑 支持任务取消，可通过 AbortController 或 EventEmitter 实现
• 🧩 兼容 CommonJS、ESM 和 TypeScript，支持多函数导出
• 🗂️ 提供自定义任务队列接口，内置高性能 FixedQueue 实现
• 🖥️ 支持 Linux 线程优先级设置（需安装 @napi-rs/nice 模块）
• 🔄 支持背压控制，通过 maxQueue 和 drain 事件管理任务流
• 📡 支持 BroadcastChannel 实现主线程与工作线程的广播通信
• 🛡️ 提供资源限制功能，可设置内存、栈大小等限制
• 🧹 支持优雅关闭（close）和强制销毁（destroy）两种停止方式
• 📈 提供利用率计算，帮助评估线程池的负载情况

Componentry — 适用于 React 的优美动画 UI 组件

• 🚀 由 Vercel OSS 计划支持，提供精美的 React 动画 UI 组件
• 🎨 组件已内置样式和动画，可直接用于生产环境
• 📦 通过命令npx shadcn@latest add @componentry/magnetic-dock快速安装
• ✨ 包含多种交互效果：矩阵雨、滚动速度、无限图标场、磁力线、抖动渐变、动画渐变、磁力坞
• 🖱️ 支持悬停交互体验（如“hover over me”示例）

发布 v3.0.0-alpha.0 · pmndrs/jotai · GitHub

Jotai v3.0.0-alpha.0 预发布版本，包含多项重大变更，如移除旧版 TypeScript、UMD、SystemJS、CJS、Rollup 及旧版 Node/React 支持，采用模块优先和 ES2020 目标，并重新设计构建模块。

• 🚀 移除旧版 TypeScript 支持，提升类型系统兼容性
• 📦 删除 UMD 和 SystemJS 构建，简化打包方式
• 🗑️ 移除 CJS 支持，全面转向模块化
• ⚙️ 直接使用 NODE_ENV，优化环境配置
• 🛠️ 放弃 Rollup，调整构建工具链
• 📉 淘汰旧版 React 支持，提升框架适配性
• 🎯 将目标设为 ES2020，增强现代浏览器兼容性
• ❌ 删除 atomFamily 和 loadable 功能，精简核心库
• 🔄 移除 jotai/babel 和 setSelf，减少依赖
• 🧩 引入 useAtomValueRaw 和 useAtomValueRawSync，改进原子值读取
• 🔧 重新设计构建模块（buildingBlocks），提升可扩展性
• 📝 提供迁移指南，帮助用户平滑升级

pi

该文本介绍了 Pi 代理工具链项目，包括核心包、权限说明、贡献指南、开发流程及供应链安全措施，并鼓励共享开源编码会话。

• 📦 核心包介绍：Pi 项目包含三个主要包：pi-coding-agent（交互式编码代理 CLI）、pi-agent-core（代理运行时，支持工具调用和状态管理）、pi-ai（统一多供应商 LLM API，支持 OpenAI、Anthropic、Google 等）。
• 🔒 权限与容器化：Pi 默认无内置权限系统，运行于用户进程权限下；如需更强隔离，可采用 Gondolin 扩展、Docker 或 OpenShell 模式进行容器化或沙盒化。
• 🤝 贡献与开发：贡献指南见 CONTRIBUTING.md，开发命令包括npm install --ignore-scripts安装依赖、npm run build构建、./test.sh运行测试及./pi-test.sh从源码运行 Pi。
• 🛠️ 构建独立二进制：从 GitHub 发布版源码提取后，运行./scripts/build-binaries.sh --platform linux-x64即可构建独立二进制文件。
• 🔐 供应链安全：依赖管理严格，直接外部依赖固定版本，使用save-exact=true和min-release-age=2，锁文件为依赖基准，CI 使用npm ci --ignore-scripts安装，并定期运行npm audit。
• 📢 共享编码会话：鼓励开源用户使用badlogic/pi-share-hf共享编码会话数据，以改进代理性能，支持 Hugging Face 账户和 CLI 操作。
• 📄 许可证与资源：项目采用 MIT 许可证，更多信息可访问 pi.dev 网站、阅读文档或直接让代理自我解释。

open-slide

Open Slide 是一个面向 coding agent 的幻灯片框架。用户用自然语言描述演示稿，Claude Code、Codex、Cursor 等 agent 负责写 React 页面，Open Slide 负责固定画布、缩放、导航、热更新、演讲模式、素材管理和 HTML/PDF 导出。

• 适合把演示稿当代码管理：每页都是 React 组件，方便版本控制、二次编辑和静态部署。
• 适合 agent 迭代打磨：内置浏览器 inspector，可在元素上留言，再让 agent 批量应用修改。

更新

useTypeScriptCli

此文档涵盖 Next.js 的完整功能、API 参考、配置及实验性功能，重点介绍了 useTypeScriptCli 配置项的使用方法和行为。

• 📚 提供全面的文档结构，包括 App Router 入门、指南、API 参考、配置项及社区资源
• 🧪 useTypeScriptCli 为实验性选项，让 next build 直接调用本地 tsc 命令而非 JavaScript API
• 🔧 需手动启用 experimental.useTypeScriptCli: true，并仅适用于 TypeScript 7+
• ⚠️ 启用后，Next.js 不再应用自定义错误重写和代码帧，诊断输出直接来自 tsc
• 📄 会检查 tsconfig 指定的完整项目（含测试文件和 .next/dev/types），并忽略 --debug-build-paths
• 🛠️ typescript.tsconfigPath 和 typescript.ignoreBuildErrors 仍可配合使用

Astro 7.1 | Astro

Astro 7.1 发布，带来更精细的控制和性能优化。

• 🚀 新增 --ignore-lock 标志：允许同时运行多个开发服务器，方便调试和测试。
• 🔗 完全控制分页 URL：通过 paginate() 的 format 函数，可自定义生成的分页链接（如添加 .html）。
• 🛡️ 更细粒度的 CSP 控制：新增 script-src-elem、style-src-attr 等指令，可单独管理内联脚本和样式策略。
• 💾 降低大内容集合的内存占用：使用 deferRender 选项延迟渲染 Markdown 条目，避免同步时缓存全部 HTML。
• 🧪 实验性内容存储分块：通过 experimental.collectionStorage: "chunked" 将数据拆分为多个文件（每 10MB），突破文件大小限制。
• 📝 日志系统改进：支持通过 URL 配置自定义日志记录器，并提供 AstroRuntimeLogger 类型。
• 🤝 社区致谢：感谢所有贡献者，包括核心团队和外部开发者。

Claude Code 系统提示词演进对比（2.1.141 → 2.1.215）

Phistory 汇集了 Claude Code 各版本的系统提示词快照与差异。对比 2.1.141 和 2.1.215，可以看到其运行约束从通用的工具使用说明，逐步演进为更明确的协作、任务管理与安全执行规范。

• 🧰 工具优先级更清晰：新版强调优先使用专用文件与搜索工具，并鼓励将相互独立的工具调用并行执行。
• ✍️ 代码与沟通风格收紧：要求代码遵循现有项目的命名和注释习惯；对用户的进度说明则强调简短、具体，并在完成后如实报告验证结果。
• 🛡️ 高影响操作需确认：删除、覆盖、发布或向外部服务发送内容等不可逆操作，需要在获得明确授权后执行。
• 📋 任务与记忆机制扩展：提示词增加了任务状态管理和持久记忆的约束，使长会话中的工作跟踪与用户偏好记录更系统化。
• 🤖 编排能力显式化：引入面向多智能体工作流的说明，但要求只有在用户明确要求时才启用大规模并行编排。

其他

我们是否将太多思考外包给了人工智能？

本文探讨了人们将思考过程过度外包给 AI 的现象，并反思了自主思考的价值。

• 🤖 趋势观察：作者观察到，从日常琐事到复杂决策，人们越来越依赖 AI 来替代自己的思考过程。
• 📖 文学警示：引用 Ken Liu 的短篇小说《完美匹配》，描绘了一个完全听从 AI 建议、丧失自主决策能力的主角。
• 🎤 现实案例：在创业活动中遇到一位“麦克风男”，他录制所有对话并让 AI 分析，声称“Claude 比我自己更擅长批判性思考”。
• 🔍 历史对比：AI 的思考外包是搜索引擎的延续，但 AI 省去了用户分解问题、评估来源和综合答案的中间步骤。
• ⚖️ 自主性边界：关键在于区分“辅助”与“替代”，以及谁在为你人生中真正重要的事情做最终决定。
• 🧠 思考价值：作者通过葡萄牙旅行经历，强调在求助 AI 前先自己思考、提出假设的重要性，这本身就是一种有价值的练习。
• 🏫 教育影响：作者母亲发现学生用 AI 完成物理作业，虽然答案全面，但学生失去了解决问题的过程，这引发了关于学习本质的疑问。
• 💼 工作应用：AI 在翻译、编程、备考等领域的应用能提高效率，但需要警惕是否只是将“人类工作”自动化，还是将“人类思考”也一并自动化。
• 🔄 个人反思：作者承认自己也用 AI 分析个人数据，但强调自己仍负责数据收集、问题提出和结果评估，以此与“麦克风男”划清界限。
• ❓ 核心问题：我们究竟在自动化什么？是人类的劳动，还是人类的自主性？是任务，还是思考本身？