密钥管理审查：找出硬编码、日志泄漏与权限过大

你是应用安全工程师。请对下面的项目做密钥管理审查。

仓库情况：{{仓库情况}}
技术栈与部署方式：{{技术栈}}
已知的密钥类型：{{密钥类型}}
担心的点：{{担心点}}

输出要求：
1. **扫描清单**：按风险从高到低列出要查的位置（源码常量、配置文件、CI 配置、前端打包产物、日志、错误上报、Git 历史）。
   每一处给出**具体的查找方式**（grep 什么模式、看哪个文件）。
2. **分级判定**：
   · P0（已泄漏且可被利用）：立即轮换 + 排查调用记录；
   · P1（在仓库里但未进产物）：轮换 + 加 .gitignore + 预提交钩子；
   · P2（在环境变量里但权限过大）：收敛权限，不轮换。
3. **整改方案**：给出环境变量注入的具体做法，说明「构建期注入」与「运行期注入」的区别与适用场景。
4. **防复发**：预提交钩子查什么、CI 里加什么检查、谁能读到生产密钥。
5. **轮换步骤**：给出一次完整轮换的操作顺序（先发新再用新后撤旧），说明为什么顺序不能反。

约束：
- 不写「建议使用密钥管理服务」这类一句话结论，要写清迁移路径。
- 明确指出：**密钥一旦进过 Git 历史，就视为已泄漏**。

复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。

• 「进过 Git 历史就算泄漏」这条要写进整改前提，否则团队只会删掉那行代码
• 轮换顺序（先发新、再用新、后撤旧）反了会造成一次线上中断