摘要

2026 年，多数用户已不再需要 Root。厂商定制系统覆盖了日常需求的主体，Bootloader 解锁权限则因灰产、外挂与供应链风险持续收紧。Root 并未消失，而是从用户态补丁迁移到内核门禁。本文以公开文档与社区共识为依据，把启动镜像拆分、GKI 与 LKM 作为前置知识，比较 Magisk、KernelSU、APatch 三条路线各自改写的分区与适用边界，并单独评估 KernelSU Next 作为当前高频迭代的内核发行版。文章同时梳理模块分层、临时 Root 的能力上限，以及 A/B 无缝更新导致 Root 丢失的机制，给出一份按内核世代执行的决策清单。

关键词：Android；通用内核镜像（GKI）；可加载内核模块（LKM）；KernelSU Next；Magisk；APatch；LSPosed；A/B 更新

目录

01  先把结论写在前面

02  你必须先懂的三块积木

2.1  手机上先跑的是 Linux

2.2  Android 13 之后，Ramdisk 从 boot 里被拆走了

2.3  LKM：Linux 早就给过的热插拔驱动

2.4  GKI：Google 在用标准内核，对抗十年碎片化

03  现代 Root 的三条技术路线

3.1  Magisk：用户态时代的规则制定者

3.2  KernelSU：把 su 放回内核

3.3  APatch：不重编内核，直接补 kernel 二进制

3.4  对照总表

04  这一轮的焦点：KernelSU Next

05  Zygisk、Zygote，以及模块的三层结构

06  临时 Root：它解决不了你以为能解决的问题

07  OTA：你点的不是更新，是切槽位

08  决策清单

09  结语

附录公开参考

01  先把结论写在前面

过去十年，「Root」几乎等于玩机入场券。2026 年再看这件事，局面已经反过来了。

各家定制系统把日常能力做得很满：小窗、超级省电、应用分身、无线调试、系统级剪贴板，甚至部分场景下的权限精细化，已经覆盖了普通人90% 的诉求。与此同时，灰产、外挂和供应链盗刷把 BL（Bootloader）锁从「极客开关」变成了厂商的风控开关。锁越来越紧，不是因为工程师突然保守，而是因为解锁之后的设备，太容易变成别人的生产工具。

所以第一句结论必须难听，也必须诚实：

对大多数人来说，Root 已经不是刚需。真正常规使用，完全用不到。

第二句结论才是这篇文章存在的理由：

Root 没有消失，它只是从「用户态补丁」迁到了「内核门禁」。还在做这件事的人，必须先懂三块积木：镜像拆分、GKI，以及 LKM。

第三句，关于圈子：玩机圈质量下滑是事实。教程互相抄、模块互相缝、防检测话术按周过期。这不意味着底层技术停了。停的是「无脑跟风」的红利。剩下的，是更窄、更专业、也更需要判断力的一条路。

作者按

这不是一份「点一下就变神机」的刷机教程，也不是劝所有人去解锁。它更像一份2026 年的判断框架：先决定自己要不要动，再决定动哪一层，最后才谈工具选型。文中涉及的分区、机制与项目，均来自公开文档与社区共识。

图1  任何内核级操作之前，备份是唯一可逆的退路

如果你只想带走一张图，看这一张决策图就够了。

图2  按内核世代选择 Root 方案：先问是否 GKI 2.0，再问是否接受替换内核

02  你必须先懂的三块积木

很多争论从一开始就错位。有人在比Magisk 和 KernelSU 谁「更强」，却说不清自己手机的 boot.img 里现在到底还剩什么。工具是结果，分区布局才是原因。

2.1  手机上先跑的是 Linux

可以把一台Android 手机理解成两层：

·  下面一层：一颗被高度定制的Linux 内核，负责和 SoC、内存、闪存、显示、射频这些硬件说话。

·  上面一层：Android 框架、Zygote、系统服务和你每天点的 App。

