Zygisk 与 Riru 的互斥问题
为什么会互斥
Zygisk 与 Riru 是两套向 Zygote 进程注入代码的通道，各自在启动链上占位。同时存在时互相干扰，结果通常是两败俱伤：Riru 在开启 Zygisk 的系统上会失效，框架激活也随之失败。
官方在 v2.x 起直接移除了 Riru 支持，新版本只有 Zygisk 一条路，这个历史问题主要困扰还在用第一代包的老设备。
自查表：开关与包的搭配
| Zygisk 开关 | 已装 Riru | 该刷的包 |
|---|---|---|
| 开 | 无 | Zygisk 版 |
| 关 | 已装 | Riru 版 |
| 开 | 已装 | 出问题组合：要么关 Zygisk 走 Riru，要么移除 Riru 走 Zygisk |
常见翻车场景
场景一：新面具默认开着 Zygisk，用户照老教程又刷了 Riru + Riru 版框架 → 激活失败。修复：卸载 Riru 与框架，打开 Zygisk，刷 Zygisk 版框架。
场景二：老设备稳跑 Riru 版多年，某天升级面具后 Zygisk 开关默认打开 → Riru 环境失效，框架全趴。修复：关掉 Zygisk 开关重启，Riru 环境恢复；或干脆顺势迁移到 Zygisk 路线。
场景三：装了第三方 Zygisk 提供器又开着面具内置 Zygisk → 双实现打架。修复：二选一。面具用户用内置，KernelSU/APatch 用户用提供器。
修复的通用流程
- 卸载框架（及 Riru，如适用）
- 把 Zygisk 开关调整到与目标包配套的状态
- 重启确认环境就位
- 重刷对应版本的框架包，重启验证通知出现
一劳永逸的建议
除非设备停留在一个不支持 Zygisk 的老面具上，否则一律走 Zygisk 路线：它是当前标准，v2.x 唯一支持，Riru 相关的排错知识可以逐步忘掉了。