"又 30 个 G 没了。"Xcode 每次大版本更新，群里都会冒出几句熟悉的吐槽：硬盘告急的、纠结要不要删旧版本的、还有直接问"这玩意儿到底凭什么这么大"的。说实话这三个问题我都琢磨过------删是可以删的，至于为什么大，答案也不神秘：Xcode 不只是个 IDE，它是苹果一整个开发环境的打包。大得有理有据，但"有理有据"不等于"你必须全盘接受"，这篇把体积构成拆开看看，再聊聊另一条轻量路线的取舍。
在 Mac 上先跑三条命令，对"谁在占地方"有个直观印象：
bash
du -sh /Applications/Xcode.app # Xcode 本体
du -sh ~/Library/Developer/CoreSimulator # 模拟器运行时
du -sh ~/Library/Developer/Xcode/DerivedData # 编译缓存我第一次跑的时候也以为最大的会是 Xcode 本体，结果缓存那块紧追不舍------好家伙，一个"临时目录"吃掉的空间快赶上整个 IDE 了。下面按"谁在占地方"逐个说，每块都回答两个问题：它是干什么的、能不能动。
模拟器运行时为什么占这么多？
Xcode 里每跑一个 iOS 模拟器，背后是一份完整的系统运行时（runtime）------每个 iOS 版本一份，一份就是好几个 G。watchOS、tvOS 的 runtime 同理，只是很多人装过一次就忘了它们还在；不做那几个平台的话，那几份完全可以不留。这些年 iOS 版本出得勤，你的机器上很可能躺着四五份，加起来比 Xcode 本体还壮观（不是夸张，是真的）。
那能删吗？能。用不到的旧版本系统可以删掉，在 Xcode 的 Settings → Components 里管理，或者用 xcrun simctl runtime delete 处理。删了就是跑不了对应版本的模拟器而已------判断标准也简单：你最近半年打开过某个旧版本的模拟器吗？没有的话，那份 runtime 基本就可以送走了吧。做回归测试、要给老系统兜底的项目另说，那种情况下这几份该留还得留嘛。
DerivedData 和缓存：可以放心删，但迟早要重编
DerivedData 是编译产物的缓存，几十个 G 是常事，也是"硬盘不知不觉满了"的头号嫌疑。它的特点是：删了完全安全，就是下次编译全部重来一遍的过程（大项目上第一次编译会慢得让你怀疑人生，这是正常的）。
顺带说两个同住一个目录的邻居：Archives 是你的历史出包归档，上架排查问题全靠它，别手滑删了；iOS DeviceSupport 是连真机时留下的符号文件，每个系统版本一份，删了不致命，但下次连那台旧系统的设备时会重新下载。
要清缓存的话，别在 Finder 里乱翻，Xcode 的设置里有专门的位置管理，或者直接删 DerivedData 目录也行------它本来就是个"可再生资源"。另外提一句：编译突然报一些莫名其妙的错、或者补全集体失灵的时候，清缓存也是老江湖们的常规操作，十有八九能好（"重启试试"的 IDE 版本，懂的都懂）。
SDK 与工具链：这部分才是 Xcode 的"本体"
前面两块都算"可修剪项"，真正撑起 Xcode 体积的大头在这儿：各平台 SDK（iOS、macOS、watchOS、tvOS、visionOS 各一份）、Swift 编译器与 LLVM 工具链、Interface Builder、Instruments......这套东西的存在意义就一个：让你能用同一台机器开发苹果所有平台的应用，并且拿到跟苹果官方完全一致的编译结果。
这部分基本砍不动吧------砍了它就不是完整的 Xcode 了。顺带说一个经常被混淆的：xcode-select --install 装的命令行工具是另一码事，它带编译器、不带模拟器和 Interface Builder，有人以为"装了命令行工具就够了"，结果发现模拟器还是跑不了，说的就是这个区别。所以问题反过来问会更清楚：你真的需要"完整的 Xcode"吗？ 做多平台应用、需要 Instruments 做深度性能分析的、要最新 SDK 全覆盖的，需要，而且没得商量。可如果你的日常只是写 iOS App、跑真机、出个包------这条主线用到的东西，其实只是工具链里的一个子集。
只做 iOS 主线的人，另一条路长什么样
这就是轻量方案的立足点。KXApp 这类工具把 iOS 开发主线需要的那部分工具链内置了进来------不用把整个 Xcode 请进硬盘，照样写代码、连真机一键运行、一键构建出包。省下来的不止是几个 G，还有"装完 Xcode 再配环境"那半天的折腾：装好 IDE 直接开项目。再往细了说，各种 AI 代码助手在它上面反正也能直接用（VS Code 的底子在那儿），写起来的体感跟桌面编辑器是一路的。对 256G 硬盘的 MacBook 用户来说，这件事的吸引力可能比想象中大（至少我是这么觉得的）。
当然，话得说两头：这不是"扔掉 Xcode"的宣言。复杂工程配置、深度系统能力调试这些场景，Xcode 依然是标配；KXApp 覆盖的是"写---跑---改---出包"这条高频主线。两者也不冲突，真要装完整的 Xcode 放着备用，也没人拦着。
到底怎么选
按实际需求分一分挺清楚：做多平台应用、重度依赖 Instruments 做性能分析的------完整 Xcode，没有替代品；主要做 iOS 单端 App、机器空间紧张、又不想折腾环境的------轻量方案（KXApp 这类）足够撑起日常；团队的话常见组合是：日常开发用轻量 IDE，CI 流水线上用 xcodebuild 跑完整工具链，各取所需。真要说起来，这两条路也不是楚河汉界，按项目换着用的人多了去了。
再说，磁盘空间每次更新前删删减减，不如一开始就选对路线------毕竟每来一次大版本更新，又是一轮几十 G 的下载和腾挪。Xcode 的体积不是设计失误，是它功能范围的直接体现。 这笔账其实挺好算的：你平时真正用到的功能，占了 Xcode 的几成呢？搞清楚这个，选什么也就清楚了。