内核版本出厂基本就钉死。它不是「系统设置里那个Android 15」，而是 uname 看到的 5.10、5.15、6.1、6.6。厂商偶尔会合入 CVE，但很少给你换一条全新的内核主线，因为它直接碰硬件。合错一次，就是随机重启、耗电、基带异常。

这也是为什么「刷GKI 通用内核」听起来很先进，实际却经常带来耗电和兼容性回退：厂商自己的内核里，藏着大量你看不见的板级优化。

2.2  Android 13 之后，Ramdisk 从 boot 里被拆走了

Android 12 及更早，多数设备的 boot.img 是一个打包件：

·  Kernel：Linux 内核二进制

·  Ramdisk：第一阶段根文件系统，里面有 init

从Android 13 起，Google 推进 GKI 2.0，目的很明确：把 Google 维护的通用内核，和 OEM 维护的 ramdisk 拆开。

表1  Android 13 之后启动相关分区与 Root 方案的对应关系

图3  GKI 2.0 将原来的 boot.img 拆为内核、全局内存盘与厂商模块

一句话记：

·  想改init 或 ramdisk，就看 init_boot（老机型仍可能在 boot）

·  想改内核本体，永远看boot

Magisk 的生命线是 /init。它必须把 magiskinit 放进 ramdisk。所以在 Android 13 及以上机型上，官方路径变成修补 init_boot.img。APatch 的靶标是内核二进制，所以它几乎永远只要求你提供 boot.img。KernelSU 则两种都有，后面单独展开。

2.3  LKM：Linux 早就给过的热插拔驱动

LKM（Loadable Kernel Module，可加载内核模块）是 Linux 原生机制。驱动不必全部编译进内核，可以在运行时把 .ko 模块插入内核地址空间。只要设备跑的是 Linux，理论上就有这条路。Android 手机并不例外。

GKI 真正改变的是谁有权改内核本体。

2.4  GKI：Google 在用标准内核，对抗十年碎片化

以前的现实是：高通改一版、联发科改一版、三星再改一版，系统调用路径和结构体偏移都能长得面目全非。安全补丁难合，驱动难共用，Root 方案更是「一机一内核」。

GKI（Generic Kernel Image，通用内核镜像）的规定是：底层 Linux 内核必须使用 Google 构建的标准镜像，OEM 不准再把私货焊死进内核本体；自家硬件驱动编译成 .ko，放到 vendor_boot，开机再加载。

阶段差异很重要，别混着说：

·  GKI 1.0（大约 Android 12 试行）：管控松，芯片商和手机商仍能做一定魔改。

·  GKI 2.0（内核 5.10 及以上，Android 13 起对 5.10 及以上强制）：技术成熟，执行变硬。

对KernelSU 这类内核方案来说，GKI 2.0 设备体验通常明显更好，因为挂钩点更标准。老机器、非 GKI、厂商深度魔改内核，往往需要自己编译，或者直接退回 Magisk。

GKI 对 KernelSU 更友好，不等于对你的这台手机更友好。除非有明确目的，不要为了 Root 去换一条「更纯」的通用内核。耗电变高、相机异常、充电协议怪异，都是真实代价。

03  现代 Root 的三条技术路线

上古时代是SuperSU 和各种一键 Root，本质是把当时公开的提权漏洞打成 App。那页已经翻过去了。现在还值得认真讨论的，是三条技术路线。

图4  Magisk、KernelSU、APatch 分别对应用户态、内核原生与二进制补丁三条路线

3.1  Magisk：用户态时代的规则制定者

时间坐标：2016 年起，至今仍是兼容性天花板。

Magisk 跑在用户态。特征明显、容易被检测，这是它在 2026 年不再是「默认第一选择」的核心原因。成熟的隐藏方案仍然存在，但整体已经偏折腾。

它仍然不可替代的地方只有一个：几乎没有不能刷的设备。你不需要理解内核版本，也不需要会编译。门槛最低。

原理压缩成一句：Magisk 必须接管 ramdisk 里的 init。Android 13 及以上对应 init_boot.img。

常见衍生：

·  Magisk Alpha：前沿灰度分支

