数据库密码严禁硬编码或明文存于.git可见文件，应通过环境变量+密钥管理服务（如vault）注入，doctrine仅用database_url统一配置并强制使用%env(resolve:db_password)%解析，配合最小权限与运行时校验。
数据库密码不能硬编码在配置文件里，也不能明文写进 .env 后直接提交到 Git —— 这是绝大多数线上事故的起点。
为什么不能把 DB_PASSWORD 写死在 .env 里？
因为 .env 文件极易被意外提交、日志泄露、或通过错误配置的 Web 服务器（如未禁用 .env 目录索引）直接暴露。哪怕加了 .gitignore，开发人员仍可能本地调试时误传、CI/CD 流水线错误读取、或容器镜像层残留。
- 不要用
DB_PASSWORD=mysupersecret123这种形式存入版本控制可见的文件 - 避免在
config/packages/doctrine.yaml中直接引用%env(DB_PASSWORD)%而不做保护 - 不建议依赖“靠运维保密”的做法——密钥管理必须由机制保障，而非信任人
正确做法：用环境变量 + 密钥管理服务（或 Vault）
Symfony 默认支持 %env()% 表达式，但关键在于“谁来提供这个环境变量”，而不是“怎么读它”。安全链条的薄弱点永远在注入源头。
- 生产环境必须通过操作系统级环境变量注入（如 systemd service 的
Environment=、K8s Secret 挂载为 env、Docker--env-file配合 secret mount） - 禁止在 CI/CD 脚本中 echo 或 set -x 输出含
DB_PASSWORD的命令行 - 若使用 HashiCorp Vault、AWS Secrets Manager 或 Azure Key Vault，应通过官方 SDK 在应用启动前解密并注入环境变量，而不是让 Symfony 自己去调 API（那会把访问密钥也暴露在代码里）
- 本地开发可用
symfony secrets:set DATABASE_URL（Symfony 5.4+），它加密后存于config/secrets/prod/，且仅限 CLI 环境解密，比.env.local更可控
Doctrine 配置里怎么写才不踩坑？
Doctrine 的 DATABASE_URL 是唯一推荐入口，它把用户、密码、host、db name 封装成一个 URI。Symfony 官方组件会自动解析，避免手动拼接导致的 SQL 注入或转义遗漏。
- ✅ 正确：
DATABASE_URL=pgsql://user:%env(resolve:DB_PASSWORD)@10.0.2.5:5432/myapp，配合外部注入DB_PASSWORD - ❌ 错误：
doctrine.dbal.url: 'mysql://root:password@localhost/app'—— 字符串字面量绕过所有 env 解析机制 - ⚠️ 注意：
%env(resolve:DB_PASSWORD)%中的resolve:是必须的，否则 Symfony 不会尝试解密或替换；普通%env(DB_PASSWORD)%在未设置时会原样保留，导致连接失败但错误信息模糊 - 敏感字段（如密码）必须用
resolve:或file:（读取文件内容）这类处理器，不能裸用default:回退值
额外防线：运行时校验与最小权限
即使密码来源可信，也要防止配置错误放大风险。
- 数据库账号必须只授予应用所需的最小权限（例如不给
DROP TABLE、CREATE USER），禁用 superuser 权限 - 在
Kernel::boot()或命令启动时，可轻量验证连接是否能建立（非全量查询），失败立即 halt，避免带病运行 - 日志中绝对禁止输出
DATABASE_URL或任何含密码的字符串 —— 即使是 debug 模式，Symfony 的默认doctrine:database:create命令也不会打印密码，但自定义命令要主动过滤 - 若使用 Doctrine 的
url参数，确保parse_url()提取密码后不被记录：Symfony 内部已处理，但自定义连接逻辑需自行 scrub
最常被忽略的一点：密码轮换后，旧密钥可能还残留在旧部署的进程内存、容器镜像缓存、或未清理的临时文件中。自动化部署流程里，必须包含强制重启服务、清空 OPcache、并验证新凭据生效的检查点。
