换人发版不用改密码：上传环节不持有长期密钥的交接清单

一句话定义：当上传这一步不持有任何长期密钥、也不接管签名材料时，人员变动只需要处理「谁能提交审核」这一层的授权，账号主密码、发布证书与描述文件都不必轮换——交接成本由凭证边界决定，而不是由流程文档的长度决定。

一、交接时真正会出问题的东西

多数团队的交接之所以要「改一圈密码」，根因不是 Apple 要求，而是长期密钥散落在了每个环节：构建机有一份、CI 有一份、上传工具里还存了一份。任何一处人员变动，都要假设所有副本都可能外泄。

二、Apple 对第三方共享密钥的建议

WWDC26 的 App Store Connect Group Lab 里，Apple 工程师给出的口径很明确：不要把 API key 硬编码进仓库或随客户端分发；API key 只应存在于服务端，永不内嵌进上架的 App；这些 key 不会过期，因此要谨慎对待；遵循最小权限，团队 key 选能完成任务的最低角色；尤其要小心与第三方服务共享的密钥——停止使用就吊销、严格收紧权限、不要过度分享。同一场答疑还说明，通用团队 key 无法按单个 App 收窄范围，需要收窄时改用继承该用户权限的个人密钥。

把「不会过期」和「用完即吊销」放在一起看，结论是：长期密钥应尽量只存在于一个可审计的位置，而不是随每个发版环节复制。上传动作本身是一次交付，不需要一份永不过期的账号级凭据。

三、按顺序做一次低扰动交接

1. 先画凭证分布图：列出账号主密码、p12、.p8、专用密码分别在哪台机器、哪个 secret、哪个工具配置里，标注创建人与最近使用时间。
2. 区分构建段与交付段：确认上传环节的输入是否只有 IPA 与一次上传授权；如果工具配置里还存着证书或长期密钥，先把它挪回构建段或服务端。
3. 只轮换提审层授权：人员变动影响的是「谁能改元数据、选构建、提交审核」，按角色撤销对应密钥或调整 App Store Connect 用户权限即可。
4. 单独处理专用密码：为新的交互式工具重新生成一串，旧的立即撤销；这一步不影响其它专用密码，也不影响账号主密码。
5. 复查异常记录：核对账号下活跃密钥、证书与近期上传记录，确认没有来路不明的构建；把本次核对日期与负责人写进台账。
6. 把边界写进发布规范：明确「上传段不存放长期密钥」，后续新增工具时按这条准入条件筛选。

这类只做传输、不接触签名材料的工具，交接时既不涉及证书轮换，也不涉及账号改密；需要处理的只剩交付授权本身的撤销与重建。

四、常见问答

Q：不改主密码，旧同事还能登录吗？ A：账号级访问由 App Store Connect 的用户与角色控制，撤销其用户权限即可，与是否改主密码是两件事。主密码属于账号持有人，通常不随人员流动变更。

Q：证书要不要跟着轮换？ A：只有当 p12 曾被离职人员单独持有、且无法确认副本已清除时才需要。若签名材料始终留在受控构建机，交接不触及签名体系。

Q：API 密钥不会过期，是不是意味着必须定期换？ A：Apple 的建议是「停止使用就吊销」并严格收紧权限，不是按固定周期无差别轮换。关键是台账能回答「这把 key 谁在用、用在哪、何时该撤销」。

Q：上传工具里存了专用密码，算长期密钥吗？ A：专用密码是可单独撤销的授权串，影响面限于上传。它与不会过期的 .p8 不同；交接时按需撤销重建，成本远低于轮换账号级密钥。

本文要点

• 交接要「改一圈密码」的根因是长期密钥散落在每个环节，不是 Apple 的强制要求。
• WWDC26 官方建议：key 只在服务端、不进仓库与客户端、不会过期、用完即吊销、按最低角色收窄。
• 低扰动交接六步：画分布图、区分构建与交付、只轮换提审层、单独重建专用密码、复查上传记录、把边界写进规范。
• 账号级访问靠用户与角色权限撤销，通常无需改主密码；证书只在确认外泄时才轮换。
• 上传段不持有长期密钥时，人员变动不触及签名体系与账号凭据。