abt-app 仓库里，而且不能简单换掉（换了老用户装不上新版本）。abt-app/cordova/hzab_abt.jks、hzab_abt_debug.jks、ldkj_dbt.jks、ldkj_dbt_test.jks、abt-app/build-utils/Android/；还有 build-utils/private/private.key + private.pem
为什么危险：拿到签名密钥的人可以签一个"同包名高版本"的假 APP，老用户能直接被覆盖升级。
注意：签名密钥一旦正式发过版本就不能直接轮换——换了以后已安装的用户更新会报签名不一致，只能卸载重装。
建议：① 密钥保留但**移出仓库**，改成构建机上的私密文件/密钥库注入；② 仓库历史里的这几个文件做一次彻底清理（含历史提交）；③ 确认这些 .jks 的密码没写在同一仓库里。
application-dev.yml / application-prod.yml / application.yml；两个 Bucket（abt2023-open 公开、abt2023-self 私有），还带 CDN 鉴权密钥为什么危险：AK/SK 能读写整个 OSS 桶，而且测试生产共用——测试环境的泄露等于生产泄露。
建议：新建一对专用 AK，只授这两个桶的最小权限；旧 AK 直接禁用；测试和生产拆成两对。配置改成从环境变量/密钥管理读取，不再写进仓库。
application-dev.yml / -prod.yml / application.yml（含 Druid 控制台弱口令 abjt/123456）为什么危险：这些库里有全公司的人事数据。
建议：逐个改口令；测试库和生产库不能共用一个账号（现在是共用的）；Druid 控制台在测试/生产关掉或换强口令。
和我们有关：我现在连测试库导结构用的就是仓库里这套口令。你轮转后，本地和团队都要换新口令。
为什么危险：能发短信 = 能刷你的短信费，也可能被用来发诈骗短信。
建议：控制台重置 AppSecret，加发送限额和告警。
application-dev.yml（eventBus.token / scoreToken / historyToken / inviteToken、userChangePhone.token）为什么危险：能往你的事件总线里灌数据。
建议：重新生成 webhook 地址 + token；这批看起来是一次性配的，换掉影响面小。
abt-server/settings.xmlabt-server/settings.xml（<username> + <password>，仓库 id 2185959-release-jzJm0N）为什么还有它：主服务依赖两个定制包 abt-flowlong-*，只能从这个私服拉。
建议：改用云效**访问令牌**替代账号口令；轮转前先确认团队本地已经有可用的新凭据（否则构建会断）。
· 人脸/识别服务里还有一处 masterSecret + secret（identify、user 两个仓）。
· 前端两个仓（APP / PC）除了 APP 签名密钥外，没有发现放进仓库的密钥；接口地址是公开域名，不算凭据。
· 根子上的建议：这些值以后统一走环境变量或密钥管理，配置模板里只留占位符——不然轮转一次，仓库里又会躺一遍。