macOS内核扩展管理核心是用户批准、签名验证与SIP保护三重机制；用户须在“系统设置>隐私与安全性>安全性”中手动点击“允许”，终端无法跳过此步，未批准则kextload静默失败。
macOS 对内核扩展（Kext）的管理核心是“用户批准 + 签名验证 + SIP 保护”三重机制，不是装上就能用，也不是点一下就一劳永逸。关键在于理解每一步的作用和失败时的真实原因。
用户批准不是可选步骤，而是强制交互环节
从 macOS High Sierra 开始，所有第三方 Kext 必须由用户在「系统设置 > 隐私与安全性 > 安全性」中手动点击「允许」。终端无法跳过这步，任何 sudo kextload 命令在未批准前都会静默失败——不报错、不提示、也不加载。
- 批准记录存在本地数据库：
sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT * FROM kext_policy WHERE allowed = 1;" - 若查不到对应 bundle_id 或 team_id，说明根本没被允许过
- Ventura 起支持“长期信任”，Monterey 是单次有效，升级后常需重新批准
签名有效性决定“允许”按钮是否出现
即使你打开隐私设置，也未必能看到「允许」按钮——因为系统先检查签名。签名无效、过期、或 Team ID 不匹配，界面直接隐藏该选项。
- 验证签名是否通过 Gatekeeper：
spctl --assess --type execute /Library/Extensions/YourDriver.kext（返回 accepted 才行） - 查看签名详情：
codesign -dv --verbose=4 /Library/Extensions/YourDriver.kext，确认含有效 TeamIdentifier 和公证时间 - 仅验证不加载：
sudo kextutil -t /Library/Extensions/YourDriver.kext，无 error/warning 才算合格
SIP 状态直接影响加载结果
系统完整性保护（SIP）默认启用，它会拦截绝大多数非 Apple 的 I/O Kit 驱动——哪怕你已批准、签名也完美，加载时仍会被内核静默拒绝。
- 检查状态：
csrutil status（显示 enabled 即受保护） - Apple Silicon Mac 上，Kext 必须为 arm64e 架构，且需在恢复模式下调低安全策略才能启用用户管理权限
- 不推荐关闭 SIP；更稳妥的做法是确认驱动是否已迁移到 DriverKit 或 System Extension 架构
排查死机与内核恐慌的实用路径
频繁蓝屏、黑底白字 panic 日志、重启后自动进恢复模式，大概率是 Kext 冲突或损坏。
- 查最近崩溃：
log show --predicate 'eventMessage contains "panic"' --last 24h - 安全模式启动（开机按住 Shift）：自动禁用全部第三方 Kext，稳定即说明问题在此
- 高危目录逐个清理：
/Library/Extensions/（传统 Kext）、/Library/SystemExtensions/（新架构）、/Library/LaunchDaemons/（部分后台服务也会引发连锁崩溃） - 替代方案优先：用 BlackHole 替 Soundflower，UTM 替 VirtualBox，避免使用停止维护的老驱动
