必须用操作系统级凭据管理器（如systemd secrets、AWS Secrets Manager）注入环境变量，禁用硬编码和明文.env文件，确保MongoDB连接URI包含authSource=admin、tls=true、tlsCAFile、retryWrites=false等安全参数。
别把密码写死在代码里，也别用 .env 文件裸存明文凭据——这是生产环境最常见、最危险的两个错误。
为什么不能直接写在代码或 .env 里？
硬编码凭据一旦泄露（比如误提交 Git、日志打印、容器镜像残留），攻击者就能直连数据库；而 .env 文件本身不加密，权限配置不当（如被其他用户读取）或进程内存 dump 都可能暴露内容。MongoDB 的默认认证机制不防凭据泄露，只防未授权连接。
- 明文凭据可能被
process.env日志意外输出（尤其开启 debug 模式时） -
.env文件若未设chmod 600，同服务器其他用户可读 - Docker 构建时若 COPY
.env，它会留在镜像层中，docker history可提取
推荐方案：用操作系统级凭据管理器 + 运行时注入
Node.js 进程启动前，由系统凭据服务（如 Linux 的 systemd secrets、AWS Secrets Manager、HashiCorp Vault）注入环境变量，且仅对目标用户/服务可见。Node.js 代码只读取变量名，不接触原始值。
- Linux systemd 示例：在 service 文件中用
EnvironmentFile=/run/secrets/mongo_uri，配合systemd-creds或tmpfiles.d动态生成临时 secret 文件 - AWS ECS/Fargate：通过
secrets字段绑定 Secrets Manager ARN，自动注入为环境变量 - 本地开发替代：用
dotenv-safe+.env.example+.env.local（gitignored），但仅限非敏感环境
连接时直接使用：const client = new MongoClient(process.env.MONGODB_URI, { ... }) —— URI 中已含用户名、密码、认证库等，无需拆解拼接。
MONGODB_URI 必须包含哪些安全参数？
光有 username:password@host 不够。缺少关键参数会导致 TLS 被绕过、重试行为失控、或认证失败后静默降级。
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
-
authSource=admin：明确指定认证数据库（不是业务库），避免因用户创建在admin但驱动默认查test而失败 -
tls=true&tlsCAFile=/path/to/ca.pem：强制 TLS 且验证 CA，禁用tlsAllowInvalidCertificates=true（测试除外） -
retryWrites=false&w=majority：关闭自动重试写操作（防止重复提交），显式控制写关注 -
minPoolSize=3&maxPoolSize=10：避免连接数突增耗尽 DB 资源，尤其在突发流量下
示例安全 URI：mongodb://myuser:mypass@db.example.com:27017/mydb?authSource=admin&tls=true&tlsCAFile=/etc/tls/ca.pem&retryWrites=false&w=majority
容易被忽略的认证细节
很多团队配了密码却连不上，问题常出在认证机制和用户角色上，而不是连接字符串本身。
- MongoDB 6.0+ 默认启用 SCRAM-SHA-256 认证，旧客户端（如某些老版本 mongoose）需显式加
authMechanism=SCRAM-SHA-256 - 用户必须在
authSource指定的库中创建，例如db.createUser({user:"myuser", pwd:"...", roles:[{role:"readWrite", db:"mydb"}]}, {pwdPolicy: {enabled: true}}) - 如果用
mongodb+srv://，DNS SRV 记录必须返回带 TLS 的地址，且驱动版本 ≥ 4.0（否则忽略tls参数）
真正麻烦的不是“怎么连”，而是“连上之后，谁能在什么库上做什么”——角色粒度没控好，一个凭据泄露就等于全库沦陷。
