2026-第二十八周

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

技术

使用 FastAPI 服务前端：实用指南

FastAPI 的 app.frontend() 功能允许开发者直接从后端服务静态前端应用，实现 API 和前端在同一服务中运行，简化部署流程。

• 🚀 核心功能：app.frontend() 可服务静态前端构建目录（如 React、Vue、Svelte 等），同时保持 API 路由优先级
• ⚡ 路由优先级：FastAPI 路径操作优先于前端文件，确保 API 不会被前端路由覆盖
• 🔄 SPA 支持：通过 fallback="index.html" 参数处理客户端路由，如 /dashboard 直接返回 index.html
• 📁 项目结构：典型结构包含 dist/ 目录（存放构建后的 HTML、CSS、JS）和 app/ 目录（存放 FastAPI 代码）
• 🎯 使用场景：适合内部仪表盘、管理界面、原型或小型产品；不适合需要 SSR、CDN 或独立部署的大型项目
• 🛠️ 开发建议：本地开发使用前端开发服务器（如 Vite），生产部署时由 FastAPI 服务构建后的静态文件
• 🔗 前缀支持：通过 APIRouter 和 prefix 参数可将前端服务在 /admin 等子路径下
• ⚠️ 注意事项：服务静态构建输出而非 SSR；大文件应使用 CDN；前端构建工具需正确配置基础路径

使用 progress() 实现流式排版 – Master.dev 博客

本文探讨了使用现代 CSS 进行流体排版的新方法，通过progress()函数解决传统预计算方式中忽略用户字体大小偏好的问题，并提供了完整的实现步骤与未来展望。

• 📐 问题根源：传统流体排版将断点转换为 rem 单位，导致用户调整基础字体大小时，排版比例失真，违背用户偏好。
• 🔄 解决方案：使用 CSS 中的progress()函数进行范围映射，直接在浏览器中计算，避免单位转换带来的问题。
• 🛠️ 核心实现：通过progress(100vi, min-viewport, max-viewport)获取视口位置，结合calc()计算输出范围内的流体值。
• 📏 扩展至比例尺：利用自定义属性和pow()函数，可轻松构建多级流体排版比例尺，支持不同缩放比率。
• 🧩 灵活应用：支持容器查询（100cqi）、取整（round()）及反向缩放，适应多种设计需求。
• 🌐 浏览器支持：progress()在除 Firefox 外的现代浏览器中可用，可通过@supports进行降级处理。
• 🚀 未来特性：@function和calc-mix()将简化代码，实现更简洁的流体排版函数调用，但尚未完全普及。

开始使用锚点定位 • Josh W. Comeau

锚点定位 API（Anchor Positioning API）是一种新的浏览器功能，用于将一个元素（目标）附加到另一个元素（锚点）上，例如工具提示或下拉菜单。它通过 CSS 属性（如 anchor-name、position-anchor 和 position-area）实现，并支持自动处理溢出和回退位置，从而避免使用 JavaScript。

• 📌 核心概念：使用 anchor-name 命名锚点元素，position-anchor 指定目标元素，position-area 定义目标相对于锚点的位置（如 top、bottom）。
• 🔄 溢出处理：通过 position-try-fallbacks 属性（如 flip-block 或 bottom）自动检测溢出并切换到回退位置，无需 JavaScript。
• 🎯 绝对定位 vs 固定定位：position: fixed 使目标以视口为包含块，更适合滚动场景下的溢出检测；position: absolute 则以祖先元素为包含块。
• 🛠️ 高级功能：使用 container-type: anchored 和 @container 查询，根据回退位置（如 fallback: bottom）调整样式（如工具提示的箭头方向）。
• 🌐 浏览器支持：截至 2026 年 7 月，支持率约 81%，Level 2（如锚定容器查询）仅 64%。可使用 polyfill 或 @supports 提供降级方案。
• 📚 资源：推荐 CSS Tricks 指南、web.dev 介绍、CSSWG 规范、Anchoreum 游戏等，以深入学习。

《坠落——你没注意时，前端发生了什么》

前端开发经历了从零构建步骤到复杂工具链的演变，最终又回归到以服务器渲染和最小化 JavaScript 为核心的简洁模式。