·  Kitsune Mask（原 Magisk Delta，狐狸面具）：强化类似旧 MagiskHide 的挂载隐藏与隔离，防检测取向强于官方

模块生态上，Magisk 仍是事实标准。系统级 zip 模块、Zygisk 原生注入，后来者基本都在兼容它的规则。它不支持内核级模块（KPM），这不是缺陷，是层级决定的。

适用边界

老机器、非GKI、厂商内核魔改严重、只要稳定能用、不想碰内核编译。

3.2  KernelSU：把 su 放回内核

时间坐标：2022 年起的内核态主流。

KernelSU（KSU）把权限门放在内核。用户态可以做到看不到传统 su 二进制；未授权应用即使扫盘，也很难按旧方式找到痕迹。它依赖编译进内核，或通过 LKM 加载，对内核世代更挑剔，GKI 设备最舒服。

社区里常把「GKI」和「LKM」当成两种互斥方案，这不精确。更干净的分法是：

表2  KernelSU 两种工作模式的操作面对照

官方KernelSU 的价值取向很清楚：最小权限、安全第一。非 GKI 的旧内核（4.x、3.x）官方不予承诺，也不把各种防检测黑科技做成默认卖点。没有特殊需求，官方树是更干净的起点。

衍生生态按「它们补了官方故意不做的部分」来理解，而不是按热度膜拜：

·  KernelSU Next：把社区刚需但上游未合入的能力做进发行版，例如 SUSFS 相关能力、更宽的内核覆盖、更细的授权规则

·  SukiSU：大量 backport，面向 Non-GKI 4.14、4.19 等老内核，强调开箱隐蔽

·  ReSukiSU：SukiSU 争议下的重写取向

·  MKSU（Magic KernelSU）：另一支内核方案变体

口碑需要单独说一句：KernelSU Next 被一部分人称为「缝合怪」，不够优雅，但对小白确实有用；SukiSU 争议更大，早期被指代码质量与过度宣传并存。技术选择不要只看星星数，要看你能不能接受它多出来的攻击面。

适用边界

GKI 2.0 设备（5.10、5.15、6.1 及以上）优先考虑；接受自己编译的人，也可以在非 GKI 上走内置路线。

3.3  APatch：不重编内核，直接补 kernel 二进制

APatch 走中间态：内核能力加用户态管理，安装体验接近 Magisk，隐蔽性接近 KSU。它的核心不是「又一个 Magisk」，而是 KernelPatch。在没有内核源码的前提下，反汇编解析预编译 kernel，静态或动态寻找挂钩点，把调用门（SuperCall）写进内核镜像。

因为kernel 无论哪个 Android 版本都在 boot.img 里，所以 APatch 的操作面非常稳定：只修补 boot.img。

代价也很明确。这是在对厂商编译产物做二进制级手术。遇到特异内核、压缩格式、指令布局异常，可能修补失败，表现为卡在第一屏。它不是「更懒的KSU」，而是「没有源码时的内核方案」。

衍生：

·  FolkPatch：预置更多社区补丁，照顾小众 SoC 的解包差异，部分版本增强 KPM 调度

·  WebAPatch：纯网页端静态修补，面向不想装一堆桌面工具的人

适用边界

GKI 2.0 但不想换内核；能接受一定变砖风险；需要 KPM 内核模块。

3.4  对照总表

表3  三条 Root 路线在 2026 年的选型对照

特殊分支例如SKRoot，社区讨论里更强调隐蔽取向，它和「日常玩机」不是同一条需求曲线。本文不把它当作常规推荐。

04  这一轮的焦点：KernelSU Next

如果你现在只想盯一个上游，盯Next。不是因为它完美，而是因为它把 2024 到 2026 这轮社区分裂之后，真正还在高频迭代的能力，收成了一个能讨论的发行版。

图5  KernelSU Next 的发行版能力：文件隐藏、可加载模块、魔法挂载与应用授权

仓库：https://github.com/KernelSU-Next/KernelSU-Next

公开页面给出的能力边界，建议原样理解，不要自行加戏：

·  定位：面向Android 的内核级 root，用内核模块实现 su 与权限管理

