当 Linux 成为“空气”：容器、Agent 与不再重要的“桌面之争” -- 肘子的 Swift 周报 #143

当 Linux 成为“空气”：容器、Agent 与不再重要的“桌面之争”

一周前，微软推出了无需 Docker 的 Windows 11 原生容器支持的公开预览；再结合苹果不久前发布的容器管理器（container）1.0 正式版，一时间，两大主流桌面操作系统都将 Linux 容器深度集成为了系统的一等公民。

这件事引发了一场有趣的讨论。有人认为，这是 Linux 的最终胜利：虽然它始终没能真正赢下桌面市场，但它已经无处不在；也有人提出反问：当 Windows 和 macOS 都能相对顺畅、轻量地运行 Linux 容器时，这究竟是 Linux 的胜利，还是它被彻底“工具化”和“隐形化”的开始？

这两种说法看似相反，其实都触碰到了同一个事实：Linux 的角色正在发生变化。

过去，我们谈论操作系统时，通常是在谈论一个完整的平台。它有自己的桌面、应用、开发模型、用户习惯和生态边界。Windows 是一个平台，macOS 是一个平台，Linux 发行版当然也是一个平台。围绕这些平台，人们讨论份额、体验、兼容性，以及那个已经被反复调侃了几十年的“Linux 桌面元年”。

但容器改变了这个问题的结构。

在现代软件开发中，Linux 越来越少以“你正在使用的操作系统”的形式出现，而是以“默认运行环境”的形式存在。开发者不一定会说“我部署到了 Linux”，他们更可能说“我部署到了 Kubernetes”、“我跑在云上”、“我用了一个容器镜像”。

这种变化在 AI Agent 时代会更加明显。随着 Agent 从简单的聊天助手转向能够真正执行任务的工具，它们需要的不再只是一个对话界面，而是一个轻量、秒级启动、完全隔离且易于销毁的执行环境。容器天然适合承担这种角色。而当越来越多的任务经由 Agent 完成，人与操作系统直接交互的界面，其权重也在悄然下降——那场持续了数十年的“桌面之争”，胜负已经愈发不重要了。

所以，Linux 正在超越“平台”这个身份。它没有成为桌面操作系统份额的赢家，却进入了几乎所有现代计算体系的底层。它没有让所有人都改用 Linux，却让所有平台都不得不支持 Linux 的运行方式。

不是让所有人都高喊你的名字，而是让所有人都离不开你，却又想不起你。这种胜利无声胜有声。

本期内容 | 前一期内容 | 全部周报列表

原创

两个 SwiftUI 动画 Bug 排查小记

易用的动画一直是 SwiftUI 的主要特色之一。但声明式框架的特性是一把双刃剑：动画一旦出现异常，排查往往比命令式框架更棘手。本文记录了过去两周里，我在开发中遇到的两个与 SwiftUI 动画有关的 Bug。与其说是解决方案，不如说是一段排查的心路——希望能为你面对类似问题时开阔一点思路。

近期推荐

利用属性机制重构状态化业务逻辑 (Task Property: Reusing Stateful Business Logic for SwiftUI Views)

在 SwiftUI 中封装带状态的业务逻辑，你第一时间会想到什么方式？放进视图？写成 modifier？Rick Van Voorden 提供了一个不太常见但很有 SwiftUI 味道的视角：利用 DynamicProperty 将状态化业务逻辑从 View 中抽离出来，封装为可复用的动态属性，让 View 回归更纯粹的声明式表达。

项目中的 TaskProperty 只是一个辅助原语，用于在自定义动态属性中管理异步 Task 的生命周期。它很实用，但并不是这篇 README 真正想强调的重点。作者从“如何复用 Stateful Business Logic”这个问题出发，逐步展示了 DynamicProperty 不只是 @State、@Binding、@Environment 背后的机制，也可以成为组织和复用状态化业务逻辑的一种方式。

