容器内通过 process.env 读取环境变量本身不自动“安全”，关键在于变量如何进入容器、是否被校验、是否含敏感明文；node.js 仅暴露进程已有环境变量，不负责过滤或加密。
容器内通过 process.env 读取环境变量本身不自动“安全”，关键在于变量如何进入容器、是否被校验、是否含敏感明文——Node.js 只负责暴露已存在的进程环境，不负责过滤或加密。
确保变量已正确注入容器
宿主机的环境变量默认对容器不可见。必须显式传入：
- 用
docker run -e DB_HOST=192.168.1.100 -e NODE_ENV=production单个注入 - 用
--env-file ./prod.env批量导入（推荐，避免命令行泄露） - 在
docker-compose.yml中通过environment或env_file字段声明
注入后，可在容器内执行 printenv | grep DB_HOST 验证是否生效。若 process.env.DB_HOST 仍为 undefined，说明变量根本没进容器，不是 Node.js 读取问题。
在代码中安全访问 process.env
不要直接使用 process.env.SECRET_KEY，应做存在性、格式和最小权限检查：
- 先判断是否定义：
if (!process.env.DB_PASSWORD) throw new Error('DB_PASSWORD is required') - 避免日志打印敏感字段：
console.log(`Connected to ${process.env.DB_HOST}`)✅，但console.log(process.env)❌ - 对值做基本校验，如非空、长度、格式（例如 JWT_SECRET 至少 32 字符）
生产环境不依赖 .env 文件
dotenv 库只适合开发。生产中应禁用 require('dotenv').config()，改用系统级环境变量：
- Docker Compose 的
environment或env_file已足够 - 禁止挂载
.env文件到生产容器（易权限失控、误提交、被 Web 服务意外暴露） - 敏感值（如数据库密码）应由 Secrets 管理工具提供，再由启动脚本注入进程环境
避免常见陷阱
这些看似细微的问题常导致“读不到”或“不安全”：
-
process.env键名是大写的，process.env.node_env永远是undefined - 变量值含空格或特殊字符时，
export KEY="val with space"必须加引号；.env文件中KEY=val with space是非法的，应写成KEY="val with space" - PHP-FPM、Nginx 等中间件可能拦截或未透传环境变量，需额外配置（如
env[DB_HOST] = $DB_HOST）
