模块不生效的七步排查清单

快速诊断：框架本身正常吗

先确认基础环境没问题。打开 Manager：

• 首页的核心版本号是否正常显示（不是 blank 或 "未加载"）
• 应用管理里目标应用是否显示「本地加载器模式」或「内置模式」
• 如果是本地模式，模块管理里对应模块是否已启用

三项都 OK 再往下查。有任何一项异常先回到对应章节解决。

七步排查清单

Step 1：强制停止 → 清缓存 → 重开

90% 的情况这一步就够了。LSPatch 是在应用进程启动时注入模块的——应用如果已经在跑，进程里没有 LSPatch 运行时，模块当然不会生效。

1. 系统设置 → 应用管理 → 目标应用 → 强制停止
2. 存储 → 清除缓存（清除数据会删登录信息，谨慎）
3. 返回应用列表 → 重新打开

Step 2：作用域勾对了吗

回到 Manager → 应用管理 → 目标应用 → 模块作用域，确认模块是勾上的。

别犯这个错：LSPatch 本地模式的作用域入口在「应用 → 模块」方向（点应用 → 勾模块），不是「模块 → 应用」方向。如果你习惯了 LSPosed 的入口方式，很可能看错了地方。

Step 3：模块是不是支持 LSPatch

模块本身可能只测过 LSPosed（Root 模式）。快速验证：

• 模块仓库或说明里有没有 "Non-Root" / "LSPatch compatible" 标记
• 搜酷安/GitHub Issue 里有没有人反馈过 LSPatch 下的表现

如果模块开发者加了反内置检测（便携模式下会主动拒绝运行），本地模式可以试试——本地模式是 Manager 动态加载，检测逻辑可能触发不了。

Step 4：模块是不是在正确时机被加载了

有些模块需要在应用启动的非常早期（<clinit> 阶段）hook。LSPatch 的注入点比 Zygote 晚一整个阶段，如果模块 hook 的目标在 LSPatch 初始化之前就执行了，那模块永远也 hook 不到。

判断方法：把应用版本回退到几个月前的老版本试试——老版本的类加载顺序可能不同，Hook 时机有可能赶得上。

Step 5：LSPatch 版本 vs 模块版本

LSPatch 原版停更于 2023 年 12 月，核心版本 v1.9.2。模块如果依赖更新的 Xposed API 特性（比如 hook 新的 Android API、更新的 libxposed 版本），可能在 LSPatch 原版上不工作。

解法：换 opatch/onpatch 分支——它们持续更新，核心版本更新。

Step 6：模块和宿主应用版本的匹配

很多模块硬编码了宿主应用的版本号："只在微信 8.0.43 到 8.0.50 之间工作"。如果你的微信版本超出这个范围，模块直接跳过。

解法：

1. 找对应版本的宿主应用 APK，修补那个版本
2. 或者在修补时「覆写版本号」——把修补后的版本号改成模块期望的范围内（99% 场景别动，但这个场景刚好是例外）

Step 7：还是不行？换太极·阴或回 LSPosed

走到这一步，大概率是以下几种情况：

• 模块 hook 的方法在应用新版本里已经不存在了
• 应用做了额外的检测来反 hook
• LSPatch 补丁式框架的注入时机从根本上赶不上模块需要的时机

务实选择：LSPatch 能做的事已经到天花板了。要么换太极·阴（商业闭源，有防检测机制），要么回到 LSPosed（需要 Root）。

完整诊断工具

上面七步都走完还是不行的话，用详细日志来做精确诊断：

1. Manager 设置 → 打开「输出详细注入日志」
2. 强制停止目标应用 → 重开
3. 去修补输出目录找日志文件（名字类似 inject_xxx.log）
4. 用电脑看日志，搜：

• Error / Exception：看有没有模块加载失败的堆栈
• module found / module loaded：确认模块是不是被找到了、是不是被成功加载了
• hook skipped / not in scope：模块是不是因为作用域或版本原因被跳过了

日志能告诉你模块在 LSPatch 眼里是「找到了但拒绝加载」、「找到了但 hook 方法不存在」，还是「根本没找到」。比猜要高效得多。