做马甲包应该都遇到过这种情况，提审被苹果以重复应用打回来，原因是代码逻辑和资源文件的结构特征跟原包太接近。App Store 审核会比对二进制特征，两个包如果类名、方法名、资源 MD5 高度一致，很容易被打回。不止是新上的包，更新版本时如果混淆配置没变、生成的符号跟上个版本一样，一样可能触发重复判定。这里把从工具选型到实际操作的路径记一下。
Obfuscator-LLVM：开源但门槛高
Obfuscator-LLVM 是 LLVM 的一个开源分支，编译时对中间代码做混淆。它能在源码层面把函数名、变量名改成无意义的符号，混淆强度不错。但问题是它需要在 Xcode 项目里集成编译工具链，配置流程比较长——要改 Build Settings、加编译 flag、处理链接参数，一个不留神编译就过不去。在最新 Xcode 版本上经常要等社区适配，新版本出来到工具稳定个几周是常有的事。如果你的项目用了 Flutter 或 Unity，那 Obfuscator-LLVM 只覆盖原生层，Dart 和 C# 层管不到，得另外想办法。
手动改工程文件：累人且容易漏
也有团队选择在源码里手动加垃圾代码、改资源文件命名、重排类结构。好处是纯人工控制，不会有工具翻车。但实际操作下来，一个中型项目几千个文件，光改类名就要改到对应的头文件和引用位置，改完还要跑一遍编译确认没报错。如果团队同时维护两三套马甲包，每个包的混淆配置要保持独立又不能让它们互相串，维护成本直线上升。
IpaGuard：直接对 IPA 做混淆
IpaGuard 走的是另一条路——不需要源码，直接拿编译好的 .ipa 文件做代码混淆和资源处理。操作流程分几步：把打包好的 IPA 拖进工具，在混淆界面勾选要处理的模块——类名、方法名、属性名、参数名，每项可以单独调强度等级。工具会把 OC、Swift、C++、Dart 的符号全改成不可读的乱码，同时自动清理调试信息。整个过程不需要碰项目源码，所有操作都在本地电脑上完成，不会因为混淆导致编译链断裂，也不需要担心代码上传到服务器的安全问题。
资源这边也一并处理：图片、mp3、js、xib、storyboard、json 等文件的名称统一改成无意义字符串，MD5 值也重新生成。这些改动在二进制层面制造了足够的差异，让审核系统不会判定为重复包。混淆完以后可以配置签名参数做重签名，装到真机上跑几轮确认功能正常，再打包上传。
和 Obfuscator-LLVM 怎么配合
如果原项目已经集成了 Obfuscator-LLVM 做编译期混淆，可以把它生成的混淆 IPA 再交给 IpaGuard 做第二轮资源混淆和调试信息清理。两层处理完之后，代码符号和资源特征都变了，重复判定的概率进一步降低。
