docker-compose未配置env_file时.env变量未注入Node服务问题排查

一、你确实误解了docker-compose的默认.env加载规则 #

这是最核心的认知误区：

• docker-compose在执行命令的工作目录默认读取的.env文件，作用仅为替换docker-compose.yml内部的${XXX}模板变量，或是给compose CLI本身提供配置，不会自动将其键值对注入到容器内部的运行时环境。
• 举个实际场景：如果你的docker-compose.yml写了ports: "${HOST_PORT}:3000"，这个默认.env里的HOST_PORT才会被用来替换宿主机端口，但容器内运行的Node.js进程的process.env是完全读不到这个值的。
• 如果要把.env文件的内容传递给容器内的进程，必须在对应service下显式配置env_file: .env，或是写environment:字段，这才会把变量注入到容器的运行时环境，也就是你修改配置后能正常获取变量的原因。

二、为什么同步打印undefined，异步/TypeORM执行后就能拿到？ #

这个是TypeORM的隐含默认行为 + Node.js的事件循环执行逻辑共同导致的：

• Node.js本身不会主动解析项目里的.env文件，除非你显式引入dotenv依赖手动加载，或是项目里的其他依赖帮你做了这件事。
• 你没配置docker-compose的env_file时，容器启动时本来没有预注入API_URL变量，但TypeORM在执行createConnection()的初始化过程中，默认会自动解析项目根目录的.env文件，把里面的键值对挂载到全局的process.env对象上。
• 你最开头的同步console.log(process.env.API_URL)是在模块加载阶段就立即执行的，这时候TypeORM的初始化逻辑还没运行，自然读不到刚被加载的变量，所以输出undefined。
• createConnection()本身是异步函数，调用后会立即返回Promise，它内部的.env解析、数据库连接逻辑都会被放到微任务队列中，等当前所有同步代码执行完毕后才会运行。如果你把打印逻辑放在异步函数里、或是createConnection()执行之后，等到异步打印逻辑被事件循环调度执行时，TypeORM的初始化（包括.env挂载）已经完成，process.env上已经存在API_URL，所以能正常输出对应值。

正确的使用建议 #

• 不要依赖TypeORM这类第三方依赖的隐含.env加载逻辑，避免出现变量加载时序不可控的问题。
• 开发场景下如果要读取本地.env文件，建议在项目入口文件最开头手动引入dotenv：在import其他业务依赖之前加import 'dotenv/config'，保证环境变量在所有业务逻辑执行前就完成挂载。
• 容器场景下统一使用docker-compose的env_file配置注入环境变量，不要把.env文件读取的逻辑丢给业务依赖处理。

内容的提问来源于stack exchange，提问作者mbesson