·  内核跨度：官方页面写的是4.4 到 6.6（Non-GKI 与 GKI）

·  Non-GKI：4.x 至 5.4 走 LTS 模式，3.x 实验性

·  GKI：5.10 至 6.6；6.6 以上仍标为实验

·  架构：arm64-v8a、armeabi-v7a、x86_64

·  管理器：Kotlin，近期界面重做

·  协议：GPL-2.0、GPL-3.0

·  规模：约4.3k stars，2026 年 9 月仍在高频推送

有些二手介绍会写成「4.4 到 6.12」。更准确的说法是：LKM 构建矩阵已经出现 android16-6.12 这类 KMI 目标，但发行说明仍把 6.6 以上当实验通道。新机型跟实验通道之前，先读 Release Note，不要只读海报。

4.1  它真正多出来的，不是又一个「一键 Root」

和上游KernelSU 相比，Next 的增值集中在「发行版体验」，而不是再发明一种 su：

1.  Magic Mount 与 OverlayFS 可切换。模块挂载不再绑死一种实现。遇到特定检测、特定文件系统兼容问题，可以在设置里换挂载策略。这是工程问题，不是玄学。

2.  App Profile：按应用限制 root。内核方案的安全叙事必须落到授权模型。不是「有 su 就全局上帝」，而是每个应用能拿什么、拿多久、能不能看到挂载层。

3.  SUSFS 相关控制。官方明确提供 SUSFS 兼容信息，以及 KPROBES hooks 隐藏模式的开关。社区把 SUSFS 当隐蔽基线，Next 选择把它放到可管理的位置。

4.  模块备份、SU 白名单备份。换机、误删、对比实验，是内核玩家的真实工作流。能备份模块和授权列表，比再多一个「炫酷模式」有用。

5.  hosts 隐藏、批量安装、自定义 OverlayFS 镜像大小。默认稀疏镜像 6GB。这些都是把 Magisk 时代用户已经习惯的事，接到内核方案的管理器里。

6.  自动更新管理器。管理器跟得上，内核模块不一定跟得上。两者版本要分开看。

4.2  必须写进正文的警告

兼容性警告

上游README 标明：近期部分内核版本出现破坏性变更，KernelSU Next 可能在 x86_64 上失败，甚至触发 kernel panic。模拟器、WSA、部分 x86 平板用户，不要拿生产环境当实验场。

另外，Next 的争议不必回避。它确实更像「上游没收、社区又刚需」的集成发行版。对追求上游纯净的人，官方 KernelSU 仍然更合适；对需要 SUSFS、老内核、挂载策略和备份工作流的人，Next 的存在是合理的。

如何上手（官方口径，不是第三方步骤）：先读官方安装文档，核对内核版本、KMI、是否 GKI，再决定 LKM 还是内置。LKM 的收益是保留原厂内核；内置的收益是不依赖 ramdisk 挂载脚本。手机优先考虑不换内核。

05  Zygisk、Zygote，以及模块的三层结构

只说「我装了个模块」，在2026 年已经不够用。至少要能指出它落在哪一层。

图6  模块分四层：应用层、运行时、系统层、内核层

5.1  Zygote 与 Zygisk

Zygote 是 Android 里孵化应用进程的母进程。Zygisk 最初是 Magisk 把代码注入 Zygote 的能力。KernelSU 和 APatch 没有常驻的用户态特权守护进程，于是把这件事解耦成独立模块 ZygiskNext。今天讨论稳定性，已经没有必要把 ZygiskNext 当成「劣质替代」。它就是内核方案的 Zygisk。

没有Zygisk，现代 LSPosed 热加载基本不成立。

5.2  三层模块，别装错层

第一层：内核级模块KPM。修补的是内核功能本身，例如某些隐匿路径、拥塞控制、驱动挂载。Magisk 原理上不支持。KSU 若要深度支持，通常意味着重编内核，所以现实中也常被当成不支持。真正以 KPM 为生态的，是 APatch 系。

