- Published on
2026-第三十六周
- Authors

- Name
- AgedCoffee
- @__middle__child
该周报主要为各个地方内容的汇总整理
技术
锚点定位入门
CSS Anchor Positioning API 是一套新原生机制,让开发者无需复杂 JavaScript,即可将工具提示、下拉菜单等目标元素固定到页面上其他元素(锚点)上,并自动处理溢出翻转、定位回退和视觉箭头方向调整等常见难题。文章介绍了核心用法、位置回退机制、新版容器查询特性、浏览器支持状况及降级策略。
- 🎯 核心价值:用来解决工具提示/下拉菜单等 UI 元素的“锚定 - 溢出”问题,替代过去复杂易错的原生 JS 实现。
- 🌐 浏览器支持:截至 2026 年 7 月约 81% 支持;Level 2 的“anchored container queries”覆盖率约 64%,目前主要可用在 Chromium,但已纳入 Interop 2026。
- 🧩 基础用法:锚点元素通过
anchor-name命名;目标元素设置position: absolute/fixed、position-anchor指向锚点,再用position-area指定相对位置(类似 3×3 网格)。 - 📏 间距与扩展:可用
margin制造目标与锚点间距;还支持逻辑属性(如inline-start)以及span-*实现跨行/跨列布局。 - 🔄 溢出保护:配合
position: fixed与position-try-fallbacks,当目标元素溢出视口时可自动切换到备用位置(如bottom)。 - 🧠 行为特点:一旦启用备用位置,即使原位置重新有空间也不会自动切回——这符合规范意图,可避免 UI 反复跳动。
- 💡 翻转箭头:通过 Level 2 的
container-type: anchored和@container anchored(fallback: …),可在目标元素使用回退位置时,同步调整 tooltip 箭头 / 内边距等样式。 - 🔃 更简单方案:
flip-block关键字可自动在块轴方向翻转,并同步翻转 margin 等方向相关属性;且已被所有主流浏览器支持。 - 🛠️ 兼容降级:可使用 Oddbird 提供的 polyfill,或用
@supports构建从基础回退到理想体验的分级方案;部分复杂场景仍可继续考虑 JS 库。 - 📚 扩展知识:文章未深入介绍
anchor()/anchor-size()等高级函数;文末附有 CSS Tricks 指南、web.dev、CSSWG 规范及 Anchoreum 练习游戏等学习资源。
STYLEX 深度解析
StyleX 是一种 JavaScript 语法与编译器,用于在构建时将样式对象编译为普通 CSS,使开发体验类似 CSS-in-JS,但浏览器收到的是静态类名,无运行时注入。文章涵盖其核心心智模型、React/Vite 与 Astro 集成、主要特性(组合、变体、伪类、响应式、主题、令牌等)、静态约束、对比其他方案及适用场景,并强调其在编码代理(agent)方面的优势与权衡。
- ⚙️ StyleX 将
stylex.create()中的 JS 样式对象在编译时转为小型可复用原子 CSS 类,组件通过stylex.props()组合类名,无 CSS-in-JS 的生产期注入。 - 🧩 核心要解决的问题:全局类名冲突、样式覆盖不可预测、样式归属不清、未使用 CSS 过多。StyleX 让样式就近组件、类名不可碰撞、冲突按传入顺序解决。
- 🔧 手动配置 React + Vite:安装
@stylexjs/stylex与@stylexjs/unplugin,并在vite.config.ts中先启用stylex.vite({dev,useCSSLayers})再放 React 插件。 - 🔎 调试时可使用 StyleX DevTools Chrome 扩展,通过
data-style-src属性和可读标记类名定位样式来源。 - 🚀 也可用于 Astro:通过 Vite 插件接入,React 组件可静态渲染或无交互时零 JS 输出;全局 CSS 与 StyleX 分层共存。
- 🌱 StyleX 生成原子 CSS:每条声明独立成类,相同属性和值可在全局复用,减少 CSS 重复,HTML 中类名增多但样式表体积增长缓慢。
- ✨ 样式组合使用
stylex.props(styles.card, styles.featured),后传入的样式覆盖前者,冲突由 JS 层在传给浏览器前解决。 - 🎯 支持条件样式(真值/三元表达式)、变体对象查找、
:hover/:focus等伪类,以及@media、@supports等媒体查询,均以“属性优先”结构内联表示。 - 🔑 动态值(如进度条)可通过样式的函数形式实现,编译器会生成静态类 + CSS 变量,将真实值放入
style属性,但参数和函数体受限。 - 🎨 用
stylex.defineVars()创建设计令牌,stylex.createTheme()定义主题变量组;组件消费语义令牌,主题决定具体值。 - 🔓 组件可通过
StyleXStyles类型接受父级传入的样式对象,并可限制允许的 CSS 属性,构成类型化的自定义契约。 - 🎞️ 动画使用
stylex.keyframes()自动生成并引用名称;@stylexjs/atoms提供实用原子类应对小型局部异常。 - ⛓️ StyleX 具有静态约束:样式对象不能使用任意 JS、import 普通值或对象展开,需改用
defineVars/defineConsts或props组合,以保证可编译。 - 🌐 全局 CSS 仅负责 reset、字体、文档默认值等;复杂关系状态需使用
stylex.when和 marker 类,避免全局选择器影响无关元素。 - 🔍 ESLint 插件可检测未用样式、简写冲突、键排序,并能通过
propLimits限制属性允许值(如固定间距刻度),让类型和 lint 约束设计决策。 - 🤖 StyleX 对编码代理尤其有意义:它比 Tailwind 更冗长,但限制了无效选择空间,让代理更不容易写出不一致的样式,也让代码审查更聚焦。
- ⚠️ 代价包括:构建配置更复杂、语法比 Tailwind 类长,第三方组件生态多为 Tailwind,需要转换;依赖纯 JavaScript 组件体系,不适合全局大样式表或内容驱动页面。
- 📊 对比:与普通 CSS、Tailwind、运行时 CSS-in-JS 相比,StyleX 优点是可预测组合和低运行时代价,主要成本是编译器设置和严格规则。
- 🗓️ 适用场景:新 React 应用、组件库增长、大量 AI 或代理编写/修改 UI 时。不适用于小型静态站或 Markdown 内容为主的页面(如 flaviocopes.com)。
- 🏗️ 生产构建后应检查
dist/assets中的 CSS 为哈希原子规则,应用代码中不再存在原始stylex.create()对象,以确认编译成功。
智能体代码质量
在 AI 智能体大规模编写代码的时代,传统人工审查已无法扩展,代码质量取决于你在智能体周围设置的约束与质量门。通过自动化检查、背压机制和有选择地投入人类注意力,才能在高速交付中守住质量底线。
- 🤖 智能体生成的代码量远超人工可读范围,质量必须依赖环境、工具和约束来把关,而非逐行人工审查。
- 🧪 质量门形式多样,包括单元测试、属性测试、验收测试、变异测试,以及圈复杂度等可读性指标,决定提案能否被接受。
- ⚠️ 智能体在信息缺失或任务模糊时可能失败,环境需要提供可信反馈、低损害失败模式和渐进式成功路径。
- 🛡️ 信任必须靠约束与验证来赢得,不能盲目接受智能体的意图或输出,正确性始终需要检查。
- 👁️ 人类注意力是稀缺资源,应聚焦于最需要判断力的复杂问题,只在自动化护栏失效时介入。
- 📊 软件质量不是单一指标,而是正确性、可维护性、性能、安全、效率、可理解性等多维信号的集合。
- 🔁 背压应贯穿整个流水线,从编译器、测试、安全策略到 CI 部署,而不是到最后才做一次终审。
- ⚖️ 当变更量超过验证容量时,可扩展验证系统、降低生成速率或调整质量条,也可在低风险处放宽约束以提升吞吐。
- 🎯 在关键处施加强约束,在无关处放松,平衡创新与质量,并始终保持人类对最终决策的责任。
工具
tailwind-stylex
tailwind-stylex 是一个连接 Tailwind CSS 与 StyleX 的开源工具,它把 Tailwind 的默认设计令牌转换为可直接在 StyleX 中使用的类型安全常量,支持自动补全且免去自定义配置、扫描或生成步骤。
- 🎯 核心目标:让 StyleX 开发者直接复用 Tailwind 默认设计系统,获得类型提示和自动补全体验。
- 📦 安装命令:使用 pnpm 安装
tailwind-stylex和@stylexjs/stylex。 - ⚙️ 编译配置:若用
@stylexjs/unplugin,需在externalPackages中加入"tailwind-stylex";若用 postcss 插件,则需在include中添加node_modules/tailwind-stylex/tokens.stylex.js。 - 💡 基础用法:从
tailwind-stylex/tokens.stylex导入colors、spacing、radii等令牌,并在stylex.create中直接使用;如colors.stone100、radii.lg、spacing[4]。 - 🔢 数值令牌写法:对带数字的名称使用方括号,例如
fontSizes["2xl"]、containers["7xl"]、spacing[8]。 - 🗂️ 令牌分类丰富:提供颜色、布局(间距/断点/容器等)、排版(字体/字号/行高等)、表面效果(圆角/阴影/模糊)、动效(缓动/动画/透视)以及默认值。
- ✨ 编辑器支持:每个令牌都能自动补全并显示精确取值。
- 📜 开源许可:项目基于 MIT 许可证发布,当前拥有 81 颗 Star。
更新
Vitest 5 正式发布
Vitest 5 正式发布,以性能优化为核心,同时带来 Trace View、嵌套项目、vi.when API、基准测试重写、更严格断言等多项新功能与改进。该版本要求 Vite ≥ 6.4.0 和 Node.js ≥ 22.12.0,并包含若干破坏性变更。
- 🚀 性能大幅提升:通过新基准测试框架优化,vm pools、Browser Mode 及大型隔离测试套件提速最明显,部分场景提升超 50%
- ⚙️ 基础性能改进:内联项目共享 Vite 服务器、稳定的文件系统模块缓存、减少主进程与 worker 间通信、加速 vm pools、预打包依赖以缩小安装体积
- 🔍 新增 Trace View:Browser Mode 可记录每一步交互/断言/快照,支持在浏览器 UI、Vitest UI 和 HTML 报告中逐步回放,便于本地调试和 CI 失败分析
- 📂 嵌套项目与配置继承:内联项目默认继承根配置,支持引用自带子项目的配置文件,--project/-p 支持层级过滤
- 🎯 新增 vi.when API:可按参数深度匹配及非对称匹配器定义 spy 行为,并支持 thenReturnOnce/次数限制及 toHaveBeenExhausted 断言
- ⏱️ 基准测试重写:bench 改为测试上下文内可用,支持比较、断言、持久化结果、自定义提供者,且输出集成到默认/json 报告器
- ♿ Locator 错误显示 ARIA 树:更易定位元素问题,locators 默认严格模式,避免意外误匹配
- 🕐 Mocking 支持 Temporal:假计时器和 setSystemTime 可模拟 Temporal API,也可通过 toNotFake 排除
- 🔒 断言更严格:未 await 的异步断言直接失败;expect.poll 支持超时拒绝及 AbortSignal;扩展 Matchers 类型更完善
- 🧹 clearMocks 默认开启:每个测试前自动清空 mock 调用记录,减少顺序相关测试问题
- 📝 报告器更新:统一输出至 .vitest 目录,第三方报告器可用 createReport API,HTML 报告支持 singleFile 单文件导出
- 🛠️ 其他改进:新增 --repeats 选项、可配置 CJS 全局变量注入、扩展覆盖率选项(子进程/阈值)、json/junit 报告器新选项、更美观的测试标题格式等
- ⚠️ 破坏性变更:需升级至 Vite ≥ 6.4.0、Node.js ≥ 22.12.0,升级前请阅读迁移指南
Zod 4.5
- ⚡ 全新
z.compile()可预编译任意 schema,解析速度提升约 3–9 倍,并支持全局自动编译(import "zod/compile")。 - 💳 新增
z.creditCard()字符串格式,校验 12–19 位数字及 Luhn 校验和。 - 🧩 新增
z.properties(),可对z.instanceof()等多属性 schema 批量添加检查。 - 📦 恢复
z.deepPartial()函数形式,支持深层可选字段,并保持ZodObject特性。 - 🎯 新增
.exactPartial(),字段键可省略但显式undefined会被拒绝,匹配 TS 的exactOptionalPropertyTypes。 - ✅ 新增
z.validate()快速布尔校验,无效输入时比.safeParse()快最多 16 倍。 - 🔄 新增
z.input()/z.output(),可独立验证 codec 的输入/输出侧。 - 🏷️ 新增
z.toZod<T>(),帮助定义与静态类型完全一致的 schema。 - 🍎 新增
z.getDiscriminatedOption(),按判别值提取联合成员。 - 🔁 递归 schema 现支持循环输入(Zod Mini 需显式注册 memoizer)。
- 🧠 Schema 内存占用减少 9 倍(
z.string()从 7.5kb 降至 784 bytes)。 - ⚡
.safeParse()失败路径不再捕获堆栈,速度提升约 7.5 倍。 - 🔑
z.object()支持 symbol 键,TS 推断为unique symbol且必填。 - 🐛 多项破坏性修复:
z.iso.datetime()强制要求秒、字符串长度按 Unicode 码点计算、record 键与 TS 对齐、__proto__始终剔除、IP/ULID/URL/emoji 等格式更严格。 - 🌍 新增 8 种语言区域:孟加拉语、中库尔德语、印地语、卡纳达语、新挪威语、巴西葡萄牙语、斯洛伐克语、土库曼语。
- 🤝 汇总 155 个提交,感谢所有贡献者。
其他
责任是先主动承担,而非等他人给予 - Lalit Maganti
文章指出,在大型科技公司中,晋升的关键不是等待别人赋予你责任,而是主动在现有范围内展示判断力与担当。责任是“先被实践,后被授予”的——通过模仿技术负责人的思维、逐步建立信任,你才能在正式头衔到来之前,成为真正的“所有者”。
- 🏢 在 Big Tech 晋升通常需要展示“所有权”,但很多初级工程师误以为必须等经理先给任务。
- 🔄 核心观点:责任是先被证明、之后才被正式授予,顺序不能颠倒。
- 🤔 技术负责人是否敢“给”你责任,取决于你能否用他认可的方式(或更好)处理问题。
- 🧠 作者通过反复琢磨 TL 的思考过程,并主动用那些方法检验自己的方案,逐渐提升了判断力。
- 📊 实例:作者曾认为三个数据结构无关,TL 坚持它们都是“表”,最终这个抽象演变成 Perfetto 上百张表的基础。
- ✅ 信任建立后,作者开始自己设定议程、与用户沟通、决定改进方向,甚至能反驳 TL 的建议。
- 🏅 最终,TL 从“做工具的人”改口称他为“工具的所有者”,责任被正式认可。
- 🚫 这并不等于抢项目或踩别人,而是在自己的职责范围内展现可靠判断,避免越界。
- ⚠️ 在糟糕的管理或政治环境中,这一策略可能失效。
- ⏳ 正式责任是“滞后指标”:人们先信任并尊重你的判断,然后你才获得明确授权。
- 🔑 责任是一点一点主动“拿走”的,而不是一次性“收到”的。
出卖自我
这篇文章探讨了“出卖自我”(selling out)在职场中的含义,特别是针对大型科技公司的软件工程师。作者认为,职业角色扮演并不必然导致马克思或情境主义者所说的“异化”,关键在于保持内心自主性与专业身份之间的平衡。文章分析了马克思、德波、范内格姆、萨特、波伏娃及美国社会学家的观点,指出真正的危险在于完全认同角色或承受长期 humiliation,而技术能力和权力可以缓解这种伤害。作者最终主张,在妥协与保持自我之间找到适合自己的位置,并认为这并非悲剧。
- 🎭 出卖自我如今需要技术和组织运作知识,并非易事;保持纯粹正直则会付出职业与经济代价。
- 📖 马克思的异化有四种含义:劳动增强雇主权力、与手艺分离、身心受损、心理上无法确认自我。
- 💻 对科技从业者而言,前两种不适用,第三种不适用于软件工程,第四种最相关但马克思未深入心理机制。
- 📺 情境主义者德波和范内格姆认为异化是角色扮演,会吞噬真实自我,但承认没人会被完全吞没,仍可挣脱。
- 🧠 萨特和波伏娃的“自欺”指过度认真对待职业角色,将工作价值视为绝对,需要持续自我欺骗;但可以避免。
- 🏢 美国社会学(米尔斯、戈夫曼)指出白领工作常令人屈辱,成为“标准化输家”和“小马基雅维利”,这种屈辱会累积伤害。
- ⚖️ 存在一个妥协谱系:从完全认同公司目标到彻底抵抗,作者自己处于第二点(偶尔第三点),并建议保留独立价值观以防滑入第一点。
- 🛡️ 职业人格与真实自我可以分离,只要保持心理距离;技术能力带来的权力是屈辱的解药。
- 💰 每个人都需与“财神”谈判,决定用多少正直换取财富;若出卖不可避免,至少别白卖。