如何用 Hybrid Mount 的三级规则精准控制挂载：按模块、按路径混用 Overlay、Magic、VFS 全方法

【免费下载链接】meta-hybrid_mountHybrid Mount Metamodule项目地址https://gitcode.com/gh_mirrors/me/meta-hybrid_mount点击查看免费下载Hybrid Mount 是一款面向 KernelSU 与 APatch 的混合挂载元模块meta-module。它最大的亮点是三级规则体系你可以按模块、按路径为每个挂载目标自由分配 OverlayFS、Magic Mount 或 VFS 后端——甚至在同一台设备上三种后端混用互不干扰。对装了不少模块的进阶用户来说这套规则就是实现精准控制挂载的核心手段。先搞懂三级规则是什么Hybrid Mount 在启动时只读扫描/data/adb/modules下的所有模块然后按优先级从高到低的三级规则为每一条挂载项决定使用哪个后端优先级规则级别配置位置作用范围 最高路径规则paths[rules.模块.paths]单个文件/目录 中模块默认default_mode[rules.模块]整个模块 基础全局默认default_mode顶层字段所有未覆盖的模块打个比方全局默认像公司制度模块规则像部门规定路径规则像个人申请——越具体越优先。这套优先级逻辑的实现在 src/plan/mod.rs 中可以找到规划阶段还会做冲突检测同一个文件路径只能进入一个后端真正的冲突会在启动规划阶段直接报错而不是挂载出诡异结果。三种后端怎么选一文看懂差异后端本质适用场景OverlayFS真实挂载支持目录/文件/符号链接通用首选支持 tmpfs 与 ext4 两种存储模式Magic Mount真实挂载bind/mirror需要.replace、whiteout 语义的精细替换VFS内核侧规则注入非真实挂载隐藏路径、opaque 目录、按 UID 隔离等轻量操作几个新手容易踩的坑普通目录可以共享Overlay 与 Magic 两个真实挂载后端可以共享同一目录作为结构节点但文件、类型或.replace冲突必须避免。VFS 不是挂载它通过 keyring 把注入规则下发给 HM 自有的hybridmount内核模块因此 VFS 目标不能有被 Overlay/Magic 挂载的祖先目录否则会报PlanConflict。VFS 不可用会自动降级内核里没有 Provider 时vfs规则会被改写成ignore若设置了vfs_strict true则直接启动失败适合必须生效的场景。完整配置示例一份 config.toml 学会全部写法配置文件位于/data/adb/hybrid-mount/config.toml仓库内有一份带注释的默认模板见 module/config.toml。下面是覆盖全部三级规则的写法moduledir /data/adb/modules overlay_mode ext4 # ext4 | tmpfs default_mode overlay # ① 全局默认overlay | magic | vfs # ② 模块级整个模块改用 Magic Mount [rules.my_module] default_mode magic # ③ 路径级模块内个别路径再覆盖回 Overlay [rules.my_module.paths] system/etc/hosts overlay system/build.prop vfs注意两点路径相对模块根目录书写带不带开头的/都行解析时会统一规范化。模块级和路径级规则还支持ignore等于跳过这条路径/整个模块全局默认则只接受overlay、magic、vfs三种值。配置字段的完整 schema 定义在 src/config.rs其中default_mode、vfs_strict、vfs_isolate_uids等字段都有明确注释。常用场景4 个直接抄的模板场景一某模块整体换成 Magic Mount模块里有大量.replace目录替换时Magic Mount 更稳[rules.my_module] default_mode magic场景二模块内只有个别文件想走 VFS 注入全局和模块默认保持 overlay仅用路径规则把单个文件切到 VFS[rules.my_module.paths] system/etc/hosts vfs场景三临时屏蔽某个路径不装模块也想忽略某条挂载项写ignore即可[rules.my_module.paths] system/app/SomeApp ignore场景四全局改用 Magic个别模块例外把顶层default_mode改成magic再给需要 OverlayFS 的模块单独加一条[rules.模块]覆盖回来——这正是三级规则逐层覆盖的设计本意。此外仓库还维护了一份模块黑名单 module/module_blacklist.toml被列入黑名单的模块会被规划阶段整体跳过优先级高于任何规则。规则冲突时的判定逻辑避坑指南规划器planner在把共享节点树交给执行器之前会做三道检查全部实现在 src/plan/mod.rs跨后端冲突同一文件被两个不同后端声明 → 直接报PlanConflict启动失败.replace一致性Magic 的目录替换不能在 Overlay 之后遮住已挂载的子树VFS 遮蔽检查VFS 目标若藏在 Overlay/Magic 挂载的目录下会被判为不可见而报错。换句话说冲突不会静默吞掉你一定能从启动日志/WebUI 里看到明确原因。冲突判定与执行顺序的完整说明见 docs/ARCHITECTURE.md 的共享节点树契约一节。修改后如何生效与验证重启生效配置修改在下次重启后由启动流水线 module/metamount.sh 触发执行WebUI 查看模块自带 WebUIMD3 / Miuix 双界面可以直接修改规则并查看每个模块当前分配的后端命令行验证在 root shell 中执行下面命令查看状态与 VFS 诊断VFS 不可用时 WebUI 会自动隐藏相关选项HM/data/adb/modules/hybrid_mount/hybrid-mount $HM status # 查看启动状态、各后端活动挂载 $HM vfs-doctor # 只读诊断 VFS Provider 是否可用更多 CLI 命令如运行态vfs rule add临时注入规则的完整说明见 docs/VFS_CLI.md。总结一句话记住这套方法全局定基调、模块管大局、路径做精修一个文件只进一个后端冲突启动即报错。掌握以上四级动作全局默认 → 模块默认 → 路径覆盖 → 黑名单你就能在任何模块组合下精确控制 Hybrid Mount 的挂载行为。更多细节可阅读中文文档 docs/README_ZH.md 与架构说明 docs/ARCHITECTURE.md。赞分享【免费下载链接】meta-hybrid_mountHybrid Mount Metamodule项目地址https://gitcode.com/gh_mirrors/me/meta-hybrid_mount点击查看免费下载相关推荐Hybrid MountAndroid 根挂载元模块终极指南一个模块统一 OverlayFS、Magic Mount 与 VFS 三大后端Hybrid MountAndroid 根挂载元模块终极指南一个模块统一 OverlayFS、Magic Mount 与 VFS 三大后端 Hybrid Mdoctrine/inflector源码实战RulesetInflector如何按不可变、不规则、常规三级规则精准匹配doctrine/inflector源码实战RulesetInflector如何按不可变、不规则、常规三级规则精准匹配 doctrine/inflector后端Werkzeug DispatcherMiddleware 使用指南按 URL 路径挂载多 WSGI 应用Werkzeug DispatcherMiddleware 使用指南按 URL 路径挂载多 WSGI 应用 DispatcherMiddleware 是 We后端Web框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考