swift-concurrency

swift-concurrency 技能概览

这个技能能做什么

swift-concurrency 技能帮助你更少靠猜测地处理 Swift Concurrency 问题：async/await 重构、actor 隔离、Sendable、任务结构、严格并发警告，以及 Swift 6 迁移中的各种坑。它适合需要实用的代码审查和决策建议，而不只是术语解释的时候。

适合谁使用

当你在以下场景中，适合使用 swift-concurrency 技能：

• 将代码迁移到 Swift 6 或更严格的编译器检查
• 修复数据竞争、actor 隔离错误或 Sendable 警告
• 用 async/await 替换回调
• 在 @MainActor、自定义 actor、nonisolated 或 task group 之间做选择
• 在发布前检查代码是否足够 concurrency-safe

它和普通方案有什么不同

这个 swift-concurrency 技能是面向决策的。它强调隔离边界、structured concurrency，以及会改变诊断结果的编译器设置。原因在于，同一段代码在不同语言模式和工具链下，可能是可用的、只是警告很多，甚至直接是错误。

什么时候不太适合

如果你只是想快速回顾语法，一个通用提示词可能就够了。只有在答案取决于项目上下文、编译器行为或真实迁移路径时，swift-concurrency 技能才更有价值。

如何使用 swift-concurrency 技能

在正确的仓库上下文里安装

先在你的 skills 环境里走 swift-concurrency install 流程，然后把它用在你正在编辑 Swift 代码的仓库中。一个典型的安装命令是：

npx skills add Joannis/claude-skills --skill swift-concurrency

如果你的环境使用的是别的 skills 管理器，也要保持同样的 skill slug，并把目标指向 Joannis/claude-skills 仓库。

提供合适的输入形状

有效的 swift-concurrency usage 应该从具体代码目标开始，而不是笼统主题。建议包含：

• 你想修改的文件或类型
• 编译器错误或警告原文
• 目标是 Swift 5.x 还是 Swift 6
• 已知的话，相关的隔离边界
• 是否涉及 UI 代码、服务端代码或共享模型代码

好的提示词：

把这段基于回调的网络代码重构成 async/await，但只在需要时才把 UI 更新放到 @MainActor。我们现在用的是 Swift 6，编译器在 Sendable 捕获上有警告。

不够好的提示词：

帮我处理 Swift 并发。

先读对的文件

为了更快、更安全地得到结果，先看 SKILL.md，再看最相关的参考文件：

• references/glossary.md：术语说明
• references/async-await-basics.md：转换模式
• references/actors.md：隔离和 actor 访问
• references/sendable.md：捕获与传递问题
• references/performance.md：并行与争用

如果你在做生产架构或测试相关工作，也要看看 references/production-patterns.md 和 references/testing.md。

通常有效的工作流

1. 先定位准确的警告、错误或重构目标。
2. 确认隔离域：main actor、自定义 actor，还是 nonisolated。
3. 判断这是不是结构化并发问题，而不只是语法清理。
4. 先要求最小且安全的修复。
5. 然后再补一轮，处理性能、可测试性或 Swift 6 清理。

swift-concurrency 技能常见问题

这不就是一个更好的 Swift Concurrency 提示词吗？

不是。swift-concurrency 技能是一个可复用的指南，带有基于仓库的约定，专门处理隔离、Sendable 和迁移决策。只要答案取决于编译器模式，或者任务和 actor 的组织方式，它就比通用提示词更有用。

我必须已经懂 async/await 吗？

不需要。这个技能对初学者也有帮助，但前提是你能提供代码和错误信息。如果你只知道想要的行为，给一个最小示例，让技能来帮你组织并发模型。

它适用于服务端 Swift 和 App 代码吗？

适用。两者都能用，但建议会不同。UI 代码通常需要 @MainActor；服务端或库代码通常需要更窄的隔离范围，并且对 Sendable 和任务结构更谨慎。

什么时候不该用它？

不要把 swift-concurrency 用在其他语言里无关的 async API 问题上，或者问题纯粹是业务逻辑、完全没有 actor、task 或编译器并发相关因素的时候。如果你无法提供足够上下文来识别隔离边界，它也不太合适。

如何改进 swift-concurrency 技能

先把编译器事实说清楚

对结果提升最大的做法，是一开始就说明你使用的语言模式和工具链。Swift 5.10、Swift 6 以及 strict concurrency 设置，可能会导向不同答案。能贴出准确的警告原文就更好。

说明边界，而不只是症状

当你说明状态存放在哪里、谁在访问它时，这个技能的表现会更好。比如：

• “这个 cache 会被多个 request task 共享”
• “这个 view model 会更新 UIKit 状态”
• “这个 parser 应该不要放在 main actor 上”

这能帮助 swift-concurrency 技能在 actor 隔离、nonisolated、@MainActor 或 task grouping 之间做出更合适的选择。

先要求最小且安全的改动

一个好的 swift-concurrency guide 请求，应该优先要求一个改动最小、能干净编译的修复。如果后面还需要更深入的帮助，再继续追问性能、取消机制或架构层面的调整。这样可以避免为了“一刀切”加 @MainActor，或者不必要地使用 Task.detached。

跟进下一条警告，而不是直接重写

拿到第一版答案后，把下一条编译器诊断或运行时问题反馈回来。最好的 swift-concurrency for Code Editing 工作流是渐进式的：先修一个隔离问题，重新编译，再根据新的输出继续收敛 Sendable、取消机制或任务结构。