遇到 “Sandbox deny file-write-create” 错误？只需这一步解决！

初次使用 CocoaPods 导入三方库运行项目时，Xcode 报错 Sandbox: rsync deny file-write-create？本文将带你深入理解其原因，并给出一步到位的解决方法。

一、问题背景

在 iOS 项目中首次使用 CocoaPods 导入三方库（如 SnapKit、AFNetworking 等）后，运行项目时可能会遇到如下报错：

Sandbox: rsync.samba(7048) deny(1) file-write-create /Users/edy/Library/Developer/Xcode/DerivedData/PHVideoEditeExample-xxxx/Build/Products/Debug-iphonesimulator/PHVideoEditeExample.app/Frameworks/SnapKit.framework/SnapKit_Privacy.bundle

或者：

Sandbox: rsync(42934) deny(1) file-write-create /Users/mac/Library/Developer/Xcode/DerivedData/zhcode-xxxx/Build/Products/Debug-iphonesimulator/zhcode.app/Frameworks/AFNetworking.framework/

这些报错常常伴随着构建失败、无法正常启动的状况。对于很多初次使用 CocoaPods 的开发者而言，这无疑是个令人疑惑又恼火的问题。

二、错误成因解析

从日志中我们可以看出，系统沙盒机制（App Sandbox）阻止了 rsync 命令向 Build/Products/.../Frameworks 目录写入 .bundle 或 .framework 内容。

这其实和你是否使用了某些特定的三方库没太大关系，而是和 CocoaPods 中某些 Build Phases 自动执行的脚本有关。

🔍 根源在于：

Xcode 的某些 Target 在构建时会执行 Run Script 阶段，由于默认启用了 User Script Sandboxing，使得脚本被限制了写入权限，从而触发 deny file-write-create 错误。

三、解决方案：关闭 User Script Sandboxing

✅ 正确操作如下：

1. 选中 Xcode 中的项目（最上方蓝色 Project 节点）；
2. 选择目标 Target（你运行的那个 App）；
3. 点击 “Build Settings”；
4. 在搜索框中输入 sandbox；
5. 找到名为 User Script Sandboxing 的设置；
6. 将其从 YES 改为 NO。

就这么简单。设置完成后再次构建，错误将不再出现。

🧠 为什么这个设置有效？

因为关闭 User Script Sandboxing 意味着 Xcode 允许脚本有更大的权限执行构建逻辑，CocoaPods 的某些拷贝资源操作才得以顺利完成。这个设置对大多数日常开发是安全的，苹果官方文档中也没有强制要求保持开启状态。

四、延伸说明

1. 为什么只有“第一次”会出问题？

CocoaPods 安装的三方库在第一次构建时会被编译、打包并复制资源（如 .bundle 或 .framework）。如果沙盒限制了写入权限，就会失败。但只要成功构建过一次，之后基本就不会再触发此类问题，除非你清空 DerivedData 或重新 pod install。

2. 是否影响 App 上架？

不会。这个设置只影响本地开发环境下的构建行为，生成的 App Binary 并不会包含这些调试阶段的信息，对上架审核、真机测试都没有任何副作用。

3. 多 Target 项目如何处理？

每个 Target 的 User Script Sandboxing 设置是独立的。如果你有多个 Target（如主应用 + 扩展模块等），建议一并关闭对应 Target 下的该项设置。

4. 如果项目使用的是 Swift Package Manager 或 XCFramework，还会出现这个问题吗？

通常不会。SPM 和 XCFramework 的资源处理方式更符合 Xcode 的沙盒执行模型，不会像某些 Pod 脚本那样使用 rsync 或其他命令行工具。但如果你的脚本中涉及自定义复制行为，仍可能遇到类似权限问题。

五、小结与建议

这个报错虽小，但经常困扰初学者，尤其在首次引入三方库后令人摸不着头脑。我们建议你：

• 每次 Pod 安装或更新后，如果首次构建失败，优先检查是否是沙盒权限导致；
• 习惯性在 Build Settings 中关闭 User Script Sandboxing；
• 多 Target 的项目统一配置，减少构建过程中的不确定性。

结语

Xcode 的构建系统随着版本更新越来越智能，也越来越注重安全性和可控性。像 User Script Sandboxing 这样的机制初衷是防止恶意脚本在构建阶段造成意外破坏，但对于像 CocoaPods 这样需要在 Build Phases 中操作资源的工具来说，也可能会“误伤”。

遇到这类权限相关的问题，不必慌张，也不用一头雾水地去清空 DerivedData 或重装 Pods。理解机制、找到对应的 Build 设置项，往往只需要几秒钟的调整，就能还你一个干净、稳定的构建过程。

对于 iOS 开发者尤其是初学者而言，这是一个学习如何与 Xcode 工程配置打交道的好机会。虽然“写代码”是核心，但熟悉 IDE 的构建体系和底层机制，也是在开发中少走弯路的重要保障。

未来如果你开始尝试 Swift Package、Module 化、CI/CD 自动构建，类似的权限与配置问题可能还会出现。现在解决这一问题，也是在为更高效、更专业的开发之路打基础。