凌晨一点，他在一块 2019 年的旧移动硬盘里翻 .jks 文件。翻到第三块才想起来，那台装着密钥的笔记本，去年搬家的时候被他当废品卖了。
电话里他问的还是同一句：能不能换个签名，把新版本推上去。
我说不能。不是我不想帮，是这件事从技术上就没有「换」这个动作。
先把签名这层说清楚
APK 的签名证书，是应用的身份。包名是名字，签名是身份证。
你发布一个新版本，系统会拿它的签名，和手机上已经装着的那一份去比。比得上，才允许覆盖安装；比不上，一律拒掉。多数手机到这一步只给一句「应用未安装」，连原因都不说。
所以用户那边看到的现象，通常不是「签名不一致」。他会说：更新失败了，点开还是老版本，卸载重装就能用。这句话听着像解决了，其实没有。
重新生成一份，为什么不行
有人会想：公司名一样，包名一样，参数照着抄，重新生成一份不就得了。
不行。证书里带的是一对在生成那一刻才有的密钥。就算你把所有参数都抄得一模一样，它也是一份全新的东西，指纹完全不同。系统只认原来那一份，认不出这是「同一个人」。
这事有点像配钥匙。原钥匙能开门，照着它的样子再配一把，也能开。可要是原钥匙丢了，你凭记忆去配，配出来的是另一把，插进锁里转不动。
两条路，代价差得远
方案一，把原来那份找回来。这是唯一不用付代价的路。
下面这些地方，是按常见情况列的示例，不是哪一位客户的原话。
打包机。很多人签名的文件就放在打包用的那台电脑上，从来没往外导过。
CI 的配置文件。流水线跑过，密钥多半以某种形式存在仓库的变量里。
同事的电脑。组里最早打包的那个人，他的桌面可能还留着当年那一整个文件夹。
网盘和邮件附件。给外包、给测试发过的包，附件里往往躺着一份。
旧的项目备份。移动硬盘、U 盘、云盘的历史版本，都值得翻。
找回来之后，第一件事不是打包，是记指纹。把证书的 SHA-1 或者 MD5 抄下来，以后每次打包前对一遍，对上了再传。做 App 备案的时候也要交这串东西，拿 .jks 加密码，在 https://www.chuxueyun.com/pages/appmd5 传上去就能读出来。
方案二，找不到，换包名重发。
这条路走得通，但它等于把这款应用重开一次。老用户收不到更新，只能重新下载一个新应用；商店里的安装量、评分、评论，全部从零开始；投过广告的，落地页上的包名也得跟着改。
如果你现在正在算这笔账，先问自己一句：这款应用上线到现在攒下来的东西，值不值得再攒一遍。
后台能不能直接改签名
这是第二个几乎每次都会被问到的问题。
各家商店的规则不一样。有的接受申诉，要你提供一堆证明材料；有的直接让你重新提交，连申诉入口都不给。这件事没有统一答案，别猜，去问。问清楚之前，先别在后台点「更新」，点下去状态就变了，回不来。
现在就能做的四件事
把 .jks 文件和密码分开存。文件放一个地方，密码放另一个地方。别学他，把密码写在文件名里，那等于没设密码。
至少留三份，而且别三份都搁在同一个网盘账号里。同一个账号里放三份，等于只有一份。
别名、库密码、密钥密码，这三样记全。少一样，文件就是块砖。
打包前跑一遍指纹比对。这一步花不了一分钟，能省掉后面好几天的来回。
最后
那天晚上他翻到四点多，最后在一块贴着「旧项目」标签的硬盘里找到了。文件很小，几十 KB，比一张照片还小。
他发消息说，找到了。我没回「太好了」，我回的是：现在就复制两份，一份放老家。
这话听着像玩笑。可签名这东西，本质上就是「只有一份」的东西。所有只有一份的东西，早晚会丢。
我们做安卓这边，上架前会按 15 大项、40+ 小项过一遍。包本身是其中一块，签名和包名对不对得上，是打开包第一眼就能看出来的事。资料齐了再启动，几个市场一起走，省得你在几个后台之间来回切。
要是你手上的签名已经对不上了，先把还能找到的那份发过来看看。入口在 https://www.chuxueyun.com/android 。