关于自定义 DynamicProperty 的文章并不多，而本文的特点在于，它没有停留在 API 使用教学上，而是把问题放回业务逻辑组织本身：你的 View 中是否混入了可共享的状态逻辑？这些逻辑是否可以被抽取为更贴近 SwiftUI 生命周期的自定义动态属性？

SwiftUI 地图在航向跟随模式下为何会抖动？(Why My SwiftUI Map Bounced in Heading-Follow Mode?)

Emre Degirmenci 在一个基于 TCA 的地图应用中遇到了一个典型的 SwiftUI + MapKit 边界问题：在 heading-follow 模式下，地图出现持续抖动、相机跳动，甚至定位状态异常退出。有意思的是，同样的 Map 组件在另一个 MVVM 架构的应用中却没有问题，这使得问题从“实现错误”转向了“状态同步模型是否合理”。

核心原因在于 MapKit 在 heading-follow 模式下会产生高频相机更新，而原实现通过双向绑定将更新数据回写到 TCA Store，造成了“MapKit 驱动 → 状态更新 → 再驱动 MapKit”的回路，破坏了系统自身的连续动画逻辑。修复方式为让相机变化保持由 MapKit 自身控制，只在需要时进行显式干预，从而避免状态与系统驱动之间的冲突。

SwiftUI 3D is Flat

在 UIKit / AppKit 中，Core Animation 的 CATransformLayer 提供了真正的共享 3D 空间与深度排序能力，因此不少开发者会自然地认为 SwiftUI 的 rotation3DEffect、projectionEffect 也建立在类似的 3D 场景之上。但 Mihaela Mihaljević Jakić 通过一个实验指出：SwiftUI 并不存在统一的 3D 空间或深度缓冲机制。多个视图在 3D 变换后的结果仍然是“各自独立的 2D 投影”，因此会出现典型的遮挡错误，例如“背面覆盖正面”。

这种行为并非缺陷，而更像是 SwiftUI 有意的设计选择：将 3D 能力限制在单个 view 的投影层面，而不是引入完整的 3D 场景与层级体系。

Safari 推出面向 Web 开发者的 MCP (Introducing the Safari MCP server for web developers)

在当前 AI coding agent 生态中，浏览器自动化长期以 Chrome / Chromium 体系为事实标准（Playwright、Puppeteer、CDP 等），Safari 通常更多作为兼容性验证环境。

Safari MCP server（Safari Technology Preview 247）试图改变这一点：它将 Safari 浏览器会话能力暴露给 agent，使其可以直接访问 DOM、网络请求、控制台日志、截图以及页面状态，从而在 Safari 的真实运行环境中完成调试与分析。这使 Safari 开始进入 agent toolchain 的主路径，而不再只是依赖 Chromium 的间接推断或跨浏览器切换验证。

AI 时代下的“无 UI”趋势思考 noUI()

在当前 AI agent 工具逐渐深入开发与内容生产流程的背景下，UI 的角色正在被重新审视。Jordan Morgan⁠ 从 DOS 风格的命令界面切入，提出一个值得思考的问题：当越来越多的操作可以直接由 agent 通过自然语言完成时，UI 是否仍然需要以“显式界面”的形式存在？

文章中最吸引我的部分，是作者基于 JavaScript 与 CSS 构建了一个可交互的终端界面。这个设计并不仅仅用于示例或演示，而是将文章的论述本身嵌入到一个可操作的 UI 中，使读者在“使用界面”的过程中进入对 UI 形态变化的讨论之中。UI 在这里不只是表达载体，也成为论证的一部分。

重新认识 Mac 活动监视器的各项性能指标 (What does Activity Monitor measure?)

在 AI agent 逐渐进入日常开发流程之后，很多开发者都会有类似的体验：Mac 风扇更频繁启动、内存压力明显上升，但 Activity Monitor 中显示的 CPU / Energy 数值却往往与直观感受并不一致。