• 🔧 起点：零构建时代：2008 年，只需保存 HTML 文件并通过 FTP 上传即可发布网站，无需任何构建步骤或依赖。
• 📜 第一层：jQuery 与同步之痛：为了解决页面局部刷新和浏览器兼容性问题，jQuery 应运而生，但手动同步数据和 DOM 导致了新的痛点。
• 🧩 第二层：框架的兴起：React、Vue 等框架通过声明式 UI 和组件化解决了手动同步问题，但引入了运行时依赖和构建步骤。
• 🏗️ 第三层：构建步骤的出现：为了解决模块系统和浏览器兼容性，Babel、Webpack 等构建工具成为必需，但带来了node_modules的臃肿问题。
• ⚡ 第四层：工具链的军备竞赛：为应对构建速度慢的问题，Vite、esbuild 等用 Go 或 Rust 重写的工具出现，大幅提升了开发体验。
• 🔄 第五层：服务器端渲染的回归：为解决 SPA 的白屏和 SEO 问题，Next.js 等元框架重新引入 SSR，但带来了“水合”性能开销。
• 🛠️ 第六层：工程化附加组件：TypeScript、Tailwind CSS、shadcn/ui 等工具解决了类型安全、样式和组件复用问题，成为现代开发的标配。
• ☁️ 第七层：简化部署：Vercel、Netlify 等平台实现了 Git 推送即部署，并支持 Serverless 和边缘计算，比 FTP 时代更便捷。
• 🤖 第八层：AI 编码：v0、Cursor 等 AI 工具可以根据自然语言描述生成前端代码，降低了门槛，但要求理解底层原理。
• 🏁 终点：回归简洁：2026 年的前沿趋势是服务器渲染 HTML、最小化 JavaScript、利用 Web 平台，这与 2008 年的方式惊人地相似。

GitHub - tc39/proposal-error-code-property · GitHub

该提案旨在为 ECMAScript 错误对象标准化一个 code 属性，以提供机器可读的错误标识符，从而改善错误处理、跨环境传输和生态一致性。

• 📜 核心用例：允许程序通过 e.code === 'ERR_CONNECTION_REFUSED' 等字符串代码精确处理错误，避免依赖易变的消息文本。
• 🔒 稳定合约：错误代码作为文档化、版本化的标识符，提供跨版本的稳定接口，而错误消息可能随引擎或版本变化。
• 🌐 跨环境识别：字符串 .code 属性可跨越结构化克隆、序列化和跨 Realm 传输，克服 instanceof 的局限性。
• 📊 改进遥测：在监控系统中按 .code 聚合错误比按消息聚合更可靠，因为消息在不同引擎和版本间存在差异。
• 🌍 支持国际化：稳定的代码允许错误消息被本地化或映射为用户友好文本，同时保持机器可读性。
• 🤝 生态对齐：标准化一个生态已广泛使用的属性（如 Node.js 的 ERR_* 代码），可减少碎片化并为库作者提供推荐模式。
• 🛠️ 提升开发者体验：文档和工具可引用错误代码（如 ERR_INVALID_ARG_TYPE），开发者能可靠搜索到定义性文档。
• 🚫 范围外：本提案不涉及定义 TC-39 规范自身的错误代码或命名空间，这些内容留待后续提案处理。
• 📚 生态先例：Node.js、Deno、Bun、Cloudflare Workers 等运行时，以及 axios、Firebase、Stripe 等库已广泛采用字符串 .code 属性。
• 🧩 设计细节：通过扩展 Error 构造函数的 options bag（类似 cause）接受 code，属性可为任意类型，默认不存在，可写可配置，不可枚举。
• ❓ FAQ 要点：标准化属性而非值，避免“字符串类型编程”问题；不定义新错误分类法；不强制使用字符串，但字符串是生态主流；符号代码会牺牲序列化和可读性；错误子类无法解决跨 Realm 和结构化克隆问题。

工具

GitHub - jonas-grgt/ktea: Kafka TUI 客户端 · GitHub

