macOS 的存储管理长期困扰着开发者和运维人员。当系统报告「系统数据」占用超过 50GB 时，大多数用户的第一反应是清理缓存或删除大文件，但往往收效甚微。问题的根源在于语言资源与代码签名缓存的无序累积 —— 这两个隐藏在系统深处的存储黑洞，占用了大量磁盘空间却极少进入日常清理的视野。理解其运作机制并掌握安全的裁剪方法，是释放系统存储的关键工程实践。
语言资源存储机制与空间占用分析
macOS 采用本地化资源包（Localizable.strings + .lproj 目录）实现多语言支持，每个应用程序通常包含 30 至 50 种语言资源。以 Safari 为例，其语言资源目录中包含英语、中文、日语、德语、法语等数十个语种的字符串文件和格式化规则。这些文件在应用安装时完整复制，但用户日常使用的语言通常不超过两种。根据实测数据，系统内置应用的语言资源总占用可达 3 至 8GB，用户安装的第三方应用额外贡献 1 至 3GB。语言资源位于应用包内的标准路径：.app/Contents/Resources/LANG.lproj，其中 LANG 采用 ISO 639-1 区域代码（如 zh_CN、ja、de）。
开发者可以通过命令行快速诊断语言资源的占用情况。扫描单个应用的语言资源容量使用命令 du -sh /Applications/Safari.app/Contents/Resources/*.lproj，该命令以人类可读格式输出各语种目录的大小。对于批量分析，可以结合 find 和 du 遍历 /Applications 目录，生成按大小排序的语言资源报告。值得注意的是，语言资源的压缩率较高，实际磁盘占用与文件数量并不直接相关 —— 包含复杂复数规则的语种（如俄语、波兰语）往往比简单语种占用更多空间。系统应用的语言资源位于受 SIP 保护的 /System/Applications 和 /System/Library 目录，直接操作需要额外的系统权限配置。
用户域应用的裁剪策略与安全边界
对于位于用户域（/Applications）的第三方应用，语言资源裁剪可以直接执行，无需禁用系统完整性保护（System Integrity Protection）。裁剪流程的核心原则是保留目标语言与英语资源，移除其余语种目录。具体操作分为三个步骤：首先确认应用支持的语种列表，可通过 ls /path/to/App.app/Contents/Resources/*.lproj 查看所有语种目录；其次识别需要保留的语种，通常包括英语（English.lproj）和用户当前系统语言；最后执行删除操作，保留必要目录。
安全裁剪的关键在于验证应用的功能完整性。某些应用将关键资源（如默认模板、帮助文档）存放在非语言目录中，误删可能导致功能异常。建议在裁剪前使用 codesign -dv --verbose=4 /path/to/App.app 验证应用签名状态，该命令输出代码签名详情，包括签名标识、授权级别和密封摘要。裁剪后重新运行签名验证，确认密封未被破坏。若签名失效，应用将无法启动并抛出 EXC_CRASH (Code Signature Invalid) 异常。对于企业内部分发或经过公证（Notarization）的应用，签名验证尤为重要 —— 任何文件修改都会导致 notarization ticket 失效。
批量裁剪可以借助 Shell 脚本实现自动化。脚本逻辑包含三个函数：语种识别函数提取 .lproj 目录列表，保留集函数根据用户配置生成保留清单，裁剪函数执行删除并记录操作日志。建议添加安全锁机制 —— 对签名验证失败的应用自动回滚删除操作，或将删除的目录移动到临时目录而非直接清除，为可能的恢复保留路径。macOS 的 Time Machine 和本地快照会在一定程度上保留历史版本，但依赖快照恢复并非可靠的回滚方案。
系统域应用的受限操作与替代方案
系统内置应用的语言资源位于 SIP 保护区域，直接修改将触发系统保护机制。macOS 从 Catalina 开始引入 Read-Only System Volume，用户无法直接写入 /System 目录。尝试使用 sudo rm -rf /System/Applications/Safari.app/Contents/Resources/fr.lproj 将返回「Operation not permitted」错误。绕过此限制的唯一方式是禁用 SIP，但这会引入显著的安全风险和系统不稳定因素，因此不推荐作为常规维护手段。
对于系统应用的语言资源问题，更稳妥的替代方案聚焦于减少新缓存的生成。macOS 在每次系统更新后会重新生成语言资源缓存，可以通过调整语言偏好设置避免安装非必要语种的系统组件。在「系统设置 > 通用 > 语言与地区」中，仅保留英语和主要使用语言，系统更新时将跳过其他语种资源的下载与安装。此外，Apple 提供「优化存储」功能，可在「关于本机 > 存储 > 管理」中启用，系统会自动卸载未使用的语言资源包。
对于必须释放系统应用语言空间的场景，可以考虑从系统更新包层面切入。在下载完整安装器后，使用 pkgutil 解压更新包，在安装前对语言资源目录进行裁剪，再重新打包安装。这种方式本质上是自定义系统镜像，适用于批量部署场景。操作时需使用 pkgutil --expand 和 pkgutil --flatten 命令，并确保签名流程完整。需要强调的是，自定义系统镜像可能影响 macOS 的安全更新机制和版本升级路径。
签名验证工具链与故障排查
代码签名是 macOS 安全架构的核心组件，任何系统文件的修改都会反映在签名状态中。codesign 命令行工具提供完整的签名验证与诊断功能，是裁剪操作后的必要验证步骤。验证单个应用的签名完整性使用 codesign -dv --verbose=2 /path/to/App.app，输出信息包括签名版本、授权标识和哈希摘要。对于包含多个组件的复杂应用，应分别验证主应用和其嵌入的框架、插件：codesign -dv --verbose=2 /path/to/App.app/Contents/Frameworks/Some.framework。
签名验证失败的常见原因包括文件被删除、移动或修改。codesign 通过计算整个应用包的哈希值检测任何变动，因此语言资源裁剪后必须重新签名才能使应用恢复可执行状态。重新签名命令为 codesign --force --deep --sign - /path/to/App.app，其中 - 参数使用系统默认证书。开发者和企业用户可指定自有证书：codesign --force --deep --sign "Developer ID Application: Name" /path/to/App.app。重新签名后，应用将获得新的代码哈希，原有的 notarization status 失效，需重新提交公证。
故障排查时，查看系统日志提供关键诊断信息。应用启动失败时，控制台（Console）应用会记录 com.apple.security.codesign 相关的错误事件，错误代码 0x2（代码签名无效）表明签名校验失败。对于更隐蔽的问题，可以使用 spctl --assess --type execute /path/to/App.app 检查 Gatekeeper 评估结果，该命令模拟系统对未知来源应用的安全检查。spctl 输出「accepted」表示通过评估，「rejected」表明存在签名或来源问题。
工程实践建议与监控策略
将语言资源裁剪纳入常规系统维护流程，需要建立可重复的脚本化和监控机制。建议维护一份受信任应用清单，明确每个应用的保留语言集和签名状态。清单采用 JSON 或 YAML 格式，记录应用标识、路径、当前版本和最近一次验证时间。裁剪脚本每次执行前加载清单，执行后更新验证状态并在验证失败时触发告警。
磁盘空间监控应区分 System Data 的细分类目。「系统设置 > 通用 > 存储」提供宏观视图，但无法定位具体的膨胀来源。命令行工具 du -sh 配合 sort -h 可生成目录占用排名：sudo du -sh /Library/Caches/* 2>/dev/null | sort -hr | head -10。对于更细粒度的分析，第三方工具如 DaisyDisk 提供可视化视图，但命令行方式更适合自动化集成。语言资源裁剪的效果可通过定期快照对比验证：记录裁剪前后的 /Applications 目录总大小，计算释放空间量。
最终建议是谨慎操作、分批验证、保留回滚路径。语言资源裁剪的安全收益与操作风险需要平衡 —— 对于核心生产力工具，保持完整语言包是更稳妥的选择；对于使用频率低的多语言应用，裁剪风险可控。签名验证是裁剪后的必要安全关卡，任何签名异常都应视为严重问题并回滚操作。系统级优化应优先考虑 Apple 官方提供的「优化存储」功能，避免直接修改受保护的系统文件。