Kotlin Multiplatform iOS…

当 Kotlin Multiplatform 项目的 iOS 或共享框架构建（linkDebug*/linkRelease*、XCFramework、CI 冷构建）过慢时，用测量驱动的诊断和一组安全修复来提速。

适用场景

解决思路

1. 先分类慢场景：确定四个事实——位置（本地还是 CI）、目标（debug 反馈循环还是 release/分发产物）、状态（首次构建、clean、warm 还是 no-op）、阶段（日志中哪些任务占主导），再对照症状表匹配主因。
2. 对照症状表定位：本地循环里出现 linkRelease* 或 *ReleaseXCFramework 说明在为开发构建分发产物；CI 每次运行都下载 Kotlin/Native 编译器分发说明 ~/.konan 未被保留；首个任务开始前长时间停顿说明配置阶段未启用配置缓存；只需一个模拟器却构建所有 iOS 目标说明任务过宽或存在未使用目标；ksp* 任务排在 compileKotlinIos* 之前说明原生路径上有生成代码工作；小改动却重编译重链接全部说明编译器缓存被禁用或缺少增量；多个 link* 任务并行导致机器过载说明原生链接并行。
3. 从项目根目录运行只读静态审计脚本：scripts/audit-native-build.sh /path/to/project，它会打印 file:line 发现项（缓存被禁用、过宽的本地任务、transitiveExport、过宽的 KSP 配置、CI 缺少 .konan 缓存），每项都指向对应参考文件中的修复方法；发现项只是线索而非结论，需对照项目策略确认。
4. 找到用户真正等待的命令：某个脚本、CI 步骤或 Xcode 构建阶段内的 Gradle 调用，优化该命令而不是自己挑选的任务。
5. 实际可行时把该命令运行两次：首次构建会下载 Kotlin/Native 组件并填充缓存，只有第二次及之后才有代表性；在归咎编译器前先按任务归因耗时，可设置 kotlin.build.report.output=file（写入 build/reports/kotlin-build/），也可用 Gradle 的 --scan 或 --profile。
6. 如果无法运行构建（没有 macOS 主机、没有 Xcode），改为分析日志、构建扫描或已提交的指标，并明确说明结论是静态分析得出的。
7. 按安全顺序逐个应用修复并每次重新测量：第一步恢复健康默认值——移除缓存/守护进程的临时绕过，启用 Gradle 构建缓存和配置缓存，在 CI 中保持 ~/.konan 预热，更新 Kotlin 版本。
8. 第二步只构建反馈循环所需内容——每个循环只跑一个具体任务，使用正确的集成方式，目标矩阵要有依据。
9. 第三步削减导出与生成代码成本——去掉 transitiveExport，收窄 export(...)，把 KSP 工作限定到真正需要它的原生编译。
10. 第四步最后才在用户同意下启用实验性开关。
11. 验证：重跑完全相同的基线命令，warm 构建对 warm 构建比较（不要 warm 对 cold）；第二次运行配置缓存应报告被复用；本地开发日志不再包含 linkRelease*、*ReleaseXCFramework 或被移除的生成器任务；CI 仍产出所有必需的 release 产物且不变；测试通过且应用仍能从 Xcode 运行；audit-native-build.sh 不再报告你未有意接受并记录的发现项。
12. 收尾时写一份简短性能说明：慢场景（本地/CI、debug/release、cold/warm）及测量证据（或说明分析是静态的）；每项改动及其为何对 release 行为安全；用户可自行运行以确认收益的前后命令；剩余权衡（启用的实验性标志、基于策略假设移除的目标、worker 限制、推迟的生成代码工作）；以及相关官方文档链接。

适用边界 · 注意事项

• 无法运行构建（没有 macOS 主机或 Xcode）时，只能做静态分析，不能声称已测量验证。
• 不要为了加快本地循环而改变 CI 发布的内容或必需的 release 行为。
• 不要在未与用户确认的情况下启用实验性开关或移除目标（如 iosX64）。