ktea 是一个基于终端的 Kafka 客户端工具，旨在简化与 Kafka 集群的交互操作，支持多集群管理、主题操作、记录消费、消费者组监控、Schema Registry 和 Kafka Connect 集成等功能。

• 🫖 概述：ktea 是一款 Kafka TUI 客户端，类似 k9s 的终端界面，方便用户高效管理 Kafka 集群。
• 🌟 多集群支持：可无缝连接并切换多个 Kafka 集群，支持 TLS 和 SASL 认证。
• 📋 主题管理：支持列出、创建、删除和修改主题，包括分区和偏移量详情。
• 🔍 记录消费：支持文本、JSON 和 Avro 格式的记录消费，并具备强大搜索功能。
• 👥 消费者组监控：可查看消费者组成员和偏移量，跟踪消费滞后情况。
• 🗂️ Schema Registry 集成：轻松浏览、查看和注册 Avro 模式。
• 🔗 Kafka Connect 集成：支持浏览、查看和更新 Kafka Connect 集群。
• 🛠️ 安装便捷：支持 Mac（brew）、Linux 和 Windows 二进制包。
• ⌨️ 导航友好：使用 vi 风格快捷键（j/k 上下移动，d/u 翻页）。
• ⚙️ 配置灵活：所有配置存储在 ~/.config/ktea/config.yaml，可通过 TUI 管理。
• 🚀 开发支持：提供 Docker Compose 测试集群和测试数据生成工具。

PocketJS — 裸机现代网页

PocketJS 是一个能在 8MB 内存下运行现代 Web 界面的框架，通过将繁重工作移至构建时和 Rust 核心，让开发者使用熟悉的前端工具在 PSP 等受限硬件上构建流畅的 60 FPS 界面。

• 🚀 超低内存运行：在 8MB 内存预算内实现 60 FPS 动画，支持 PSP、macOS 等设备。
• 🧩 熟悉的前端工具：支持 Tailwind、Flexbox、Solid 和 Vue Vapor，保持现代开发体验。
• ⚙️ 构建时优化：Tailwind 类在构建时编译为紧凑样式记录，无 CSS 解析器或运行时开销。
• 🖼️ 原生渲染：布局、样式、文本和动画在 Rust 核心中处理，JSX 和信号量保持不变。
• 📱 跨平台兼容：同一 Rust 核心可移植到 PSP、macOS、3DS、Steam Deck、iOS、Android 等设备。
• 🎮 游戏机友好：专为 PSP 等受限硬件设计，支持原生按钮映射和焦点管理。
• 🔧 精细响应式：Solid 和 Vue Vapor 的响应式 API 直接与核心树通信，状态更新高效。
• 📝 清晰文本渲染：Inter 字体字形预烘焙为图集，支持亚像素定位，小屏幕文字清晰。

更新

宣布 TypeScript 7.0 - TypeScript

TypeScript 7.0 正式发布，这是一个用 Go 语言重写的原生版本，速度提升高达 10 倍，并带来了全新的并行化架构和编辑器体验。

• 🚀 性能飞跃：全量构建速度提升 8-12 倍，例如 VS Code 代码库从 125.7 秒降至 10.6 秒；编辑器首次报错从 17.5 秒缩短至 1.3 秒以下。
• 🧠 并行化架构：引入 --checkers（类型检查器数量，默认 4）和 --builders（项目构建器数量）标志，可进一步利用多核 CPU 实现更高加速（如 VS Code 达 16.7 倍），同时提供 --singleThreaded 单线程模式。
• 💾 更低内存占用：在多数项目上内存使用减少 6%-26%，例如 VS Code 从 5.2GB 降至 4.2GB。
• 🔧 编辑器全面支持：基于 LSP 协议，支持 VS Code（专用扩展）、Visual Studio、WebStorm 等编辑器，并新增语义高亮、排序导入等缺失功能。
• 🏭 生产就绪：经微软内部（Loop、Office、PowerBI 等）及外部公司（Slack、Vanta、Canva 等）大规模验证，Slack 将 CI 类型检查从 7.5 分钟降至 1.25 分钟，Vanta 获得最高 9 倍加速。
• 📦 安装与兼容：通过 npm install -D typescript 安装；提供 @typescript/typescript6 包实现与 TypeScript 6.0 并行运行，方便工具过渡。
• 👁️ 改进的 --watch 模式：基于 Parcel 文件监听器重写，大幅提升跨平台性能和资源效率。
• ⚠️ 配置默认值变更：strict 默认开启，module 默认为 esnext，target 默认为当前稳定 ECMAScript 版本，types 默认改为 [] 等，需注意调整。
• 🔤 模板字面量类型改进：现在按 Unicode 码点（而非 UTF-16 代理对）分割字符，如 "😀abc" 的 Head 推断为 "😀"。
• 🧩 JavaScript 支持重构：JSDoc 类型推断更严格，废弃 @enum、@class 等旧模式，与 .ts 文件分析更一致。
• 🚫 嵌入式语言暂不支持：Vue、MDX、Svelte、Angular 等需继续使用 TypeScript 6.0，团队正积极合作解决。
• 🔮 未来路线图：7.1 将推出新 API，后续每 3-4 个月发布新特性版本，持续优化性能与体验。

