多数团队把精力都花在「怎么把内测包发出去」，很少认真想过「内测结束后怎么收场」。等下个项目启动、负责分发的同事换人、或客户半年后又来要那个包，才发现二维码还挂着旧版本、安装包只在某个分发账号里、下载记录也没人导过。这份清单给出一条可直接执行的收尾路径，适合中小团队与外包项目在验收后使用。
为什么内测收尾比发布更容易出问题
- 分发二维码本身长效：不因你停止维护而失效，历史版本可能还在被扫码安装。
- 安装包只存在于平台账号里：成员变动或权限调整后，本地找不到与线上一致的包，复现问题很被动。
- 分发记录留不下来：哪个版本发给了哪些人、覆盖多少台设备，事后很难补齐。
- 证书与描述文件状态会变化：状态改变后旧包可能无法安装，只留包不留证书信息等于留了个空壳。
内测收尾的六步清单
- 冻结交付版本。确认通过验收的版本，把版本号写进项目文档，并在分发平台的多版本管理里标注清楚，避免与后续迭代包混淆。
- 停用历史版本入口。虾分发的多版本管理支持随时启停，把不再对外分发的历史版本停用，只保留交付版；项目结束后入口也可一并停掉。会员版二维码永久有效指链接不会自然过期，并不代表该让它长期对外开放。
- 归档安装包本体。把 APK 与 IPA 复制到内部存储或版本库，不要只依赖在线文件，同时保存证书与描述文件信息、打包配置说明。
- 导出分发记录。下载量、设备分布、地域分布、下载时段都支持导出，与测试报告一起归档，写清「哪个版本发给哪些人、覆盖多少台设备」。
- 回收测试权限。重置下载密码、清理 IP 白名单、调整下载次数限制，避免内测入口变成长期敞口。
- 通知与交接。给测试用户明确的结束通知，说明后续走正式渠道，并把归档位置与版本清单同步给接手的人。
归档命名的几条约定
半年后找不到包，多半是命名混乱。下面几条成本很低但很管用：
- 统一格式，例如
项目名_平台_版本号_日期.apk，平台用android/ios区分。 - 版本号与包内字段一致：安卓侧对应
versionName与versionCode，iOS 侧对应CFBundleShortVersionString与CFBundleVersion。 - 目录按「项目 / 平台 / 版本」三级存放，最新交付版单独放
release目录并附简短说明。 - 随包保留校验值（如 MD5 或 SHA-256），使用前先校验，可判断文件是否在传输中被改动。
- 内测包不要放进公开网盘，归档位置要有明确访问权限。
建议：把六步做成一份项目收尾模板，每次验收后由负责分发的同事逐项打勾，比事后回忆可靠。分发环节可以继续用 虾分发 的合并下载与权限控制能力，但归档与记录一定要落到团队自己的存储里。
常见问题
| 问题 | 处理方式 |
|---|---|
| 二维码还能用，要主动关掉吗？ | 要。二维码不会自然失效，历史版本的入口建议在项目结束后停用或加访问限制 |
| 包已在平台，还要本地留一份吗？ | 要。平台是分发通道，归档责任在团队，账号变动时本地副本才是兜底 |
| 分发记录哪些字段值得留？ | 版本号、下载量与设备分布是核心，导出后写进测试报告方便回溯 |
| 证书状态变化后归档包还能装吗？ | 不一定。归档时应连证书与描述文件信息一起保存，并以 Apple 最新说明为准 |
小结
冻结交付版本、停用历史入口、归档包与证书信息、导出分发记录、回收测试权限、完成交接，六件事做齐，内测项目才算闭环。收尾做得好，下次有人问「上次那个包还能给我一份吗」，你只要打开归档目录，而不是翻遍聊天记录。