多模块项目中 Keystore 管理的核心痛点

说实话，我在很多团队里见过这样的场景：项目初期就一个 App 模块，Keystore 文件往项目根目录一扔，密码写在 gradle.properties 里，大家都很省心。但一旦拆成多个模块——比如基础库、功能 A、功能 B、以及壳工程——问题就接二连踵来了。

我记得有一次接手一个老项目，光是找到所有模块用到的签名配置就花了一整天。有的模块用 debug 签名，有的用 release，还有的直接硬编码了密码……嗯，那场面，你想象一下。

痛点一：密码碎片化 —— 每个模块各自为政

多模块项目很容易出现「一个模块一个密码」的乱象。A 模块用了 storePassword 是 "android"，B 模块又改成 "android123"，C 模块干脆写在 Java 源码里。为什么会这样？因为初期没人规定统一的管理规范。

场景	典型表现	风险等级
模块间密码不统一	每个模块的 build.gradle 直接写死密码	🔴 高
密码存本地但未忽略	gradle.properties 未加入 .gitignore	🔴 高
开发与发布密码混淆	debug 和 release 共用同一套	🟡 中

痛点二：配置泄露风险 —— 代码仓库成了「密码本」

很多团队直接把 keystore 文件、密码、alias 放到项目仓库里。哪怕设置了 .gitignore，也保不齐有人一时手快提交上去。我见过最夸张的：一个公司的 release 密码就写在 README 的“注意事项”里，原因是“方便队友”。

• 源码泄露：仓库一旦公开或被克隆，签名信息完全暴露
• 历史记录残留：即使后来删掉文件，Git 历史里依然可查
• 内部威胁：离职员工可能持有仓库克隆副本

痛点三：构建不一致 —— 「在我电脑上能跑」

多模块项目最大的噩梦之一：A 模块在本地能签名通过，CI 上却报错。原因往往是模块依赖的签名配置路径不同。比如本地用的是相对路径 ../keystore/release.keystore，而 CI 的 working directory 不同，导致找不到文件。

// 常见错误写法：硬编码路径
signingConfigs {
    release {
        storeFile file('/Users/me/project/keystore/release.keystore')
        storePassword '123456'
        keyAlias 'mykey'
    }
}

正确的做法是让路径和密码都变成可配置的变量。嗯，这里要注意：变量本身也得安全传递，不能直接写死。

痛点四：权限混乱 —— 谁该拥有签名权？

在多模块项目中，签名配置经常会复制粘贴到每个子模块的 build.gradle 里。结果就是：每个模块都具备完整的签名能力。你想想看，如果某个基础库的开发者不小心改错了密码，整个 release 构建链都会受影响。

• 过度授权：非核心模块拿到 release 签名权限
• 权限模糊：没人清楚哪些模块真的需要签名
• 管理盲区：新增模块时自动继承了老配置，容易漏掉安全审查

痛点五：版本同步困难 —— 换签名如打仗

当 keystore 过期或需要更换时，多模块的痛感会放大。我记得有个项目需要更换上传 Google Play 的签名证书——因为原来的密钥泄露了。结果我们花了三天找齐所有模块中引用的旧密码，并逐一更新 CI 配置。那三天，团队几乎什么事都干不了。

为什么会这么难？因为每个模块都可能引用签名配置，而且引用方式五花八门：有的在 gradle.properties，有的在环境变量，有的在 Jenkins 的构建参数里。

总结：这些痛点其实是「管理缺失」的投影

上面五个痛点——密码碎片化、配置泄露、构建不一致、权限混乱、版本同步困难——表面上互不相干，但根因其实就一个：缺乏统一的 Keystore 管理策略。我在不同公司、不同项目里都见过类似的影子，解决起来也不复杂：

• 用 CI 环境变量或安全服务统一管理密码
• 只在壳工程定义签名配置，子库通过 consumerProguardFiles 等机制解耦
• 所有签名的敏感文件严格执行 .gitignore + 定期审计
• 建立模块签名权限白名单，新增模块必须审批