Howard Oakley 通过 powermetrics 与多种真实负载对照实验指出，Activity Monitor 中的 CPU % 更接近各 CPU core active residency 的简单叠加，而非传统意义上的“利用率百分比”；GPU % 同样只是 active residency 的近似表达；而 Energy Impact 则主要反映 CPU 层面的功耗估算，既不包含 GPU，也没有很好地刻画时间维度上的能耗变化。

工具

Quiver：用 Swift 学线性代数与经典机器学习

Wayne Bishop 长期维护的《Swift Algorithms & Data Structures》是一部面向 Swift 开发者的算法与数据结构电子书。在最新的第五版中，这本书已经从传统算法、数据结构延伸到向量、矩阵和相似度计算；而 Quiver 则把这条路径继续推进到数值计算、统计和经典机器学习。

Quiver 是一个纯 Swift、零依赖的线性代数、统计与经典机器学习库。它直接扩展 Swift 标准库的 Array，强调值语义、Codable、Sendable，以及在 Apple 平台上的轻量端侧运行。它的目标不是替代 Python 数值生态，而是为 Swift 开发者提供一个用熟悉语言理解线性代数、训练小型模型，并将结果带回 App 的入口。Wayne 在《Swift Algorithms & Data Structures》后续章节中，也正是以 Quiver 作为数学与机器学习基础内容的配套工具。

SwipeCell v3：SwiftUI 原生的侧滑菜单

WWDC 2026 上，SwiftUI 通过新的 swipeActionsContainer() 终于让侧滑菜单走出了 List，可以服务于 ScrollView、懒加载栈以及更多自定义容器。但遗憾的是，这项能力目前需要 anyAppleOS 27 对应的系统版本才能使用。

SwipeCell 是我六年前刚进入 Swift 开发时写下的第一个第三方库。旧版本很稚嫩，但也陪我见证了 SwiftUI 侧滑交互这些年的变化。最近我对它做了彻底的重写，推出了 v3 版本：新的 API 更 SwiftUI 化，配置更完整，交互手感也重新打磨，并加入了 macOS 支持。

目前 SwipeCell v3 发布在 v3-beta 分支，仍处于 beta 阶段，欢迎试用，也欢迎反馈使用中的问题。

求贤

资深 iOS / Swift 工程师

Speak：YC 孵化、OpenAI 多轮投资的 AI 语言学习独角兽。

工作地：上海。

一家在海外多个市场长期验证、商业化成熟的 AI-native 语言学习公司，正在从 0 -> 1 组建中国核心工程团队。团队小而美、不内卷，重度使用 AI(Cursor / Claude Code 等)，看重工程 owner 意识和 agentic engineering 工作方式。

作为中国团队的早期核心 iOS，你将全程参与技术选型,搭建国内 iOS 完整基建、对接本土支付 / 登录 / 合规 SDK、优化 AI 语音实时交互体验,并与全球团队英文协作。

期待你具备:

5 年以上 iOS 原生(Swift)开发经验,有上线的消费级产品
扎实的原生 iOS 深度(性能、稳定性、架构、弱网优化等)
AI-native 工作流(日常用 Cursor / Claude / Copilot 等)
书面英文胜任 PR / Slack / 文档,口语 B1+、能清晰表达技术想法
有国内 App Store 上架 / 本土 SDK 经验者优先;音视频 / RTC / 语音方向加分

👉 详细参见

有意向者欢迎投递英文简历至 a.suen@usespeak.com

往期内容

💝 支持与反馈

如果本期周报对你有帮助，请：

👍 点赞 - 让更多开发者看到
💬 评论 - 分享你的看法或问题
🔄 转发 - 帮助同行共同成长

🚀 拓展 Swift 视野

📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察

👥 开发者社区 | Discord 实时交流开发经验

📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

《当 Linux 成为“空气”：容器、Agent 与不再重要的“桌面之争” -- 肘子的 Swift 周报 #143》是转载文章，点击查看原文。