沙盒容器权限不足引发的崩溃通常表现为进程卡死、闪退或静默失败，关键线索在于termination reason（如namespace sandbox或0x8badf00d）、application specific information中的路径错误、控制台sandboxd deny日志、活动监视器“未响应”状态及info.plist权限声明缺失。
沙盒容器权限不足引发的崩溃，通常不会报“Permission denied”这种直白错误，而是表现为进程卡死、闪退或静默失败。日志里关键线索藏在系统拦截行为和应用自身异常终止的交叉点上，需结合控制台、活动监视器与路径上下文综合判断。
看崩溃日志里的 Termination Reason 和 Application Specific Information
打开控制台 → 崩溃报告 → 找到对应 .crash 文件，重点往下扫这两处：
-
Termination Reason 出现
Namespace SANDBOX或Code 0x8badf00d（Watchdog 超时），大概率是沙盒内操作被阻塞后主线程卡住，最终被系统强制终止 -
Application Specific Information 若含类似
Failed to open file at /Users/xxx/Library/Caches/MyApp/config.plist或Could not write to URL: file:///Users/xxx/Documents/Export/，说明应用试图访问沙盒外路径且未获授权 - 注意堆栈中是否反复出现
NSFileManager、URL.startAccessingSecurityScopedResource失败，或调用NSOpenPanel后没正确配对stopAccessing
查控制台系统日志里的 sandboxd deny 记录
崩溃日志只记录结果，真正拦截动作发生在系统层。在控制台左侧选「系统日志」，搜索栏输入：
-
sandboxd deny—— 最直接证据，会显示被拒绝的进程、目标路径、权限类型（如file-read-data） -
lsd deny—— Launch Services 拒绝打开文档或 URL Scheme，常见于双击文件启动失败 - 你的 App Bundle ID（如
com.example.myapp）+EACCES或EPERM—— 补充确认权限上下文
典型日志行：default 15:32:17.890123 sandboxd[123]: ([456]) MyApp(789) deny(1) file-read-data /Users/xxx/Desktop/report.pdf
用活动监视器交叉验证“假死型”崩溃
有些沙盒权限问题不导致立即崩溃，而是让应用卡在 I/O 等待中，表现为“未响应”但 CPU 几乎为 0：
- 打开活动监视器 → 查看 → 所有进程 → 找到状态为“未响应”的目标进程
- 点击 ℹ️ 图标 → “打开的文件和端口”，搜索
Permission denied或路径关键词（如Documents、Desktop） - 观察“磁盘读取/写入”是否长期为 0 B，同时“能量影响”偏高 —— 这种“空转”状态很可能是反复尝试访问受限路径失败后陷入等待
确认 Info.plist 权限声明与实际使用是否匹配
沙盒权限不是系统自动赋予的，必须显式声明并由用户授出。检查你的应用是否漏配关键键：
-
com.apple.security.files.user-selected.read-write—— 必须设为true，否则即使用户通过 NSOpenPanel 选了文件夹，后续也无法持久读写 -
com.apple.security.assets.photos、com.apple.security.network.client等 —— 若用到对应功能却没声明，也会触发 sandboxd 拦截 - Xcode 中 Capabilities 开启对应选项后，务必手动打开 Info.plist 核对生成的键值是否完整，尤其注意拼写和布尔值格式（
<true></true>不是YES）
