SQL注入防护需组合参数化查询、动态凭证获取、最小权限和连接池隔离；凭证须从环境变量或K8s Secret注入，轮换时需新旧并存、滚动重启、设置maxLifetime确保旧连接超时失效。

SQL注入防护不能只靠参数化查询 应用层的 prepareStatement 或 query 参数绑定只能防住拼接 SQL 的漏洞，但部署侧如果用硬编码凭证、静态连接字符串或未隔离的环境配置，攻击者一旦拿下应用服务器，就能直接连库执行任意语句。轮换凭证本身不防注入，但它能切断“一次得手、长期有效”的攻击链。

真正起作用的是组合动作：参数化 + 凭证动态获取 + 权限最小化 + 连接池隔离。

数据库连接凭证必须从运行时环境注入，而非打包进代码 常见错误是把 DB_USER、DB_PASSWORD 写死在 application.properties 或 config.yml 里，甚至提交到 Git —— 这让轮换变成改代码、发版、重启，根本做不到“定期”。

• Java 应用应通过 JDBC_URL + DB_USER/DB_PASSWORD 环境变量加载，Spring Boot 默认支持；不要用 spring.datasource.username 配置项硬编码
• Node.js 用 process.env.DB_PASSWORD，绝不用 require('./config/db.json')
• Kubernetes 场景下，凭证必须走 Secret 挂载为文件或环境变量，且 Secret 名称和挂载路径要与应用启动逻辑解耦
• 避免用 .env 文件——它容易被误提交，也不支持密钥轮换时的原子切换

轮换凭证时，必须容忍新旧凭据并存窗口期 数据库不支持“原子切换密码”，ALTER USER ... IDENTIFIED BY 执行后旧密码立刻失效。若应用未重启或连接池未刷新，会批量报错 Access denied for user。

安全轮换的实操要点：

• 先在 DB 创建新用户（如 app_prod_v2），赋最小权限（只给必要表的 SELECT/INSERT/UPDATE）
• 更新环境变量 / Secret，滚动重启应用（K8s 用 rollingUpdate，避免全量中断）
• 确认新连接全部建立、旧连接自然超时断开（连接池 maxLifetime 建议设为 10–30 分钟）
• 等 24 小时无旧用户登录日志后，再删旧用户

跳过并存期等于制造可用性事故。

连接池配置不当会让轮换失效 很多团队轮换了凭证，但应用仍连着旧连接——因为连接池复用已建连，根本不读新环境变量。

关键参数检查：

• HikariCP：dataSourceProperties 必须设 password= 动态值，不能设在 jdbcUrl 里（如 jdbc:mysql://x/y?user=a&password=b 是反模式）
• Druid：initConnectionSqls 不能含认证相关语句；testOnBorrow 要开，但更推荐 validationQuery=SELECT 1 + testWhileIdle
• 所有池都需设 maxLifetime（建议 ≤ 30min），否则连接可能活过凭证有效期

没设 maxLifetime 的连接池，等于把旧密码缓存在内存里，轮换只是掩耳盗铃。

轮换不是定时任务跑个脚本，本质是验证“应用能否在不重启进程的前提下，用新凭据建新连、弃旧连”——这个能力比密码复杂度重要得多。