内测群里最常见的一类返工是这样开始的：包已经发出去，测试用户装完却说「功能没变化」；或者上传时一直解析失败，回头才发现文件在传输中被截断了。安装包到底有没有被改动、手上这份是不是你要发的那一份，靠文件名和修改时间都判断不了，真正靠得住的只有哈希校验。
为什么内测分发前值得先校验一遍
内测包从构建到用户安装，中间要经过好几道手，每一道都可能让文件悄悄变样：
- 传输中断：用聊天工具或网盘传大文件可能出现截断，文件看着还在，内容已经不完整
- 多轮产物混淆：CI 目录里往往堆着好几个同名的
app-release.apk，随手拖错一个很难察觉 - 后处理改动了产物：混淆、加固、补签等步骤都会改变文件内容，哈希自然跟着变
- 事后难以对账：真出问题时双方各说自己手里那份是对的，缺少客观依据
哈希值的作用就在这里：文件内容只要有一个字节不同，算出来的值就完全不同。它是判断「是不是同一份文件」最直接的办法。
三步完成一次哈希校验
按下面的顺序做，一次校验用不了几分钟：
- 出包后立刻算一次哈希。构建完成、还没往外发之前就算一遍，把结果连同版本号记进发版记录或工单里。
- 拿到手上这份再算一次。Windows 上可用
Get-FileHash .\app-release.apk -Algorithm SHA256；macOS 与 Linux 上可用shasum -a 256 app-release.ipa或sha256sum app-release.ipa。 - 逐字符比对结果。一致说明是同一份文件；不一致说明中间某个环节换了内容，此时别急着分发，先回到构建产物重新确认。
关于 MD5 补一句：它计算快、结果短，但已知存在碰撞风险，更适合当作「快速比对」的手段；对可靠性要求高的场景优先选 SHA-256。
只对哈希不够，还要过三条核对线
单一手段容易漏判，内测分发前建议同时过下面三条线：
- 哈希值：确认文件内容没有被改动
- 文件大小：与构建记录里的字节数一致，能快速发现截断类问题
- 版本信息：确认
versionCode与versionName符合这一轮的预期，避免「包是对的，但版本还是上一轮」
三条线都对上，才能确定手上这份就是准备发给测试用户的安装包。
分发环节怎么进一步减少装错包
哈希校验解决的是「是不是同一份文件」，分发环节还要解决「用户装到的是不是最新那一版」。在虾分发（https://xiafenfa.com）上传安装包后，系统会自动解析并生成分发二维码，安卓与 iOS 可合并为同一个入口；配合多版本管理把每一轮版本号标注清楚，需要回退时随时启停对应版本即可，不必重新上传旧包。如果包只发给固定几台设备，还可以叠加下载密码与 IP 白名单。遇到解析失败时，先按前面三条线核对一遍，多数问题能当场定位。
常见问题 FAQ
| 问题 | 答案 |
|---|---|
| 哈希一致但用户装不上，怎么办？ | 哈希只能证明文件没被改动。装不上多半与设备兼容性、系统版本限制或证书状态有关，需要另外排查 |
| MD5 现在还能用吗？ | 快速比对场景仍可用；对可靠性有要求时优先选 SHA-256 |
Get-FileHash 默认用哪种算法？ |
默认 SHA-256，也可以用 -Algorithm 显式指定其他算法 |
| 大安装包算哈希要很久吗？ | 哈希需要完整读取文件，包越大耗时越长，属正常现象 |
建议 把「出包后立刻算哈希、连同版本号写进发版记录」固定成流程里的一步。测试反馈问题时，先比对哈希值和
versionName，确认双方说的是同一份包，再往下查代码，能省掉大量来回确认的时间。
安装包校验算不上高深技术，但它把「我们说的不是同一个包」这类无效沟通挡在了前面。把哈希、体积、版本号三条线串进出包流程，再配合分发平台的版本管理与回退能力，内测节奏会稳定不少。