macos守护进程权限管理是分层、分角色、分来源的组合控制，核心在于运行身份、启动时机、资源访问和策略驻留。daemons以root权限运行于/library/launchdaemons/，agents以用户权限运行于~/library/launchagents/，配置文件需严格匹配归属与权限（如root:wheel+644或用户+600），启用后须经bootstrap、enable、kickstart三步验证状态，并受后台刷新、登录项、辅助功能等图形化权限独立约束。
macos 中应用进程的守护权限不是单一开关，而是分层、分角色、分来源的组合控制。关键不在于“能不能运行”，而在于“以谁的身份运行”“在什么时机启动”“能访问哪些资源”“是否被系统策略允许持续驻留”。
区分守护进程类型：Daemons 与 Agents
系统级守护进程（Daemons）存于 /Library/LaunchDaemons/，由 root 加载，拥有完整系统权限，可读写 /System、/usr、/var 等受保护路径；用户级代理（Agents）存于 ~/Library/LaunchAgents/，仅对当前账户生效，受 TCC（透明度、同意与控制）框架限制，无法绕过文件访问授权弹窗。
混淆两者会导致命令失败：比如用普通用户执行 sudo launchctl bootstrap system 是必要操作，但对 Agent 加 sudo 反而会加载到 system 域，导致服务不可见或权限异常。
配置文件权限必须严格合规
launchd 加载 plist 文件前会校验归属与权限，不满足即静默失败或报 Operation not permitted：
- 系统级 plist：所有者必须为 root:wheel，权限应为 644（
-rw-r--r--） - 用户级 plist：所有者为当前用户，权限建议 600（
-rw-------）
修复命令示例：
sudo chown root:wheel /Library/LaunchDaemons/com.example.service.plist
sudo chmod 644 /Library/LaunchDaemons/com.example.service.plist
启用 ≠ 运行：三步验证状态
执行 launchctl load 或 bootstrap 仅完成注册，不代表服务已自启或正在运行。完整验证需三步：
- bootstrap：将配置加载进 launchd 并注册 label
- enable：激活自动触发逻辑（如 RunAtLoad、KeepAlive）
- kickstart：立即启动一次，跳过等待条件
检查真实状态请用：
sudo launchctl print system/com.example.service 2>/dev/null | grep -E "(enabled|PID|LastExitStatus)"
若 enabled 为 false，说明未激活；若 PID 为空且 LastExitStatus 非 0，说明启动失败——常见原因是 ProgramArguments 中路径不存在、无执行权限，或脚本依赖的环境变量未设置。
图形界面权限与后台行为独立管控
终端管理的是 launchd 服务本身，但 macOS 应用的“后台活动”还受三类图形化权限制约，终端无法替代：
- 后台应用刷新：控制退出后是否拉取邮件、同步通知等（路径：系统设置 → 隐私与安全性 → 后台应用刷新）
- 登录项：决定是否随用户登录自动启动（路径：系统设置 → 通用 → 登录项）
- 辅助功能 / 自动化：授权跨应用操作能力（如键盘宏、AI Agent），一旦开启可在后台持续监听（路径：系统设置 → 隐私与安全性 → 辅助功能 / 自动化）
例如，一个 App 即使被 launchctl 卸载，只要它在“辅助功能”中被勾选，仍可能通过 Accessibility API 在后台唤醒并操控其他程序。
