大厂男孩的粉丝遇到这个提示的人，十有八九是在双击一个 .pkg 安装包的时候。macOS 安装软件报错“必须跳过某些项目”，本质上就是系统权限不足在捣鬼。进度条走到一半，画面弹出这句提示，接着按钮变灰，安装直接结束。我第一次碰到是在一台 Intel 芯片的 MacBook Pro 上装音频插件，当时第一反应是安装包坏了，重新下载两遍还是一样，最后才意识到问题出在权限上。
处理这类安装软件报错，说难不难，说简单也不简单。它背后牵扯到 POSIX 权限位、ACL、SIP、TCC 好几层机制。网上搜答案，最常见的建议就是 chmod -R 777，但这个命令恰恰是最容易把系统搞坏的操作。这篇文章我会从报错的真实含义讲起，把权限不足的底层原因拆开，再给出一套从轻到重的修复方案，最后专门说说 chmod 的风险边界。适合谁看？被 pkg 安装器劝退的新手，以及想彻底搞懂 macOS 权限机制、不想再靠瞎蒙解决问题的老用户。
提示：不同的 macOS 版本、芯片平台，权限机制细节会有差异。本文以 macOS 12 Monterey 到 macOS 14 Sonoma 之间的主流行为为主，Intel 和 Apple Silicon 通用。
1. “必须跳过某些项目”到底是什么在跳
1.1 这个报错的真实场景
严格来说，“必须跳过某些项目”是一个失败兜底提示，不是某一个固定窗口的专属文案。英文安装器里常见的是 The Installer requires you to skip certain items 或者 Installation cannot continue，中文版被本地化成“必须跳过某些项目”。无论文案怎么变，它传递的信息都只有一个：安装器在尝试往某个位置写入时，被系统拒绝了。
我实际遇到过三类典型场景：
- 双击下载的 .pkg 安装包，进度条走到大约三分之一处，弹出提示，点“好”之后安装器退出；
- 安装时输入管理员密码，安装完却发现某个功能不可用，回看日志才发现对应组件被悄悄跳过；
- 把 .app 拖进“应用程序”文件夹，提示“不能完成操作，因为您没有权限查看某些文件”，或者干脆没有任何反应。
如果你的情况是这三种之一，那基本可以确定是权限问题。当然，还有一个容易被忽略的场景：安装包本身要求安装系统扩展（比如网卡驱动、虚拟音频驱动），而当前系统的安全策略不允许加载，这时安装器也会以“跳过”方式处理。
1.2 安装器的“跳过”机制是怎么回事
macOS 的安装器本质上是一个解包、拷贝、注册的过程。一个 .pkg 文件里通常包含多个组件，每个组件都指定了目标路径和安装条件。安装器在准备阶段会逐个检查这些条件：目标磁盘格式是否兼容、目标目录是否存在、当前用户是否有写权限、系统版本是否满足要求。
重点在于：macOS 的安装器碰到其中一个组件不满足条件时，并不会总是终止整个安装，而是会把那个组件标记为“跳过”，然后继续装剩下的。这个设计本意是让部分软件在条件不全的情况下也能装上一部分，避免用户因为一个小问题就完全无法使用。但副作用就是，权限不足时你看到的不是“Permission denied”，而是莫名其妙的“必须跳过某些项目”。
比如一个驱动包同时包含“应用程序”和“系统扩展”两个组件。系统扩展需要写入受保护的系统卷，当前策略不允许，安装器就跳过这个组件，只安装应用程序。表面上看安装过程跑完了，实际上核心功能没装上。
这也是为什么很多人发现：安装完软件能启动，但功能缺失，或者反复提示需要安装驱动。问题不在软件本身，而在最开始那个被跳过的组件上。
1.3 被跳过的组件去了哪里
被跳过的组件不会写入目标位置，但安装器的处理过程会详细记录在系统日志里。排查时可以这样看：
bash复制sudo log show --predicate 'process == "installerd" or process == "Installer"' --last 30m --info
日志里会看到类似 skipping ... due to ... 的字段，后面会跟具体原因。我见过最多的是这三类：
| 日志关键字 | 真实原因 |
|---|---|
| permission denied | 目标目录权限或属主异常 |
| volume not writable | 磁盘格式不支持或卷只读 |
| unsupported architecture | 安装包和当前芯片架构不匹配 |
如果你连日志都懒得查，也可以直接按照第三章的方法，对重点目录做权限修复，很多时候能直接绕过日志排查这一步。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 权限不足的底层逻辑：POSIX 权限、ACL 和 macOS 的三道闸门
2.1 先看懂 rwx：POSIX 权限位
macOS 的权限模型继承自 Unix，也就是 POSIX 权限。每个文件或目录都有三组权限位：属主、群组、其他人。每组又有三个动作：读（r）、写（w）、执行（x）。目录的执行位表示能否进入和遍历，写位表示能否在目录里创建或删除文件。
常用权限值对照：
| 权限值 | 含义 | 典型用途 |
|---|---|---|
| 644 | 属主可读写，其他人只读 | 普通数据文件 |
| 755 | 属主可读写执行，其他人可读执行 | 可执行程序、目录 |
| 700 | 仅属主可读写执行 | SSH 私钥、私人目录 |
| 775 | 属主和群组可读写执行，其他人只读执行 | 多人协作目录 |
| 777 | 所有人可读写执行 | 临时共享目录，慎用 |
| 1777 | 在 777 基础上加 sticky bit | /tmp 等共享可写目录 |
目录的权限特别重要。在 Unix 世界里，创建一个文件、删除一个文件，看的是所在目录的写权限，而不是文件本身的权限。所以当安装器往某个目录写文件失败时，问题往往出在目录权限，而不是文件权限上。
比如“应用程序”目录的正常权限应该是 775，属主 root，群组 admin。如果你之前对系统做过整盘权限清理，或者用某些清理工具误操作过，把“应用程序”变成了 755 甚至更严格的只读，那么普通用户就永远无法往里拖拽 App。
2.2 macOS 独有的三道闸门
POSIX 权限只是第一层。macOS 在它之上还叠加了三个安全机制，很多 chmod 修复无效，就是因为没有绕过这三道闸门。
第一道是 Gatekeeper。它管的是“这个 App 能不能被打开”。从互联网下载的 App 会被打上 quarantine 属性，未经签名或被拦截时，系统会阻止打开，提示“无法验证开发者”或“已损坏”。这个问题和权限无关，但经常被误当成权限问题。解法是右键打开，或者在终端执行 xattr 清除隔离属性。
第二道是 SIP，系统完整性保护。在 macOS 10.11 之后，/System、/usr（部分路径）、/bin、/sbin 等目录默认只读，即使是 root 用户也不能修改，除非关闭 SIP。如果你试图直接在系统卷目录上 chmod、chown、删除文件，系统会直接拒绝，甚至报 operation not permitted。
第三道是 TCC，隐私权限。App 要访问“桌面”“文稿”“下载”文件夹、摄像头、麦克风、通讯录、日历这些数据时，需要在“系统设置-隐私与安全性”里授权。TCC 出问题时，App 能启动但访问不了文件，表现也很像权限不足。
这三道闸门之间的关系，可以类比为一栋楼的安全体系：POSIX 权限是房间门锁，TCC 是楼层门禁，SIP 是小区保安，Gatekeeper 是前台访客登记。你用 chmod 换了门锁，但保安不放行，依然是进不去。
2.3 为什么以前 chmod 好使，现在不好使了
很多老教程会告诉你“遇到权限问题就 chmod -R 777”，在十年前的 macOS 上确实管用，因为那时候系统卷可写、SIP 还没引入、TCC 也没有现在这么严格。但从 macOS 10.15 Catalina 开始，系统卷被单独挂载为只读，很多目录连 root 都改不了，这直接让一批旧教程失效。
Apple Silicon 机型上，这个趋势更明显。系统启动时的安全策略默认是“完整安全性”，内核扩展（kext）默认不让加载，某些系统文件连重启过程中都很难替换。这就是为什么现在很多人照着网上的命令敲半天，还是装不上软件——因为你修改的路径，可能根本在 SIP 保护范围内。
所以在动手之前，先判断一下：你遇到的权限问题，是在写用户目录、应用目录，还是系统受保护目录？前两者 chmod 还有用，后者就得考虑安全策略层面的调整。
3. chmod 修复实操：按报错场景匹配命令
3.1 第一步：先诊断，别急着敲命令
拿到权限问题，先花两分钟看清现状。在终端里执行：
bash复制ls -le@O /Applications
这条命令会列出“应用程序”目录的权限位、属主、ACL 条目和扩展属性。正常输出里，目录权限应该是 drwxrwxr-x，属主是 root，群组是 admin。如果出现类似 drwxr-xr-x（775 变成了 755）或者属主是你自己的用户名，那就说明有人改过根目录权限。
还可以单独看某个目标目录：
bash复制stat -f "%Sp %Su %Sg" /usr/local
记住，权限修复的黄金法则是“哪里坏了修哪里”。不要一上来就对整个磁盘或者整个用户目录递归授权，那是把手术做成了大扫除。
3.2 场景 A：拖拽 App 到“应用程序”提示权限不足
这是最常见的权限问题之一，症状是把 App 图标拖进“应用程序”文件夹时被弹回，或者显示“不能完成此操作”。
先执行：
bash复制sudo chown -R root:admin /Applications
sudo chmod 775 /Applications
第一句把“应用程序”目录的属主改回 root、群组改为 admin。macOS 上这个目录的标准配置是 root:admin，意思是用 admin 群组的成员都能往里写入。第二句把目录权限恢复为 775，也就是群组内用户可以写入。
这里有个细节：很多教程只写 chmod 775，不写 chown，导致一直修不好。因为如果目录属主是普通用户或者混乱的 uid，即使权限位正确，其他进程也可能因为没有对应 ACL 而无法写入。两个命令配合才能彻底解决。
如果目录里已经有一些 App 权限异常，可以继续执行：
bash复制sudo chown -R root:admin /Applications/*.app
不建议对整个 /Applications 做递归 chown，因为里面可能有部分 App 需要特殊权限，递归改完反而会出一些奇怪问题。建议先修目录本身，再修报错的单个 App。
3.3 场景 B：pkg 安装器提示“必须跳过某些项目”
遇到这类报错，优先怀疑安装目标涉及 /Library 或 /usr/local 这两个目录。先说 /usr/local，Intel 芯片 Mac 上很多命令行工具和部分软件都装在这里，如果目录属主是 root，普通用户安装时就没有写权限。
Homebrew 是重灾区。如果你用 chmod -R 777 处理过 /usr/local，之后 Homebrew 就会一直报 “Unsafe permissions” 警告。修正方式是：
bash复制sudo chown -R $(whoami):admin /usr/local
sudo chmod -R u+rwX /usr/local
注意这里用的是 u+rwX，大写的 X 表示“只有对目录或者已经有执行权限的文件才加执行位”。相比 777，它只给属主加写权限，不改变其他人的权限，风险小很多。
Apple Silicon 芯片的 Mac 上，Homebrew 默认装在 /opt/homebrew，同理：
bash复制sudo chown -R $(whoami):admin /opt/homebrew
sudo chmod -R u+rwX /opt/homebrew
涉及到 /Library 的组件（比如打印机驱动、输入法、杀毒软件），可以尝试：
bash复制sudo chown -R root:wheel "/Library/Application Support"
不过我不建议盲目对这个目录递归。更稳妥的办法是先看日志里到底具体哪个路径被跳过了，再用 stat 检查那一条路径。如果日志来不及看，就先确认当前登录用户有管理员权限：
bash复制sudo dscl . -read /Groups/admin GroupMembership
3.4 场景 C：外部磁盘、U 盘上安装出错
很多人喜欢把软件装在外置硬盘上，尤其是大型设计软件。如果外置盘是 exFAT 或 FAT32 格式，就会出现一个尴尬局面：这些文件系统没有完整的 POSIX 权限支持，而安装器往里面写文件时依然会做权限检查，结果就是各种安装失败或功能异常。
遇到这种情况，修复权限没有意义。正确的做法是先把外置盘格式化为 APFS 或 macOS 扩展（日志式），再重新安装。确认一下：
bash复制diskutil info /Volumes/你的盘名 | grep "File System"
如果显示的不是 APFS 或 HFS+，建议备份数据后重新格式化。如果只是为了拷文件，那没问题；但如果要安装软件、插件、驱动程序，文件系统必须原生支持 macOS 的权限模型。
3.5 场景 D：双击某个小工具提示 “Permission denied”
这个最简单，通常是文件没有执行权限。比如从 GitHub 下载的二进制工具，默认权限可能是 644，直接执行就会报 permission denied。
解决办法：
bash复制chmod +x /path/to/工具
或者直接指定 755：
bash复制chmod 755 /path/to/工具
注意区分：如果文件本身不可执行，chmod +x 有效；如果运行时报的是“无权限写入某个目录”，那就得检查目录权限。很多人习惯一刀切 777，其实 755 就已经覆盖了绝大多数场景。
3.6 chmod 1777 和 777 到底是什么关系
热搜里经常有人问 chmod 1777 是什么意思。简单说，1777 在 777 的基础上多了一个 sticky bit，也就是粘滞位。它的作用是：在这个目录下，只有文件属主和 root 才能删除或重命名文件。
macOS 的 /private/tmp 和 /private/var/tmp 就是 1777。所有用户都可以往临时目录里写文件，但谁也不能删除别人的临时文件。这是多用户系统为了避免互相破坏而设计的。
如果你在某个共享目录上不小心用了纯 777 而没有 sticky bit，任何本地用户都能删除别人的文件。对于单人使用的 Mac，危害面稍小，但如果是公司配发、多人共用的电脑，这就是个大坑。所以共享目录要么用 1777，要么用带群组权限的 775，而不是裸的 777。
4. chmod 777 的代价：那些年我见过的权限事故
4.1 777 到底放开了什么
把某个文件或者目录改成 777，相当于告诉系统：这台电脑上的任何一个本地用户，都可以读取、修改、执行这个对象。注意，不只是登录的用户，还包括以其他身份运行的进程，比如浏览器插件、自动更新程序、甚至是恶意软件。
对一个普通文件来说，777 意味着别人可以改内容；对一个可执行文件来说，777 意味着别人可以替换掉这个程序；对一个目录来说，777 意味着别人可以往里面放文件，也可以删掉里面的任何文件，而这个目录可能正好藏着你的 SSH 密钥、钱包文件、私密文档。
这就是为什么安全人员普遍把 777 视为一个危险信号。它也许偶尔能解决眼前的问题，但代价是把后续所有访问它的进程都默认为可信，这是把安全模型直接掏空。
4.2 递归 777 的三次真实事故
第一次事故：有用户尝试对用户主目录执行了 sudo chmod -R 777 ~，想着“把所有权限都给足，应该就能修复了吧”。结果钥匙串（Keychain）里的条目权限全部变成 666，登录项错乱，系统反复要求重新输入密码，部分证书直接失效。折腾了两个小时，最后还是从 Time Machine 恢复才解决。
第二次事故：为了让某个软件运行，对 /System 目录执行了 sudo chmod -R 777 /System。之后系统开始疯狂报错，部分系统服务无法启动，重启后直接进入不了桌面环境。原因很简单：SIP 保护目录之外，很多系统组件的依赖文件被改了属主，服务的沙盒环境全部失效。
第三次事故：对 /usr/local 目录执行 chmod -R 777。Homebrew 立刻进入“权限不安全”状态，brew upgrade 动不动就报错；更麻烦的是 /usr/local/bin 下的二进制可能被任意进程覆盖，等于所有命令行工具都暴露在风险里。
这三个案例的共同点是：用递归 777 这种粗暴方式，解决一个本来只需要单目录、单文件操作的权限问题。权限修复一定要精准，范围越小越好。
4.3 为什么 macOS 对权限异常更不宽容
有些平台可能对权限错误睁一只眼闭一只眼，但 macOS 在这方面比较敏感。几个常见的连锁反应：
- SSH 直接拒绝使用权限过宽的私钥文件，提示
Permissions too open； - TCC 数据库对系统目录的权限有严格校验，改动后隐私授权行为异常；
- 系统服务以低权限运行，拿到 777 目录后可能触发沙盒警告；
- 如果文件属主被改成 root 或 uid 0，普通应用可能无法读取，反过来又造成新的权限不足。
所以，macOS 上权限问题并不是越宽松越好。适得其反是常事，尤其当这个目录同时被多个系统服务依赖时，一次暴力授权引发的问题可能比原来的报错更难排查。
4.4 什么情况下才能真正使用 777
我不是说 777 绝对不能碰。在下面这些场景里，它是合理的：
- 一次性使用的临时 U 盘或虚拟机共享文件夹；
- 完全隔离的调试环境，不会有其他用户或重要数据；
- 自己创建的、确认只为单一设备服务的目录。
即使在这些场景，我也建议优先用 1777 或者 775，因为你永远不知道未来会往这个目录放什么。安全边界这种东西，收一收容易，放开后再想收回来，成本就高了。
5. 不依赖 chmod 的替代方案：从急救到 SIP 的完整路径
5.1 磁盘工具“急救”的作用
如果你想先试试系统自带的修复能力，打开“应用程序-实用工具-磁盘工具”，选择系统盘，点击“急救-运行”。这个操作会检查卷结构、修复部分目录权限错误和文件系统元数据问题。
需要明确：磁盘急救修复的是卷层面的异常，比如 ACL 标志位错乱、目录树不一致，但不会针对某个 App 的权限做定制修复，也无法修复用户手动改坏的文件属主。它更像是对整个磁盘做一次体检，适合作为权限问题排查的前置步骤，而不是全部答案。
5.2 安装器“自定”选项：绕开高权限目录
很多 pkg 安装器在第一步会提示“自定”按钮，点进去可以看到所有组件列表。如果你只是想在用户层面使用软件，可以把需要写入系统目录的组件取消勾选，只保留应用程序部分。
还有一种思路是把软件装到用户目录。具体来说，把 .app 拖到 ~/Applications 下而不是 /Applications 下，同时在安装器里把安装位置改为用户目录。这样路径上的权限完全由你控制，不需要动系统目录，也不需要修改任何系统级权限。
这种方案的代价是：如果软件依赖 LaunchDaemon、系统扩展或者共享库，用户目录方式可能无法成立。但它值得先试，因为成功率比改权限高，而且零风险。
5.3 清除 Gatekeeper 隔离属性
涉及打开“已损坏”或被拦截的 App，执行：
bash复制sudo xattr -dr com.apple.quarantine /Applications/xxx.app
这是把 App 的隔离属性移除，让 Gatekeeper 不再把它当作“来自互联网的未信任文件”。注意，这个操作会绕过签名验证，仅适用于你确认安全的应用。如果是破解软件、来历不明的软件，不建议这么做。
还有一个隐藏信息：有时候打开 App 显示“已损坏，无法打开”，其实不是文件损坏，而是 quarantine 属性在作祟。先执行 xattr 再试，比重新下载靠谱。
5.4 重置 TCC 权限
如果软件能启动，但访问不了“桌面”“下载”“照片”等目录，可以重置 TCC 权限：
bash复制tccutil reset All
这会清除所有 App 的隐私授权记录，之后系统会在你再次访问敏感数据时重新弹窗询问。执行后需要重新授权那些真正需要的 App，但能解决 TCC 记录错乱带来的“权限不足”表象。
5.5 关闭 SIP 的安全边界
最后一招，也是最重的一招：关闭 SIP。操作步骤是：
- 重启 Mac，按住电源键进入“恢复”模式（Apple Silicon 机型）；
- 在菜单栏打开“终端”；
- 输入
csrutil disable并回车； - 重启进入系统，完成需要的安装操作；
- 再次重启进入恢复模式，执行
csrutil enable恢复。
风险说明：关闭 SIP 意味着系统卷保护被绕过，恶意软件有可能直接修改系统文件。这条路只建议在开发调试时临时使用，并且安装完成后必须立即恢复。Apple Silicon 机型也可以不彻底关闭 SIP，而是把“安全策略”改为“降低安全性”，允许加载未签名的系统扩展，然后再改回来。
每次看到网上有人一上来就让人关 SIP，我都觉得有点头疼。绝大多数情况根本不需要走到这一步，先试权限修复，再试 xattr，再考虑系统扩展，SIP 应该是最后的手段。
6. 我的排障顺序和几个容易忽略的细节
6.1 一套好用的排查顺序
我踩过很多坑之后，总结出一个比较高效的顺序：
- 先看安装日志，确认是权限问题还是架构问题；
- 打开“访达-应用程序”，右键“显示简介”，检查目标 App 或目标目录的共享与权限；
- 用
ls -le@O查看实际权限位和 ACL，记录异常项； - 针对目标目录做最小范围的权限修复，改完立刻重试安装；
- 不行就换用户目录安装，或者“自定”去掉多余组件；