当 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 的运行方式。

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

前一期内容｜全部周报列表

感谢阅读！如果有所收获，请点点「在看」支持 ❤️

🚀 拓展你的Swift视野

• 💌 邮件订阅| 在 weekly.fatbobman.com^[1]获取完整的周报内容与独家技术洞察
• 📚 深度文章| 访问 肘子的Swift记事本^[2]探索 200+ Swift/SwiftUI 实战教程
• 👥 开发者社区| 加入 Discord^[3]与 2000+ 中文开发者交流实战经验

原创

两个 SwiftUI 动画 Bug 排查小记^[4]

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

近期推荐

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

在 SwiftUI 中封装带状态的业务逻辑，你第一时间会想到什么方式？放进视图？写成 modifier？Rick Van Voorden^[6]提供了一个不太常见但很有 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?)^[7]

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

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

SwiftUI 3D is Flat^[9]

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

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

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

在当前 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()^[12]

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

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

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

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

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

工具

Quiver：用 Swift 学线性代数与经典机器学习^[16]

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

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

SwipeCell v3：SwiftUI 原生的侧滑菜单^[19]

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

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

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

求贤

资深 iOS / Swift 工程师^[20]

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 / 语音方向加分

👉 详细参见^[21]

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

往期内容

#142 SPI 加入 Apple，Swift 迈向自举

#141 Swift 还让你 Excited 吗？

#140 WWDC 26：AI 帮你看完了，然后呢？

THANK YOU

点点「在看」♥️，帮助本文推荐给更多同行；转发分享，助力更多开发者成长 👊