APatch 和 Magisk 的核心差异 — 改 init vs patch 内核

一条根本不同的路线

Magisk 和 APatch 虽然都叫 root 方案，但它们的技术路径从一开始就不一样：

这条根本差异导致了两者在几乎所有维度上的不同。

Magisk 安装流程：

APatch 安装流程：

看起来只差"修补的是 ramdisk 还是内核"——但这意味着 Magisk 修补产物只能用于同一设备的同一 boot 分区，而 APatch 修补产物的内核部分是设备无关的（KernelPatch 会在运行时适配不同内核）。

这是两者最本质的区别：

Magisk 的 root 在用户空间可见：su 守护进程、su 二进制文件、magisk 相关属性、以及执行 su 后进程身份变化——SafetyNet 检测的就是这些痕迹。

APatch 的 root 在内核层面隐身：没有 su 二进制、没有守护进程、没有额外属性。SuperCall 系统调用被设计成验证密钥错误时"调用方不受任何影响"——所以检测 App 尝试调用 SuperCall 也会被静默忽略。

对于需要过 root 检测的场景（银行 App、游戏），APatch 天然就比 Magisk 更有优势。

Magisk 的 OTA 保 root 机制：OTA 更新时系统会把新 boot 写到未使用的槽位（A/B 分区），Magisk Manager 会把修补好的 boot.img 刷到那个槽位，重启后切换到修补好的槽位。

APatch 的 OTA 保 root 机制和 Magisk 完全一致——安装到未使用槽位（OTA 后）。这是 APatch 从 Magisk 那里借鉴过来的成熟方案。

但有一个坑：APatch 修补 boot 时默认不备份原厂 boot.img（Magisk 会）。对于 MIUI/HyperOS 用户，如果不在 OTA 前手动恢复原厂 boot，会导致系统校验失败，强制使用全量包。

两者的模块都是 systemless 修改（不触碰系统分区），格式基本一致。APatch 的 APM 模块实现来自 KernelSU，代码层面和 Magisk 模块高度兼容——大部分 Magisk 模块可以直接装在 APatch 上。

但 APatch 多了一个 KPM 内核模块系统，能做 Magisk 模块做不到的事（内核 hook、syscall hook 等）。