最安全的做法是环境变量仅作引用器，敏感数据由专用系统托管并按需注入；支持_file机制的镜像从挂载文件读密钥；分层env文件+权限控制；构建阶段禁用敏感信息；运行时验证与日志脱敏。
直接把密码、密钥写进 .env 或 docker-compose.yml 是最常见也最危险的做法。真正安全的配合方式，是让环境变量只做“引用器”，不存“真值”——敏感数据由专用系统托管，容器启动时按需注入。
用 _FILE 后缀机制从文件读取密钥
很多官方镜像（如 Zabbix、PostgreSQL、Redis）原生支持 _FILE 结尾的环境变量。它不会把密码明文传入容器，而是让应用从挂载的文件中读取内容：
- 在
docker-compose.yml中写：ZBX_DBPASSWORD_FILE=/run/secrets/db_password - 通过
secrets或bind mount把密钥文件挂进容器指定路径 - 应用内部调用
file_env()类函数自动加载，避免内存中暴露原始字符串
拆分 env 文件 + 严格权限控制
把配置按敏感程度分层，再用操作系统级权限锁死访问范围：
- 保留
.env.common存通用配置（如服务端口、日志级别），可提交 Git - 新建
.env.production存数据库密码、API 密钥，加进.gitignore - 运行前执行：
chmod 600 .env.production && chown $USER:$USER .env.production - 在
docker-compose.yml中按需加载：env_file: [.env.common, .env.${ENV_NAME}]
禁止环境变量进入镜像构建过程
构建阶段（Dockerfile）绝不能 COPY 或 ENV 敏感信息，否则会固化到镜像层，无法清理：
- 删除所有
COPY config/ .或ENV DB_PASSWORD=xxx这类语句 - 用多阶段构建：构建阶段只装依赖、编译代码；运行阶段只复制二进制和配置模板，不带任何源码或密钥
- 在
.dockerignore中明确排除：*.env*、config/**、secrets/**
运行时验证 + 日志脱敏
即使配置正确，运行时疏忽仍可能泄露。必须在应用启动逻辑中主动防御：
- 入口脚本检查关键变量是否为空：
if [ -z "$DB_PASSWORD" ]; then echo "MISSING DB_PASSWORD" >&2; exit 1; fi - 禁用调试模式输出环境变量：
printenv、os.environ等调用必须屏蔽或过滤敏感键名（如PASSWORD、KEY、TOKEN） - 使用结构化日志（如 JSON 格式），对日志字段自动脱敏，而非依赖人工
console.log控制
