关于 swift-diagnostics
面向 iOS 和 macOS 开发者的调试技能，通过诊断决策树系统排查导航、构建、内存和性能问题。
主要功能
- 01按症状分类的诊断流程
- 02含决策树的参考指南
- 03必要的初步检查
- 04逐项修改并验证
- 05最小复现示例指导
适用场景
- 01排查 NavigationStack 或深链故障
- 02追查 Swift 包构建与依赖问题
- 03检查循环引用和内存增长
- 04诊断构建缓慢或 Xcode 卡顿
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/swift-diagnostics确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/build-issues.mdbuild-performance.mdmemory.mdnavigation.mdxcode-debugging.md详细介绍
Swift 诊断
iOS/macOS 开发的系统化调试工作流。遵循结构化的诊断方法，这些模式可帮助你在几分钟而非几小时内找到根本原因。
参考资料加载指南
只要有一丝可能需要参考资料中的内容，就务必加载对应文件。 拿到相关上下文总比漏掉一种模式或犯错要好。
| 参考资料 | 加载时机 |
|---|---|
| 导航 | NavigationStack 没有响应、意外返回、深度链接失败 |
| 构建问题 | SPM 解析、“No such module”、依赖冲突 |
| 内存 | 保留环、内存增长、未调用 deinit |
| 构建性能 | 构建缓慢、Derived Data 问题、Xcode 卡住 |
| Xcode 调试 | LLDB 命令、断点、视图调试 |
核心工作流
- 识别症状类别 - 导航、构建、内存或性能
- 加载相关参考资料 - 每份资料都包含诊断决策树
- 运行必须的初步检查 - 更改任何代码之前先执行
- 遵循决策树 - 在 2-5 分钟内得出诊断结果
- 应用修复并验证 - 一次只做一项修复，逐项测试
核心原则
80% 的“神秘”问题都源于可预测的模式：
- 导航：路径状态管理或目标位置设置
- 构建：缓存过期或依赖解析
- 内存：计时器/观察者泄漏或闭包捕获
- 性能：环境问题，而非代码错误
系统地诊断。切勿猜测。
常见错误
-
跳过必须的初步检查 — 未运行诊断（清理构建、重启模拟器、重启 Xcode）就直接修改代码，意味着你会追查并不存在的问题。务必从必须的检查开始。
-
一次更改多项内容 — “我来删除 DerivedData，再重启模拟器，还要结束 Xcode 进程”，这样你就无法确定究竟是哪项修复起了作用。一次只更改一个变量。
-
自以为知道原因 — “NavigationStack 不工作了，肯定是我的 reducer 有问题”——实际上问题出在过期的 DerivedData。诊断决策树可以避免先入为主。遵循决策树，不要猜测。
-
忽略内存问题的基础知识 —
deinit未被调用意味着存在保留环，但新手往往会归咎于架构。重构前先使用 Instruments 确认泄漏。依据数据，而非直觉。 -
没有隔离问题 — 使用整个应用进行测试会让诊断变得复杂。只保留有问题的功能，创建一个最小可复现示例。隔离问题有助于找到根本原因。
评论
支持 Markdown