打包签名的局限：嵌入能力与过签不可兼得
打包签名给了你第二条路，但它有清晰的边界。把边界写明白，是为了让你在它做不了的事情上不要浪费时间。
局限一：模块不能内置进应用
FPA 只支持本地模式——框架代码打进应用包，模块本身留在 FPA 侧，运行时按作用域挂载。它做不到把模块 APK 一起塞进成品里（社区在过签场景的讨论中特别强调过这一点：「FPA 仅支持本地模式，不能将模块内置到应用中」）。
带来的实际差别：成品的运行依赖 FPA 本体在场与模块的安装维护，模块升级要去 FPA 侧操作，而不是换一个新成品。这个依赖关系在为什么 FPA 不能卸载里讲过。
局限二：嵌入与过签是二选一
社区把免 Root 打包工具的能力格局总结成一句话：能免 Root 过签的不能嵌入模块，能嵌入的如 LSPatch、NPatch 又不能过签。这句话值得记住，它意味着：
- 你的应用需要过签名校验 → 选 FPA，接受「模块不内置」；
- 你的需求是模块内置、成品自包含 → FPA 给不了，需要用支持嵌入的工具，接受「过签弱」；
- 两个都要 → 目前免 Root 方案里没有两全的答案。
过签能力的细节与上限，分别在过签是什么意思与哪些应用过不了签。
局限三：改签名的代价一样不少
打包签名只是换了个组包方式，签名字段照样变了——卸载重装、支付登录分享可能失灵，这些代价与动态加载完全一致（见支付登录分享失灵）。别因为「手动组包显得更可控」就以为能绕开签名问题。