Swift/Xcode 编译慢时定位编译热点并给出源码级优化…

当开发者反馈 Swift 或混合语言项目编译慢、类型检查告警多、clean build 编译阶段耗时高、CompileSwiftSources 任务过长时，用构建计时摘要与 Swift 前端诊断定位热点并产出建议优先的优化方案。

适用场景

解决思路

1. 从证据出发，优先使用最近的 `.build-benchmark/` 产物或原始 timing-summary 输出。
2. 调查阶段优先使用仅分析的编译器 flag，而不是持久修改项目设置。
3. 按预期 wall-clock 影响排序发现，而不是按累计编译时间影响；当编译任务高度并行（各编译类别之和远大于 wall-clock 中位数）时，说明修复单个热点可能只提升并行效率而不减少构建等待时间。
4. 当证据指向并行工作而非串行瓶颈时，把建议标注为“减少编译器工作量（并行）”而不是“减少构建时间”。
5. 未经开发者明确批准，不要修改源码或构建设置。
6. 检查 clean 和增量构建的 `Build Timing Summary` 输出。
7. 检查长时间运行的 `CompileSwiftSources` 或单文件编译任务。
8. 检查 `SwiftEmitModule` 时间——大模块中单行改动后可能达到 60s+；若它在增量构建中占主导，说明模块可能过大或宏过多。
9. 检查 `Planning Swift module` 时间——若该类别在增量构建中异常大（每模块可达 30s），说明存在意外的输入失效或宏相关的重建级联。
10. 用 `-Xfrontend -warn-long-expression-type-checking=<ms>` 和 `-Xfrontend -warn-long-function-bodies=<ms>` 做临时运行。
11. 深入调查时使用更详细的诊断 flag：`-Xfrontend -debug-time-compilation`（按文件编译时间，排序最慢文件）、`-Xfrontend -debug-time-function-bodies`（按函数编译时间，无过滤，补充基于阈值的告警 flag）、`-Xswiftc -driver-time-compilation`（driver 级计时以隔离 driver 开销）、`-Xfrontend -stats-output-dir <path>`（每个编译单元的详细编译器统计 JSON，用于根因分析）。
12. 检查增加桥接工作的 Swift 与 Objective-C 混合接口。
13. 判断主要问题是整体编译量过大还是少数极端热点。
14. 解析 timing-summary 各类别并排序最大的编译贡献者。
15. 运行诊断脚本暴露类型检查热点：`python3 scripts/diagnose_compilation.py --project App.xcodeproj --scheme MyApp --configuration Debug --destination "platform=iOS Simulator,name=iPhone 16" --threshold 100 --output-dir .build-benchmark`，它会产出超过毫秒阈值的函数和表达式排名列表；结合诊断产物与源码检查，优先关注最昂贵的文件。
16. 把证据映射为具体的建议列表。
17. 把代码级建议与项目级或模块级建议分开。
18. 优先查找这些模式：昂贵表达式中缺少显式类型信息；难以类型检查的复杂链式或嵌套表达式；delegate 属性类型为 `AnyObject` 而非具体协议；过大的 Objective-C 桥接头或生成的 Swift-to-Objective-C 接口；跳过框架限定、无法复用模块缓存的头文件导入；从未被继承却缺少 `final` 的类；仅内部使用的符号却有过度宽泛的访问控制（`public`/`open`）；应拆分为子视图的单体 SwiftUI `body` 属性；没有中间类型标注的长方法链或闭包。
19. 每条建议包含：观察到的证据、可能受影响的文件或模块、预期等待时间影响（例如“预计减少 clean build 约 2s”或“减少并行编译工作但不太可能减少构建等待时间”）、置信度、应用前是否需要批准。
20. 若证据指向项目配置而非源码，则转交给 `xcode-project-analyzer`：读取其 SKILL.md 并在同一项目上下文应用其工作流。
21. 在建议持久修改构建设置之前，先建议通过构建命令临时注入 flag。
22. 优先把巨大的 view builder、闭包或 result-builder 表达式收窄为更小的带类型单元。
23. 当显式导入和协议类型能减少编译器搜索空间时，建议采用它们。
24. 当混合语言边界才是真正问题时，明确指出，而不是只归因于 Swift 语法。