KernelSU：把 root 权力关进内核，而不是留在用户空间
基于内核的 Android 根解决方案。兼容性状态 KernelSU 正式支持 Android GKI 2.0 设备（内核 5.10+）。
秒懂
- 它是什么？
- KernelSU 是一个基于内核的 Android root 方案，官方支持 GKI 2.0 设备（内核 5.10+），通过内核模块实现 su 与模块系统。本文拆解它的工作原理、安装路径、已知风险，以及它与 Magisk 的根本差异。
- 适合谁用？
- KernelSU 适合拥有 GKI 2.0 设备、愿意自行编译内核或跟随官方预构建镜像的开发者，以及那些需要精细控制 root 权限、希望用 App Profile 限制每个应用权限的人。不适合追求即插即用的普通用户，因为它的安装依赖内核版本，且 x86_64 设备在较新内核上有崩溃风险。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Kotlin（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
用户空间 root 的瓶颈，内核 root 的起点
Magisk 这类工具把 su 和模块逻辑放在用户空间，通过修改 boot 镜像来注入。这有个隐含问题：任何用户空间的进程都可能被检测或干扰，尤其是在系统完整性校验越来越严的今天。KernelSU 换了个思路，把 su 直接放进内核。这不是新点子，README 里明确提到它借鉴了 Kernel-Assisted Superuser，那是个 2013 年的项目。KernelSU 的卖点不是发明，而是把它做成一个可维护、可扩展的现代框架。它面向的是愿意折腾内核的开发者，不是只想装个 root 管理器的小白。
内核里的 su 和模块系统，数据流长什么样
KernelSU 的核心是内核模块，它注册了自己的 su 实现，并管理 root 权限的授予。当应用请求 root 时，请求会通过内核里的机制传递到用户空间的 Manager 应用，后者决定是否放行。这个放行决策可以按 App Profile 来定制，README 里叫“把 root 权力关进笼子”。模块系统基于 metamodules，这是一种系统less 修改的基础设施，类似 Magisk 的模块但运行在内核层面。具体的数据流是：内核模块拦截 su 调用，检查权限，然后执行或拒绝。这比用户空间的 su 更隐蔽，因为普通进程看不到内核里的钩子。但这也意味着，一旦内核模块有 bug，后果是整个系统崩溃，而不是某个进程崩溃。
GKI 2.0 是舒适区，老内核要自己动手
官方支持范围是 GKI 2.0 设备，内核版本 5.10 以上。GKI（Generic Kernel Image）是 Google 推动的统一内核镜像，它把内核和厂商驱动分开，这让 KernelSU 可以只针对 GKI 内核打补丁，不需要为每个设备定制。如果设备内核是 4.14 以上但不是 GKI，文档说仍然支持，但你需要自己编译内核。这不是一个简单的过程，你得下载内核源码、应用 KernelSU 的补丁、再用工具链编译。README 还提到 WSA（Windows Subsystem for Android）、ChromeOS 和容器型 Android 都支持，这扩大了适用范围。但要注意，架构只支持 arm64-v8a 和 x86_64，其他架构就别想了。
x86_64 的警告：内核崩溃不是玩笑
README 里有一个醒目的警告：最近的内核版本实现了一个破坏性变更，导致 KernelSU 在 x86_64 上可能失败并触发内核 panic。这不是一个边缘问题，而是官方明确标记的坑。如果你在用 x86_64 设备，比如某些模拟器或 ChromeOS 设备，升级内核前必须去官网检查兼容性。这个警告也暴露了内核 root 的代价：你依赖内核的稳定性，而内核的变更不受你控制。相比之下，Magisk 的用户空间方案在系统更新后通常还能撑一阵，而 KernelSU 可能直接让设备变砖。这不是说 KernelSU 不好，而是说它的使用场景有硬边界。
安装与构建：命令和配置项在哪里
README 没有给出具体的安装命令，它指向官网的安装指南和构建指南。从仓库结构看，安装方式大概分两种：一是从 releases 页面下载预构建的 GKI 镜像，二是自己编译内核。构建过程需要你配置内核源码，启用 KernelSU 的选项，然后编译。具体配置键在官网有文档，这里无法从 README 确认。但有一个明显的事实：这不是一个 `pip install` 或 `apt install` 能搞定的东西。你需要 Android 开发环境、内核源码和交叉编译工具链。如果你不想编译，官方 releases 提供了 v3.3.0 等版本，但你必须确认自己设备的 GKI 内核版本匹配。
App Profile：比 Magisk 的 per-app 配置更细
KernelSU 的 App Profile 功能值得单独说。它允许你为每个应用定义 root 权限的边界，不只是允许或拒绝，而是可以限制 su 能做什么。比如你可以让一个应用只能读写特定目录，或者禁止它访问某些系统调用。这个机制在内核层面实现，比 Magisk 的 MagiskHide 或 DenyList 更底层。Magisk 的 DenyList 是让应用看不到 root，而 App Profile 是限制 root 的能力本身。这是一个设计上的取舍：Magisk 追求隐蔽性，KernelSU 追求控制力。如果你需要精细控制某个应用的 root 行为，KernelSU 的 App Profile 是更直接的工具。但这也意味着你需要理解内核权限模型，否则可能配置出漏洞。
许可证和翻译策略：GPL 的分裂与社区运营
许可证是分裂的：kernel 目录下的文件是 GPL-2.0-only，其他部分是 GPL-3.0-or-later。这不是一个常见的选择，因为 GPL-2.0 和 GPL-3.0 不兼容。这意味着如果你要复用 kernel 目录的代码，必须遵守 GPL-2.0 的条款，而其他部分则受 GPL-3.0 约束。这会给潜在的贡献者带来法律上的困惑。另一个值得注意的点是翻译策略：README 明确说不再接受 Weblate 的翻译贡献，所有翻译改用 LLM 处理，且不接受对现有英文和中文翻译的修改。这是一个务实的决定，但也意味着翻译质量可能不稳定。如果你依赖文档的准确性，最好以英文版为准。
编辑结论
KernelSU 适合拥有 GKI 2.0 设备、愿意自行编译内核或跟随官方预构建镜像的开发者，以及那些需要精细控制 root 权限、希望用 App Profile 限制每个应用权限的人。不适合追求即插即用的普通用户，因为它的安装依赖内核版本，且 x86_64 设备在较新内核上有崩溃风险。采用前，先确认你的设备内核版本是否在官方支持列表，检查是否启用了 GKI 2.0，并阅读官网的安装指南中关于内核 panic 的警告。如果你不想碰内核，Magisk 仍是更稳妥的选择。最终判断：KernelSU 是一个把 root 逻辑下沉到内核的激进方案，它带来更隐蔽的 su 和更细粒度的模块系统，但代价是更高的构建门槛和更窄的设备兼容面。
社区笔记