docker容器启动即崩溃且日志无明确报错，大概率是环境变量配置错误；需通过printenv验证变量是否传入、检查类型/转义/格式问题、确认加载优先级，并在代码中打印调试日志定位真实原因。
应用在 docker 容器中启动就崩溃，日志里却没明确报错？十有八九是环境变量没配对。这类问题不报红但致命——php-fpm 拒绝启动、node.js 进程秒退、dify 初始化失败，往往都卡在某个看似无关的 db_host 或 debug_mode 上。
先确认变量到底有没有进容器
别猜，直接看。哪怕容器一闪而过，也能用以下方式抓取真实环境：
- 如果容器还能短暂运行：执行
docker run --rm -it your-image printenv | grep -i "DB\|DEBUG\|PORT"，快速筛关键变量 - 若已崩溃退出：加
--entrypoint /bin/sh覆盖启动命令，进入后手动执行printenv，例如：docker run --rm -it --entrypoint /bin/sh your-image -c "printenv | grep DATABASE_URL" - 对 docker-compose 项目：先
docker-compose up -d，再docker-compose exec web printenv（把web换成你的服务名）
重点查这三类典型错误
90% 的崩溃源于以下配置疏漏，逐项核对：
-
值类型错位：PHP 或 Python 应用把
DEBUG=true当布尔处理，但 Docker 传进去的是字符串"true"；正确写法是- DEBUG="true"（带引号），或在代码里用filter_var($_ENV['DEBUG'], FILTER_VALIDATE_BOOLEAN)显式转换 -
敏感字符未转义：数据库密码含
$、{、}时，Shell 会提前展开。例如PASSWORD=abc$123实际变成PASSWORD=abc。解决方法：在.env文件里写成PASSWORD='abc$123'，或在docker-compose.yml中用双引号包裹：- PASSWORD="abc\$123" -
路径/URL 格式非法：比如
DATABASE_URL=mysql://user:pass@db/app缺少端口号，MySQL 默认端口 3306 不写可能被忽略；又或者REDIS_URL=redis://localhost:6379在容器内应指向服务名redis而非localhost
检查加载顺序和覆盖关系
Docker Compose 对同名变量有明确优先级，高优先级会静默覆盖低优先级，极易埋雷：
- 最高：命令行
docker-compose run -e DB_HOST=10.0.1.5 web - 其次：docker-compose.yml 中
environment:下定义的变量 - 再次：宿主机 Shell 环境变量（如
export DB_HOST=127.0.0.1） - 最低：项目根目录下的
.env文件
如果你在 .env 里写了 DB_HOST=db，又在 docker-compose.yml 里写了 - DB_HOST=localhost，那最终生效的是后者。用 docker-compose config 可输出最终解析结果，一眼看清哪些变量被谁覆盖。
验证应用是否真读到了变量
环境变量进了容器，不代表应用能正确获取。在代码里加一行调试输出：
- PHP：
error_log("DB_HOST = " . ($_ENV['DB_HOST'] ?? 'NOT_SET')); - Node.js：
console.log('DB_HOST:', process.env.DB_HOST || 'MISSING'); - Python：
import os; print('DB_HOST:', os.getenv('DB_HOST', 'MISSING'))
把这行加到应用入口文件最开头，启动后立刻查日志。如果输出 MISSING，说明变量根本没传进来；如果输出了值但应用仍崩，问题就在值的内容或类型上。
