Docker Desktop本身不管理环境配置，真正起作用的是docker-compose.yml结合环境变量与多文件组合；单靠docker run -e无法支撑可靠多环境切换，因其难复现、不可维护、不安全且缺乏服务编排能力。
直接说结论：Docker Desktop 本身不管理“环境配置”，真正起作用的是 docker-compose.yml + 环境变量 + 多文件组合，docker run 命令无法支撑可靠多环境切换。
为什么不能只靠 docker run -e 指定环境变量？
单条 docker run 命令确实能传 -e NODE_ENV=development，但实际开发中会立刻遇到问题：
- 多个服务（如前端、后端、数据库）需要统一环境标识，手动拼几十个
-e易出错、不可复现 - 不同环境的端口映射、健康检查、资源限制（
mem_limit）、日志驱动都不同，硬编码在命令里没法维护 - 敏感配置（如数据库密码）不能写进命令行历史或脚本，得走外部文件加载
-
docker run启动的容器默认不自动重启、不建网络、不挂卷，每次都要补一堆参数
正确做法：用 docker-compose.yml 分离 dev/test/prod 配置
核心是把共性抽到基础文件，差异写进覆盖文件。推荐结构如下：
docker-compose.yml # 公共服务定义（镜像、网络、卷） docker-compose.dev.yml # 开发专用：热重载、host-mode 日志、暴露调试端口 docker-compose.test.yml # 测试专用：禁用 UI、启用覆盖率、连接 mock DB
启动时用 -f 指定组合：
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d
关键点：
- 所有
-f文件按顺序合并，后加载的文件覆盖前者的同名字段 -
docker-compose.yml里不要写environment，全交给.dev.yml或.test.yml控制 - 避免在
docker-compose.yml中使用build:，生产镜像应提前构建好再引用image:
环境变量怎么安全注入而不泄露？
别把密码写死在 YAML 里。正确路径是：
- 本地开发用
.env文件（gitignore 掉），内容如：DB_PASSWORD=mydevpass，docker-compose默认读取它 - 测试环境用
--env-file test.env显式指定，文件不进代码库 - 绝对禁止在
environment:下直接写DB_PASSWORD: "123"—— 这会出现在docker inspect输出里 - 如果必须动态生成（如 CI 中），用
export DB_PASSWORD=$(cat /run/secrets/db_pass)+docker-compose --env-file 组合
容易被忽略的磁盘和日志陷阱
开发和测试环境常因日志爆炸或 volume 污染导致 Docker Desktop 卡死甚至磁盘满：
- 开发时加
logging.driver: "json-file"并设logging.options.max-size="10m"，否则 Node.js 的 console.log 会无限写满C:\Users\XXX\AppData\Local\Docker - 测试环境禁用所有
volumes:挂载，改用tmpfs：volumes: ["/app/node_modules:tmpfs"]，避免 node_modules 被污染影响下次测试 - Windows 上 WSL2 的 ext4.vhdx 文件会持续膨胀，定期执行
wsl --shutdown && wsl --unregister docker-desktop-data（注意：清空所有镜像和容器）
最麻烦的其实是环境变量拼写错误和 compose 文件加载顺序——这两个问题不会报错，但会导致配置静默失效，查起来要翻三遍 docker-compose config 输出。