第二层：系统级无痕挂载（Magisk 规范 zip）。替换系统文件、字体、音效、hosts、温控、机型伪装。KernelSU 和 APatch 基本都在兼容这套格式。它改的是「系统看起来是什么」，不是「某个 App 内部某函数返回什么」。

第三层：进程级Hook（Xposed、LSPosed）。注入目标应用，改 Java 运行时里的方法。形态通常是 App。LSPosed 模块本质上就是 Xposed 模块，接口规范是同一套；差别在运行时内核。

Xposed 有十几年历史，可以把它理解为模块 ABI。LSPosed 是为了让这套 ABI 在 Android 8 到 15 及以上还能活下去的新运行时。关键产品决策是白名单：模块只进入你勾选的应用；没勾选的进程保持干净。旧 Xposed 那种「计算器也被塞进 Hook 环境」的做法，已经不符合现代检测对抗，也不符合最小权限。

2024 年 1 月，LSPosed 核心团队公开停更。直接原因包括社区环境恶化、大量把三方系统兼容问题当成开发者原罪的 issue，以及代码被灰产环境消耗。目前主流是 JingMatrix 维护版（原团队成员接盘），以及 Irena 等分支。

只想对一两个应用用Xposed、又不想给整机 Root 的人，社区还有基于 LSPosed 核心的 LSPatch、NPatch：把运行时打进目标 APK。这是另一条需求，不要和系统级 Root 混谈。

5.3  生态地图，不是安装清单

下面这些名字出现的频率很高。把它们当坐标，而不是当购物车。效果会随检测策略实时变化，任何「现在一定过」的表述，文章写完当天就可能过期。

表4  常见模块与工具的生态坐标（效果会随检测策略变化）

仓库索引可以记三个公共入口：MMRL、Xposed Module Repository、KernelSU-Modules-Repo。大量作者已经改走私域传播，这是社区环境问题，不是你检索能力问题。

工具层常用：MT 管理器、爱玩机工具箱；想少踩分区选择坑，有人会用紫罗兰工具箱这类向导。工具只降低操作成本，不降低判断成本。

06  临时 Root：它解决不了你以为能解决的问题

「不解BL，点一下拿到 Root」在十年前是真实路径。那时候公开内核洞多，system 分区还可写，临时提权之后可以把 su 写进系统分区，变成永久。

现在这条路在工程上基本断了，原因很硬：

1.  启动链被verified boot 锁死，用户态写不进受保护分区。

2.  厂商补丁节奏加快，公开洞窗口变短。

3.  即便内存里拿到特权，重启后现场消失。

所以今天说的Temp Root，定义应该非常窄：

它是一次纯内存提权。重启即复原，不留自启，也不能当成日常Root 环境。

早期「一键Root」App，本质是漏洞打包器。那不是新文明，那是当时的 Linux 安全债。

个别历史案例里，有人在拿到临时特权后，去改写更底层的解锁相关数据，让重启后BL 状态发生变化。这属于漏洞利用与设备安全边界问题，不是可推荐的玩机流程。本文只指出一件事：BL 锁在收紧，是因为这条链曾经被规模化滥用。正规路径仍然是厂商提供的 Fastboot 解锁政策，以及你是否接受保修与安全后果。

临时Root 的合法技术价值，更接近应急取证、自有设备上的短期诊断，而不是「白嫖永久 Root」。把它宣传成解锁捷径，是对读者不负责。

07  OTA：你点的不是更新，是切槽位

任何现代Root 方案，如果放任系统更新并重启，OTA 之后 Root 几乎必然消失。这不是玄学，是 A/B 无缝更新的设计结果。

图7  A/B 无缝更新：官方包写入闲置槽位，重启后切换到没有 Root 补丁的一侧

典型过程：

1.  你现在在A 槽，boot、init_boot 已被修补。

2.  系统在后台把完整新镜像写入B 槽。B 槽是厂商原厂镜像。

3.  重启后设备从B 启动。Root 代码不在 B 上。