2026 年 7 月 - Base UI 成为默认 - shadcn/ui

shadcn/ui 现已将 Base UI 设为默认组件库，但 Radix 仍受支持且不会被弃用。新项目初始化时默认使用 Base UI，并提供了从 Radix 迁移到 Base UI 的智能工具（技能）。

• 🎉 Base UI 成为默认：新项目运行 npx shadcn init 时，Base UI 是默认选择，Radix 仍可通过 -b radix 参数指定。
• 🔄 Radix 未被弃用：所有更新和新组件仍会同时支持 Radix 和 Base UI，现有项目无需迁移。
• 🛠️ 智能迁移工具：提供了一个“技能”（skill），允许用户逐步将单个组件从 Radix 迁移到 Base UI，同时保持项目可运行。
• 📄 迁移结果透明：每次迁移会生成工作代码、每个组件的详细报告（位于 .migration/ 目录），以及清晰的 Git 历史记录（每个组件一个提交）。
• 🧠 为何用技能而非代码转换：因为用户自定义了代码，技能让 AI 代理理解并保留这些自定义修改，而非机械替换。
• 🚀 推荐使用 Base UI：Base UI 已稳定（1.6.0 版本，周下载量超 600 万），社区选择比例已达 2:1，官方推荐新项目使用。

其他

AI 明显大大提高了我现在的工作效率，我可以同时高效地处理五件事。问题是，这种工作方式使得我整天都在切换上下文，能够真正进入心流状态的时间大大减少。

不久前，程序员的工作还属于冥想类工作。现在变了，更像不停接到厨房出菜的餐厅服务员。

-- 《程序员们现在需要开始冥想了》

我为何停止与人争论 | 一个极客的页面

作者分享了自己从热衷于争论技术正确性到放弃争论的心路历程，指出争论往往无效且有害，并提出了更有效的替代方式：关注自我成长、利用差异创造价值，以及只在他人主动求助时提供帮助。

• 🧠 正确并非绝对有益：正确性会制造对立面，赢得争论意味着制造输家，因此不应将正确视为纯粹的好事。
• 🎭 多数争论关乎自我，而非观点：争论常是自我防御，而非理性探讨；与自我驱动的人争论只会加深对立，应学会识别并远离这类对话。
• ❤️ 人类本质上是情绪动物：人们先有感受，再为感受找理由，用逻辑与情绪争论如同对牛弹琴。
• 🤐 纠正他人往往适得其反：即使出于好意，纠正也常被视为批评；人们更倾向于从自身后果中学习，而非他人的建议。
• 🚪 唯一例外：对方主动求助时：当他人明确请求帮助时，防御心降低，建议才能真正被接纳。
• 💡 利用分歧创造价值：与其争论对错，不如将分歧视为优势；若你相信他人不信之事，这本身就是市场机会，可通过行动而非言语来证明。
• 🌱 你唯一能改变的是自己：无法改变他人，但可通过自我改变影响周围；专注于自我提升，而非强迫他人改变。
• 🗝️ 保持谦逊，持续请求反馈：放下自我，主动寻求他人意见，是自我成长的关键；争论的欲望会阻碍真正的进步。