KernelSU 模块机制与 systemless——不改系统分区也能改系统

模块是干什么的

模块（module）让你在保持系统分区完整的前提下修改系统文件、注入脚本、加 SELinux 规则——这种机制叫 systemless。卸载模块或停用后，系统原样如初，OTA 与保修状态不受影响。

KernelSU 的模块运作机制与 Magisk 几乎一样：熟悉 Magisk 模块的用户可以直接沿用认知，主要差异集中在挂载架构与文件替换方式上（见元模块是什么）。

模块在磁盘上长什么样

模块就是 /data/adb/modules/ 下的一个文件夹，核心成员：

/data/adb/modules/<模块ID>/
├── module.prop        # 模块身份证：id、name、version 等
├── system/            # 要叠加进 /system 的内容
├── post-fs-data.sh    # 挂载前的阻塞阶段脚本
├── post-mount.sh      # 挂载完成后的脚本
├── service.sh         # 大多数模块该用的非阻塞脚本
├── boot-completed.sh  # 系统启动完毕后执行
├── uninstall.sh       # 卸载时执行
├── system.prop        # 以 resetprop 修改系统属性
├── sepolicy.rule      # 追加 SELinux 规则
├── disable / remove / skip_mount   # 状态标记文件

三个标记文件值得记住：出现 disable 模块被禁用；出现 remove 下次重启被移除；出现 skip_mount 则其 system 目录不参与挂载。

system 目录如何生效

模块的 system 目录会以 overlayfs 方式叠加在真实 /system 之上：同名文件被覆盖、同名目录合并；想「删除」系统文件用 mknod 创建同名节点触发 whiteout。这一切不写物理分区。

五个启动阶段与脚本的对应

阶段	特点	对应脚本
post-fs-data	阻塞，最长 10 秒，Zygote 之前	post-fs-data.sh
post-mount	挂载完成后	post-mount.sh
late_start 服务	非阻塞并行	service.sh（推荐）
boot-completed	系统启动完毕	boot-completed.sh

通用脚本放在 /data/adb/service.d 等目录，需可执行权限；模块脚本则随模块启停。脚本一律运行在 KernelSU 内置 BusyBox 的 ash 独立模式下，环境行为可预期。

重要前提：要让模块的 system 目录真正挂上，需要先安装元模块——这正是很多新装用户「模块不生效」的原因，下一页展开。