刚收到一台新的 MacBook Pro，装好开发环境，准备跑一个从 GitHub 上下载的内部工具。双击之后看到的不是界面，而是一行弹窗：“无法打开，因为 Apple 无法检查其是否包含恶意软件”。
再试另一个工具，更直接：“已损坏，无法打开，你应该将它移到废纸篓”。
我相信每个 macOS 开发者都遇到过类似场景。这时候搜索引擎里出现频率最高的问题就是：Gatekeeper 和 XProtect 能关掉吗？能不能一劳永逸地让 Mac 不再拦我？
我给一个明确的判断：技术上可以短时间放宽，但绝大多数人不应该永久关闭，更不应该把它们一起干掉。你需要的不是“关闭系统防护”，而是“精准放行受信任的软件”。本文会先讲清楚这两个机制到底是什么、在哪里拦截了你，再给出一套从稳妥到激进的处置方法，最后说明哪些做法是真坑，千万别踩。
读完你会明白：以后再收到“已损坏”提示，你可以 30 秒内判断出原因，并且知道用什么方式解决最安全。
1. Gatekeeper 和 XProtect 到底是干什么的
很多人把 Gatekeeper 和 XProtect 混为一谈，以为它们都是“拦截未知应用的防火墙”，其实两者差异很大。
Gatekeeper 是闸机，XProtect 是巡逻警。
Gatekeeper 负责的应用打开前的“入门检查”。当你从浏览器下载一个应用，macOS 会给这个文件打上一个隔离标记（quarantine attribute）。双击打开时，Gatekeeper 会检查这个应用有没有合法的开发者签名，是否经过了 Apple 的公证（Notarization），再决定是否放行。它的核心问题是：这个应用是谁写的？有没有被篡改？
XProtect 则是异步运行的恶意软件特征检查。它维护一套恶意软件特征库，在后台扫描文件和进程，发现已知恶意行为就会阻止运行或要求删除。它的核心问题是：这个文件本身是不是恶意软件？XProtect 不关心签名的合法性，它关心的是行为特征和已知病毒库。
这里有一个关键时间线：Gatekeeper 的检查发生在你双击打开应用的那一刻，是同步的、用户可感知的；XProtect 的扫描发生在后台，是你通常感觉不到的。所以当你看到一个弹窗挡住应用启动，那是 Gatekeeper 在说话，不是 XProtect。
那 XProtect 还有存在感吗？有。它负责拦截那些已经绕过 Gatekeeper 的恶意软件，比如你通过右键打开、或者从网盘同步下来的文件，一旦特征库命中，它会在后台直接阻止运行。它还有能力在系统更新时自动更新特征库，不需要用户干预。
明白这个区别之后，你再看网上的两派观点——有人喊“关闭 Gatekeeper 一劳永逸”，有人喊“千万别动，动了就中病毒”——其实都不准确。Gatekeeper 是可以配置的，而且 Apple 提供了正规的配置通道。XProtect 没有官方开关，硬要关掉属于“拆了自己的消防警报器”，收益接近于零，风险却不小。
2. Gatekeeper 的判定流程：为什么你的应用被拦了
既然 Gatekeeper 是闸机，那么理解它的判定流程，就知道应该在哪一步做文章。
流程大致如下：
- 用户双击应用。
- 系统检查文件是否带
com.apple.quarantine扩展属性。如果是从 App Store 下载或由系统组件生成的，可能没有这个属性，直接放行。 - 如果带隔离属性，Gatekeeper 检查代码签名。
- 检查应用是否通过 Apple 的公证服务。
- 根据检查结果放行或弹窗。
所以同一个应用，从 App Store 下载能开，从浏览器下载就弹窗，差别就在第 2 步。从浏览器下载的这个文件被标记为“外来文件”，需要额外验证。
这里有一个常见误区：“已损坏，无法打开”不代表文件真的损坏了。它往往意味着 Gatekeeper 验证签名失败，或者应用没有公证记录。尤其是国内很多内部工具、开源软件，开发者没有购买 Apple Developer 账号，也没有做公证，自然会被 Gatekeeper 拦下。
另一个容易被忽略的点：Gatekeeper 的拦截只针对“带隔离属性的文件”。如果你通过右键菜单选择“打开”，系统会弹出一个略显不同的确认框，这时你可以选择“仍然打开”——这是 Apple 留下的一个官方后门。但如果应用连签名都没有，右键打开也会被拦回来。
再往下，就是spctl命令和系统设置里的“任何来源”选项。在较老的 macOS 版本中，用户可以在“系统偏好设置 → 安全性与隐私”里选择“任何来源”来完全关闭 Gatekeeper。但 Apple 在后续版本里逐步收紧了入口：新版本的 macOS 系统设置里已经没有“任何来源”选项，只能通过终端命令来修改评估策略，而且这个命令在部分新版本中也已经失效。这说明 Apple 的产品方向非常明确：默认安全优先，把“完全关闭”的通道越收越窄。
3. 为什么有人想关闭 Gatekeeper 和 XProtect
要判断“该不该关”，先看看大家为什么想关。在我接触到的开发者场景里，主要有这么几类：
第一类：公司内部工具没有签名。很多企业用脚本打包内部命令行工具、GUI 工具，没有买 Developer ID 证书，也没有走公证流程。这些工具在自己电脑上编译出来没问题，但分发到同事电脑上就是“不明来源应用”，被 Gatekeeper 拦截。
第二类：老项目、老安装包在装新系统时失效。某些老旧软件在 Intel Mac 时代还能运行，到了 Apple Silicon + 新系统上，签名和公证信息不匹配，系统直接拒绝启动。开发者急着用，只能想各种绕过办法。
第三类：浏览器下载文件被 XProtect 误报。特征库匹配有概率误伤正常工具。特别是小众的开源工具、外挂插件、跨平台打包产物，容易被判定为可疑文件。
第四类：批量化装机时的效率问题。运维同学在一台新 Mac 上要装几十个工具，每个都右键打开、输入密码、再确认，效率极低。于是干脆先关掉 Gatekeeper，装完再恢复。
这四类需求都是真实的。但它们的共同点在于：问题是“如何信任一个特定应用”，而不是“如何不信任所有应用”。关闭全局防护是用一个最粗暴的手段去解决一个局部问题，副作用很大。
真正合理的做法，是分场景、分工具、分环境地做精准放行。接下来的章节，我会给出从安全到激进逐级递增的方案。
4. 什么情况下可以关，什么情况下绝对不要关
先给结论：个人开发机、纯测试环境、不存重要数据和账号凭证的机器，可以在可回滚的前提下临时放宽 Gatekeeper；涉及公司资产、生产系统、财务人事权限、个人主力机的机器，不要关。
为什么这么分？因为 Gatekeeper 和 XProtect 是你的第一道和第二道防线。关闭 Gatekeeper 并不会让 Mac 更容易中毒，但它确实会降低从浏览器下载未知文件的拦截能力。如果你平时习惯只从官网和 GitHub 下载开源工具，风险相对可控；如果你经常下载各种破解版、注册机、游戏插件，那关闭 Gatekeeper 等于敞开大门。
再单说 XProtect。XProtect 没有官方关闭开关。网上有一些通过修改系统文件、加载启动参数来禁用的方法，但它们都涉及绕过系统完整性保护（SIP）或者使用开发者模式，风险极高，而且对普通开发者来说几乎没有必要。XProtect 是一个后台扫描器，平时几乎感知不到它的存在，除非误报或误杀。你为一个感知不到的东西去冒安全风险，这笔账不划算。
在企业的受管设备上，我的态度更明确：不建议在受管 Mac 上关闭 Gatekeeper。MDM 管理员可以通过配置描述文件批量设置安全策略，而不需要牺牲整机防护。如果你在的是有一定规模的公司，建议先找 IT 或运维确认团队是否已经通过 MDM 下发了安全基线配置，避免个人操作和公司策略冲突。
5. 如何绕过 Gatekeeper：从稳妥到激进的方案
当你确定确实需要绕过 Gatekeeper，可以按下面的顺序选择方案。顺序的设计原则是：影响范围从小到大，能解决单点问题就不要用全局方案。
5.1 右键打开：官方留的快捷通道
最简单的方法是右键点击应用，选择“打开”。系统会再次弹窗，但这次会多一个“打开”按钮，而不是仅“移到废纸篓”。
这个操作的本质是：macOS 只对本次启动做例外放行，不会修改全局策略。对于偶尔下载的未签名工具，这个方式最安全。
# 假设应用在 Applications 目录下 open -a "/Applications/Example.app"右键打开依然是首选。这个方法不需要任何终端命令，但只适用于带完整签名、只是未通过公证的应用。如果应用完全没有签名，右键打开也会被拦下。
5.2 移除单个应用的隔离属性
如果想跳过 Gatekeeper 对某个应用的检查，可以移除它的隔离属性：
xattr -dr com.apple.quarantine "/Applications/Example.app"然后直接双击打开，系统不会重复拦截。
这里做的是“只针对这一个应用放行”，不会影响其他应用，是对全局策略影响最小的方案。
在这个方案里，真正容易犯的错是路径写错。建议先用cd进入应用所在目录，用pwd确认路径，再执行命令。如果应用从磁盘映像里挂载运行，你需要先拷贝到“应用程序”目录再执行。
5.3 修改 Gatekeeper 评估策略（spctl 命令）
如果是一个开发团队，内部有大量未签名工具，逐个移除隔离属性太不方便，可以临时修改评估策略。
在旧版 macOS 上，可以这样启用“任何来源”：
sudo spctl --master-disable执行后，你可以在“系统设置 → 隐私与安全性”里看到“任何来源”选项。恢复默认：
sudo spctl --master-enable查看当前状态：
spctl --status当输出为assessments enabled时，说明 Gatekeeper 正在工作；当输出为assessments disabled时，说明已被关闭。
需要特别提醒的是：Apple 在较新系统版本中已经收紧了--master-disable命令的可用性。在某些新版本中，该命令不会产生任何效果，或者在重启后失效。这并不奇怪，Apple 的产品方向就是逐步取消全局关闭选项。如果你的系统已不适用此命令，不要纠结于寻找老方法，而应回到 5.1 和 5.2 的局部方案，或者进入第 6 节的签名方案。
5.4 使用 codesign 对内部工具签名
对开发者而言，最正规的做法不是绕过 Gatekeeper，而是让自己的应用满足 Gatekeeper 的检查要求。
如果公司购买了 Apple Developer 账号，可以给内部工具做 Developer ID 签名，再走一次公证（notarization）。签名之后，工具在分发时就不会被系统当作“不明来源应用”拦截。
如果没有开发者账号，也可以用自签名证书在本地做 Ad-Hoc 签名：
codesign --force --deep --sign - "/Applications/Example.app"签名后，应用有了一个本地签名，Gatekeeper 的检查行为会有变化。需要注意，这个签名只在本机有效，分发到其他机器仍然会被拦截。它解决的是“本机编译的应用，双击打不开”的问题，不解决分发问题。
检查签名信息：
codesign -dv --verbose=4 "/Applications/Example.app"输出里能看到Signature=adhoc或Signature=Developer ID Application，分别对应本地自签名和正式开发者签名。
5.5 企业分发场景：使用 MDM 或私有分发渠道
如果团队规模较大，需要给几十台上百台 Mac 统一安装内部工具，最规范的方式是交给 MDM 做分发。
macOS 比较新的版本里，Apple 提供了更友好的配置描述文件接口，可以在设备上预设安全策略、安装配置、应用白名单。管理员在 MDM 后台可以批量设置：
- 允许来源的 Developer ID 团队 ID
- 允许运行的应用路径
- 自定义配置描述文件
这样做的效果是：设备层面仍然开启 Gatekeeper 和 XProtect，但内部工具被显式加白，普通用户不再收到拦截弹窗。这是比“关全局防护”更高级、更安全的方案。
如果你的公司还没有 MDM，至少可以走一条中间路线：在镜像或装机脚本里，用 5.2 的方式预先移除内部工具包的隔离属性，再把安装流程标准化。
6. XProtect 能被关闭吗
直接回答：XProtect 没有官方关闭方式，也不建议关闭。
XProtect 不是一个独立的应用程序，它内嵌在 macOS 系统中，通过系统级服务和守护进程运行。用户能感知到的，只是“文件被系统隔离”或“下载文件被移除”之类的现象。它不是像 Gatekeeper 那样由用户偏好设置控制的组件，而是操作系统底层的安全组件。
网上有一些通过修改XProtect相关配置、加载旧版本特征库、或者利用 SIP 关闭手段来“禁用 XProtect”的教程。这些方案的问题在于：
- 需要关闭 SIP 或修改系统卷，导致整个系统完整性保护失效，影响面远超 XProtect 本身。
- 系统更新后很可能被还原。
- 收益极低。XProtect 平时不打扰你，体积小、更新静默，除非特征库误报严重，否则你根本感觉不到它的存在。
如果你遇到 XProtect 误报的情况，比如下载的某个工具被系统提示有恶意软件、文件被自动移除，更合理的做法是：
- 确认来源可信：是否从开发者官网发布？
- 查看文件哈希，与开发者发布的校验值对比。
- 通过
xattr检查隔离属性和所有扩展属性。 - 向 Apple 提交误报反馈，帮助完善特征库。
- 在确认工具可信的情况下，用 5.2 的方式移除隔离属性再尝试。
这里要明确一点：移除隔离属性只能绕过 Gatekeeper 的 quarantine 检查，不一定能完全躲过 XProtect 的后台扫描。如果文件确实被 XProtect 命中，系统可能会直接阻止访问或删除文件，这时候再去修改系统安全组件是得不偿失的。
查看 XProtect 的当前状态，可以查看它的版本信息：
system_profiler SPInstallHistoryDataType 2>/dev/null | grep -A 5 -i xprotect或者：
ls -la /Library/Apple/System/Library/CoreServices/XProtect.bundle输出会显示 XProtect 特征库的版本和时间信息。正常情况它应该随系统更新自动更新。
7. 常见问题与排查思路
以下是 macOS 应用安全拦截场景中最常碰到的问题和解决思路：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 打开应用提示“Apple 无法检查其是否包含恶意软件” | 应用未公证，Gatekeeper 无法获取公证状态 | 查看是否带 quarantine 属性 | 右键打开，或移除隔离属性 |
| 提示“已损坏，无法打开” | 签名验证失败或签名缺失，或架构不兼容 | 用 file 命令查看架构，用 codesign 查看签名 | 移除隔离属性，或重签名，或下载对应架构版本 |
| 右键打开仍提示“应用已损坏” | 应用没有任何签名，Gatekeeper 直接拒绝 | codesign -dv 查看签名信息 | xattr 移除隔离属性后测试 |
| spctl --master-disable 无效 | 新系统已移除该命令 | spctl --status 查看状态 | 改用移除隔离属性或签名方案 |
| 下载文件被系统自动删除 | XProtect 特征库命中 | 查看安全日志或下载记录 | 确认来源，提交误报，临时关闭隔离属性后重新尝试 |
| 从网盘下载的安装包双击无反应 | quarantine 属性触发 Gatekeeper 拦截，或网盘处理了文件格式 | 打开日志查看拦截记录 | 右键打开，或拷贝后移除隔离属性 |
这里给一个快速排查命令组合：
# 查看文件的隔离属性 xattr -l "/Applications/Example.app" # 查看签名 codesign -dv --verbose=4 "/Applications/Example.app" # 查看架构 file "/Applications/Example.app/Contents/MacOS/Example" # 查看 Gatekeeper 状态 spctl --status如果xattr -l输出里有com.apple.quarantine，那基本就是 Gatekeeper 在拦截。如果codesign -dv输出报错说code object is not signed at all，说明应用完全没签名，右键打开和移除隔离属性都不一定能解决，需要考虑使用开发者账号签名。
日志排查方面，Gatekeeper 和 XProtect 相关的拦截记录一般会出现在统一日志中：
log show --last 1h --predicate 'eventMessage contains "Gatekeeper" OR eventMessage contains "XProtect"'输出可能比较长，建议用grep过滤关键词。注意，日志查询可能触发系统权限对话框，需要输入密码或授权终端访问。
8. 最佳实践：如何既安全又高效地管理 Mac 应用安全
说了这么多，最后落到工程实践上。以下建议适用于个人开发者、小团队和有合规要求的大团队，按需取用。
第一，能签名就签名，别靠关闭防护解决问题。如果你自己开发工具分发给他人，花几百块买一个 Apple Developer 账号，对内部工具做签名和公证，分发体验会好很多，而且对方不需要任何特殊操作。Apple Developer 账号的签名和公证通道是官方支持的安全通道。
第二，在个人机器上，优先使用“局部放行”。下载一个工具，右键打开；不行就移除隔离属性；再不行才考虑修改全局策略。这个顺序的好处是，操作影响面可控，出错也容易回滚。
第三，如果确实要临时关闭 Gatekeeper，记得操作后恢复。使用sudo spctl --master-enable恢复，或者去系统设置里重新勾选安全选项。很多开发者初期贪图方便关闭后忘了恢复，过了一两个月才想起来，这段空窗期下载的任何文件都没有经过 Gatekeeper 检查，风险是客观存在的。
第四，给常用受信任工具做个签名白名单沉淀。对于团队内部经常分发的命令行工具，建议写一个安装脚本，自动完成以下操作：
# 安装脚本示例：install_tool.sh APP_PATH="/Applications/InternalTool.app" # 检查是否已签名 codesign -dv "$APP_PATH" 2>/dev/null if [ $? -ne 0 ]; then # 未签名，尝试移除隔离属性并自签名 xattr -dr com.apple.quarantine "$APP_PATH" codesign --force --deep --sign - "$APP_PATH" fi open "$APP_PATH"这个脚本不关闭任何系统开关，只针对团队内部工具做自动放行，安全性可控。
第五，企业环境以 MDM 策略为准。如果公司用 Jamf、Mosyle、Intune 等 MDM 管理 Mac，安全基线通常包括 Gatekeeper 状态检查。不要为了安装一个工具而手动关闭系统防护，否则可能触发管理端的安全告警。正确的路径是向 IT 申请应用白名单，让 MDM 推送配置。
第六，保持系统更新。XProtect 特征库依赖系统更新。如果你长期不更新系统，XProtect 特征库会越来越旧，对新型恶意软件的识别率下降，这才是真正的安全漏洞。
第七，具备安全审计意识。你可以通过以下命令快速查看本机 Gatekeeper 和 XProtect 状态，在安全评估时很有用：
spctl --status sysctl -n xprotect.version 2>/dev/null || echo "xprotect not found"把这两条命令加到你的常用环境巡检脚本里，定期检查。
9. 总结与后续学习方向
回到标题的问题：Can you disable Gatekeeper and XProtect?
Gatekeeper 可以临时放宽，Apple 也提供了局部放行的官方通道，但完整关闭的功能在新系统中正在被逐步移除。XProtect 没有官方关闭方式，也不值得为了关闭它而破坏系统完整性。对绝大多数开发者来说，正确姿势是理解它们的判定流程，用最小影响范围的方式解决应用被拦截问题。
本文重点梳理了三个层次的内容：一是 Gatekeeper 和 XProtect 的机制差异与判定流程，让你遇到弹窗时能快速定位原因；二是从右键打开、移除隔离属性到修改评估策略、签名方案的完整方法链；三是基于个人开发者和企业环境的安全分级建议，帮助你在效率和风险之间做合理权衡。
下一步建议你做两件事：第一，在你自己的 Mac 上跑一遍xattr -l、codesign -dv、spctl --status三个命令，熟悉现在系统里的应用安全状态；第二，把你经常用的内部工具整理一遍，看看哪些还没有签名，评估是否需要安排自签名或 Developer ID 签名。
如果你做的是分发工具给外部用户，建议继续研究 Apple 的 notarization 公证流程，那是让应用“安全通行”的官方正道。对于企业环境，可以进一步了解 MDM 的配置描述文件策略，把“逐个放行”升级为“批量管理”。这两块内容都能让你在应用安全上走得更远。