要在OTA 后保住 Root，必须在 B 槽写完、但还没重启的窗口里，把补丁装到另一槽。Magisk 这条链路最成熟；KSU 的 LKM 多数也能做；GKI 换内核方式更难；APatch 有对应思路，但更需要小心。无论哪条，都有真实变砖和校验失败风险。

三条铁律：

·  用全量包，不要赌增量包校验。

·  重启前完成另一槽修补。点下去就晚了。

·  先备份。这是第三次提醒，因为前两次一定有人跳过。

还有一个被经常问错的问题：OTA 会不会把 BL 重新锁上？

按Google 的规范，Bootloader 锁定状态记在更底层的保护分区和安全硬件里，不在普通系统软件分区。官方更新包改的是系统镜像，不是 BL 策略。解锁和回锁应当由用户在 Fastboot 里物理确认，不允许系统后台自动完成。OTA 丢的是 Root，不是锁状态。当然，个别 OEM 的工程实现是否严格遵守规范，属于设备相关问题，不能用一句「绝对」给所有品牌打包票。以你机型的官方说明为准。

08  决策清单

把前面所有机制压成可执行判断。顺序不要乱。

1.  先问要不要。只是去广告、改字体、备份应用，先看系统自带能力和免Root 方案。BL 解锁的代价是长期的。

2.  看内核世代，而不是看Android 大版本。设置里的 Android 15 不能告诉你该用 KSU 还是 Magisk。看内核：5.10、5.15、6.1、6.6 通常已在 GKI 2.0 区间。

第三步：按世代选路线。

·  GKI 2.0 设备：愿意并有能力处理内核方案，选 KernelSU Next 或官方 KernelSU；不想换内核，优先 LKM，或直接 APatch；不要无目的刷通用 GKI 内核。

·  非GKI、老内核、厂商魔改严重：默认 Magisk；会编译、要内核态，再考虑 Next、SukiSU 等 backport 分支。

·  需要KPM：只有 APatch 系是现实选择。

4.  模块按层装。需要改系统文件用zip 模块；需要改单个 App 用 LSPosed；需要改内核行为才碰 KPM。三层一起堆，是自己给自己制造检测面。

5.  把备份当成步骤0。DataBackup 备份用户数据；单独留一份当前槽位的 boot、init_boot 原厂镜像。没有原厂镜像，就没有回滚。

6.  OTA 当作战术动作，不当成系统自动完成的福利。更新窗口出现时，先停手，确认全量包、另一槽修补、备份三件套。

09  结语

Root 的社会意义已经变了。

2016 年，它是对抗厂商臃肿系统的用户权利。2026 年，厂商系统已经足够好，解锁权限却在回收。剩下的需求更尖锐：研究内核、做自动化、跑一套自己的模块实验室，或者只是不能接受自己的设备对自己锁死。这些需求仍然成立。它们只是不再适合被包装成「人人都该刷」。

KernelSU Next 值得写成一篇文章的焦点，不是因为它会成为下一个 Magisk 神话，而是因为它暴露了当下生态的真实结构：

·  Google 用 GKI 把内核标准化

·  OEM 用 vendor 模块和 BL 政策把定制与风控留下来

·  社区用LKM、SUSFS、ZygiskNext、LSPosed 分支，把用户能碰的面一层层接回去

这条缝会长期存在。它不会再回到「一个App 点一下」的年代，也不会彻底消失。

如果你读完只记住三句话，记住这三句：

1.  先备份，再谈任何内核级动作。

2.  先看内核世代和分区布局，再选Magisk、KSU、APatch。

3.  GKI 2.0 上，KernelSU Next 是当前最值得跟踪的内核发行版之一；但它是发行版，不是保险。

玩机圈可以烂。判断力不必一起烂。

附录公开参考

[1]  KernelSU Next 仓库  

https://github.com/KernelSU-Next/KernelSU-Next

[2]  KernelSU Next 项目页  

https://kernelsu-next.github.io/webpage/

[3]  KernelSU 安装与 LKM、GKI 说明  https://kernelsu.org/guide/installation.html

文中项目名、星标与兼容区间以2026 年 9 月公开信息为准，后续以各仓库 README 和 Release 为准。