先厘清：两个“报毒”不是一回事
渠道侧提示风险，和本机杀毒软件报警，看起来都是“检测到问题”，但背后的判定逻辑差别很大。渠道扫描通常是一套多引擎叠加平台自建规则的组合：既有静态特征匹配，也有行为画像、权限组合、签名与包体一致性检查，甚至参考历史同包名、同证书的处置记录。本机杀毒则更依赖本地病毒库和启发式规则，更新频率、引擎版本、样本覆盖范围都和渠道侧不同。
所以“渠道报毒、本机没报”并不矛盾，它只说明：两边看到的证据集不一样。把本机结果当成“没问题”的证据，往往会误判。
渠道规则和本地引擎，差异在哪里
- 病毒库时效与样本范围：渠道侧样本量大、更新快，新出现的变种可能先进入渠道规则；本地库滞后是常态。
- 判定维度不同：本地引擎偏重文件特征；渠道还会看权限申请与功能是否匹配、SDK 来源、动态加载行为、网络明文传输、签名是否被二次打包等。
- 阈值与策略：渠道为了控制误放，往往采用更保守的阈值，宁可提示也不放过；本地产品为了控制误报投诉，阈值可能更宽松。
- 上下文信息：渠道能看到开发者账号历史、同证书下的其他包、上架记录，这些都会影响处置结果。
换句话说，渠道报毒更像一次“合规与风险的综合评估”，而不只是病毒查杀。
拿到报毒提示后，先做可复现的回归验证
不要急着改代码或直接加固，先把问题变成可复现的。建议按下面的顺序走一遍：
- 固定输入：记录被提示的具体包（包名、versionCode、签名指纹、构建时间），确认提审包和本地测试包是同一个文件，避免“测的不是提审的那个包”。
- 换环境复测：用不同引擎、不同版本的检测工具交叉验证，观察提示是否稳定出现，还是偶发。偶发往往指向动态行为或网络请求，稳定出现更可能是静态特征。
- 拆解差异：对比上一版通过审核的包，看新增了哪些权限、SDK、第三方库、动态加载或反射调用。多数渠道提示都能在“新增了什么”里找到线索。
- 最小化验证：把可疑模块单独打一个测试包提交或送检，确认是不是它触发的。这一步能把范围从“整个 App”缩到一个组件。
- 记录结论：把每次复测的包指纹、检测结果、时间点记下来，形成回归清单。后续每次发版都跑一遍，比事后救火省事得多。
需要说明的是，各渠道的具体判定规则并未完全公开，网上流传的“某条规则一定触发”的说法大多不可靠。验证要以自己包的实测结果为准。
那到底还要不要加固
判断的关键不是“本机有没有报”，而是报毒原因是否与包体被篡改、代码可被轻易二次打包有关。
- 如果提示指向签名不一致、包被重打包、资源被替换，加固（完整性校验、防二次打包）是对症的。
- 如果提示指向权限过度申请、SDK 行为、明文传输，加固解决不了问题，该做的是收敛权限、替换或升级 SDK、改走 HTTPS。
- 如果只是特征误判，优先走申诉与说明流程，同时保留复现材料，盲目加固反而可能引入新的兼容问题。
关于混淆、完整性校验和防二次打包各自能解决什么，站内已有拆解，可参考 博客文章 中的相关说明，避免把“加了壳”当成万能方案。
把验证流程固化下来
对持续发版的团队来说，更实际的做法是把上面几步做成发版前的固定动作：构建产物留指纹、关键版本送多引擎交叉检测、对比上一版差异、记录结论。渠道规则会变，本地库也会变，只有自己的回归记录是稳定的参照。需要了解分发与加固相关的服务范围，可以看 服务说明。
总结一句：本机没报不等于安全，渠道报毒也不等于一定要加固。先复现、再定位、后决策，比凭感觉处理更靠谱。