这两年我经手维护的项目里环境管理方案出现了很明显的分化老一点的仓库还靠一串 Shell 脚本打天下新一点的项目基本都切到了 Docker Compose。两种方案我都在实际项目里深度用过也分别踩过不少坑。今天不站队说谁一定更好而是把选型时真正需要考虑的因素拆开讲清楚——什么时候该继续用脚本什么时候上 Compose 更划算以及两者怎么配合使用而不是非要二选一。1. 先搞清楚环境管理到底在管什么1.1 配置漂移才是真正的敌人聊方案之前得先定义问题。我们说的环境管理本质上是在对抗一个东西配置漂移。同一个项目三个月前装好的依赖、半年前设过的环境变量、某台机器上手工改过的系统配置都会让环境一点点偏离标准状态。等到某天新同事加入照着文档从头搭一遍环境发现根本跑不起来这时候你才意识到团队其实从来没有一份真正可信的环境说明。我见过最典型的场景是这样的某同学的开发机上一切正常代码切到另一个人手里就起不来折腾半天发现是 Python 版本差了 0.1、某个系统库没装、某个环境变量没 export。这些细碎差异单看都不严重叠在一起就是一整天的排查时间。环境管理方案要解决的不是怎么装依赖而是怎么让每台机器上的环境都收敛到同一个状态。1.2 方案谱系文档、脚本、容器围绕这个目标常见做法可以放在一条谱系上手工文档环境全靠 README 描述。成本最低但文档天然滞后写的人默认读者和自己有相同的机器和习惯。Shell 脚本把安装步骤固化成可执行文件。比文档进了一步但脚本本身依然依赖宿主机的各种前提条件。容器化编排Docker Compose把整个环境要素——系统库、运行时、依赖、服务编排——全部刻画成声明式配置。环境不再安装到机器上而是被描述出来每次从镜像重建。这三个层级不是谁替代谁的关系。脚本可以内嵌在 Compose 方案里做辅助Compose 也可以反过来被脚本调用。理解这条谱系后面选型才不会钻牛角尖。2. Shell 脚本方案轻量、直接但容易假成功2.1 脚本真正擅长的场景Shell 脚本不是原罪。它最大的优势是零额外依赖——任何一台 Unix 系的机器天然有 bash你不必先安装 Docker 才能安装别的工具。所以下面这些场景我至今仍然推荐用脚本项目只有一两个外部依赖比如装个 Python 3.11 pip 安装 requirements.txt。团队规模很小机器类型高度统一比如全员标配同版本 macOS。操作本身是一次性的比如从 Git 仓库拉代码后做初始化。你只是想封装几个本地命令减少敲键盘的次数。这类脚本最怕写复杂。我见过最好的一个轻量脚本其实只有 15 行做的事情就是检查 pyenv、安装固定 Python 版本、创建虚拟环境、装依赖。它长这样#!/usr/bin/env bash set -euo pipefail PYTHON_VERSION${PYTHON_VERSION:-3.11} if ! command -v pyenv /dev/null 21; then echo 请先安装 pyenv: https://github.com/pyenv/pyenv exit 1 fi pyenv install -s $PYTHON_VERSION pyenv local $PYTHON_VERSION python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install -r requirements.txt echo 环境初始化完成运行: source .venv/bin/activate这个脚本值得注意的细节是set -euo pipefail和前置检查。前者保证任何一步失败就立刻终止不会给你看起来成功的错觉后者让脚本在缺工具时直接报错而不是继续跑出更诡异的故障。很多人写环境脚本不写这两行等到出错时才发现脚本已经带着残缺状态跑了半天。2.2 那些看起来成功的失败Shell 脚本方案最大的坑是它经常静默产生偏离而不是报错。我列几个实战里反复遇到的解释器差异脚本第一行写#!/bin/sh还是#!/usr/bin/env bash行为完全不同。某些系统里sh是dash不支持数组、source、[[ ]]脚本照样能跑但跑出来的结果就是不对。非交互 Shell 不加载 rc 文件新开一个终端跑脚本nvm、pyenv、rbenv这些版本管理器经常处于未激活状态command -v node找不到。问题不在脚本本身而在脚本假设了一个已经初始化好的交互环境。GNU 工具和 BSD 工具的差异sed -i在 Linux 和 macOS 上的参数格式不同date、ls的输出格式也五花八门。一个为 Ubuntu 写的脚本放到 macOS 上可能每个命令都有一点点不同。包管理器分裂apt、yum、brew 各有各的写法。脚本为了兼容几个平台往往演变成一堆if分支每个分支还只能尽力而为。这些坑的共同特点是脚本执行完没报错但环境并没有按预期收敛。等新同事跑完脚本说装好了实际一编译才发现缺了头文件。脚本方案的本质是把文档的可执行化它继承了文档的一个毛病无法验证结果。2.3 维护成本随人数线性上涨如果团队只有一个人脚本方案可以长期运转得很好。但到三五个人的时候机器的多样性开始侵蚀你最初的那份干净脚本。Windows 同事要装 WSL 才能跑 bash某台旧机器系统库版本太老新版本工具链不再支持……我统计过自己维护过的一个中等规模项目从最初 30 行安装脚本到后来兼容各种分支、各种检查膨胀到将近 400 行期间还不断有人给 README 补充如果遇到 XX 错误请手动执行 YY的附录。这个状态非常典型——脚本方案的成本不是写出来的是长出来的。每多一台新机器、一个新成员就等于多一份需要调试的边界条件。3. Docker Compose把环境本身变成可复现的描述3.1 环境即代码换个角度看问题Docker Compose 的核心理念和脚本截然不同。脚本关心的是怎么把环境装到这台机器上Compose 关心的是用一段声明把环境精确描述出来再用同一段声明在任意机器上重建。拿上面的 Python 项目举例用 Compose 之后你会发现你不再需要关心宿主机上装没装 Python、pyenv 版本是多少、系统库缺不缺。Dockerfile 里写清楚基础镜像和依赖Compose 文件里写清楚有哪些服务、它们之间怎么连接剩下的交给容器运行时去处理。这就是所谓的环境即代码——环境配置进入版本库跟着代码一起走天然可审计、可回滚。3.2 一个典型 Compose 文件拆解真实项目里Compose 的价值在多个服务协作时才充分体现。比如一个 Web 应用通常需要数据库、缓存和业务服务三个角色Compose 文件可以这样写services: postgres: image: postgres:16-alpine environment: POSTGRES_DB: app_dev POSTGRES_USER: app POSTGRES_PASSWORD: dev_password ports: - 5432:5432 volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U app] interval: 5s timeout: 3s retries: 5 redis: image: redis:7-alpine ports: - 6379:6379 app: build: . depends_on: postgres: condition: service_healthy redis: condition: service_started environment: DATABASE_URL: postgresql://app:dev_passwordpostgres/app_dev REDIS_URL: redis://redis:6379/0 ports: - 8080:8080 volumes: - .:/app volumes: pgdata:几个关键点我重点解释一下depends_on配合condition才是正确的启动顺序控制。很多新手只写depends_on,结果数据库容器虽然启动了但内部还没准备好接受连接应用照样连不上。加上healthcheck和service_healthyCompose 会等数据库真正就绪后才启动应用这才是声明式编排的价值。数据卷必须显式声明。数据库容器删掉再启动数据要靠pgdata这个命名卷保留下来。如果忘了定义volumes,容器一重建数据就没了这个坑比想象的常见。应用代码用 bind mount 挂载进容器。.:/app让你在宿主机上改代码容器里立即生效配合热重载开发体验和本地几乎一致。这也是 Compose 在开发环境比纯docker run好用的原因——配置文件把端口、挂载、环境变量这些散落在命令参数里的东西全部收纳到一起了。3.3 引入容器化的隐性成本我不建议无脑吹 Compose。它真实存在的成本有三块概念门槛镜像、容器、卷、网络、构建上下文每个概念都需要时间消化。团队里如果有人对 Linux 本身都不熟上手会非常挣扎。本地资源开销macOS 上 Docker 靠虚拟机跑内存和 CPU 占用都不小。笔记本只有 8G 内存的话几个容器一起起风扇直接起飞。调试链路变长应用报错了你得先分清是容器内的问题还是镜像是旧的要docker compose exec进去查看日志也要通过logs命令聚合。多了一层抽象就多一层排障成本。这些成本在项目初期、单机单人场景下尤其明显。如果一个项目本来就只有一个进程、宿主机环境也简单你用 Compose 属于杀鸡用牛刀还给自己添了维护 Dockerfile 的负担。3.4 Compose 收益最高的时刻从我几次实践的体会来说Compsoe 的收益拐点出现在**团队里开始有人问为什么我这边跑不起来**的时候。新成员加入后从克隆代码到跑起完整环境如果只需要执行docker compose up一个命令这个体验对团队效率的提升是立竿见影的。另一个高收益场景是项目本身有多个服务——数据库、缓存、队列、定时任务——脚本方案要把这些全部装到宿主机上彼此还可能版本冲突Compose 把它们隔离在各自的容器里互不干扰。4. 选型决策别问哪个好问你处在哪个阶段4.1 四个决策维度我给团队做环境方案评估时通常从四个维度打分而不是凭感觉。维度一服务数量与依赖复杂度。1 到 2 个服务、依赖都是简单的 pip/npm 包脚本完全够。3 个以上服务或者牵扯到不同版本的系统库、中间件直接考虑 Compose。我有一个判断标准如果环境的搭建步骤超过 15 条或者需要手动修改系统级配置脚本方案的脆弱性就会迅速暴露。维度二团队规模与人员流动。单人项目随便选顺手就好。多人协作、特别是经常有新成员加入的团队Compose 的一条命令拉起全部环境优势无与伦比。脚本方案在新人手里大概率变成一场跟着文档猜步骤的冒险。维度三机器与系统多样性。全员都是同样的 macOS脚本能撑很久。一旦出现 Windows Linux macOS 混杂脚本方案的if分支会爆炸这时 Compose 的跨平台一致性优势非常明显。维度四团队的容器经验。这里我最想说句实话如果团队没人用过 Docker第一次就上 Compose 大概率会翻车。容器概念对新手有陡峭的学习曲线项目进度会被什么是镜像层挂载目录怎么变了这类问题拖慢。这种情况下可以先从脚本方案过渡或者让一个有经验的人先把 Compose 方案搭好其他人只负责使用而不是理解。4.2 一张表快速定位我把上面的维度整理成表方便你对照自己的情况决策维度倾向继续用 Shell 脚本倾向迁移到 Docker Compose服务数量1~2 个依赖少3 个及以上含中间件团队规模单人 / 2 人以内3 人以上经常有新人系统一致性全员统一系统版本Windows / Linux / macOS 混杂容器经验零基础没有老手带有人熟悉 Docker能主导搭建部署目标本机开发单台服务器多环境、云环境、多台机器这张表不是二分法。大部分团队会落在中间区域这恰恰是下一节要讲的混合方案的空间。5. 混合方案用 Shell 管操作用 Compose 管环境5.1 我目前最喜欢的组合折腾了几年之后我现在的默认方案是混合式基础设施和环境细节交给 Docker Compose日常操作和参数化交给 Shell 脚本两者通过.env文件和 Makefile 粘合起来。具体来说项目里放一个docker-compose.yml管所有服务再放一个Makefile暴露高频命令让不熟悉容器的人也不用碰 Docker 命令。比如.PHONY: up down logs ps env up: docker compose up -d down: docker compose down logs: docker compose logs -f app ps: docker compose ps env: cp .env.example .env echo 请编辑 .env 填写本地配置这样新同事的流程是复制仓库 → 执行make env创建本地配置 →make up拉起环境 →make logs看日志。他完全不需要理解容器原理也不需要背 Docker 命令所有操作都被收敛成了几个好记的入口。而docker compose.yml里的细节由熟悉容器的人维护双方各得其所。5.2.env是配置注入的正确姿势混合方案最容易踩的坑是把环境变量硬编码进 compose 文件。密码、端口、密钥这些东西一旦写死换个环境就得改文件还会被带进版本库造成泄露隐患。正确做法是用.env文件配合 Compose 的变量替换# .env.example —— 提交到版本库 POSTGRES_DBapp_dev POSTGRES_USERapp POSTGRES_PASSWORDdev_password APP_PORT8080然后在docker-compose.yml里这样引用services: postgres: image: postgres:16-alpine environment: POSTGRES_DB: ${POSTGRES_DB} POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} ports: - 5432:5432 app: environment: DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}postgres/${POSTGRES_DB} ports: - ${APP_PORT}:8080.env本身不提交到版本库只提交.env.example模板。每个人都有独立配置又不互相影响。这比脚本里export一堆变量优雅得多——脚本方案里你为了覆盖一个端口往往要改脚本源码env方案里只需要改自己的.env。5.3 我踩过的几个真实坑混合方案也不是银弹有几个坑我付出了不少时间写出来给你避雷坑一数据卷权限问题。在 Linux 上跑容器pgdata卷里的文件属主经常变成容器内用户导致宿主机上删除或备份时需要 root 权限。补救办法是给pgdata卷指定命名并保持长期复用不要频繁down -v销毁数据卷销毁前务必确认数据已经备份。坑二跨平台的换行符问题。有人在 Windows 上把.env文件保存成带CRLF换行传给容器后值里莫名其妙多个\r数据库连接串就废了。这个错误极其隐蔽排查时我一度以为是自己密码写错了。建议在.env.example顶部加一行注释提醒或者让脚本入口强制做一次dos2unix。坑三镜像版本漂移。写image: postgres:latest是定时炸弹。某次基础镜像更新大版本后本地数据卷里的数据格式不兼容容器直接起不来。从此我所有 compose 文件都固定到具体小版本比如postgres:16.2-alpine升级时走明确的迁移流程而不是被动接受 latest。坑四忘记健康检查导致启动竞态。前面提过的depends_onhealthcheck是标配。没有它应用启动时数据库还没就绪应用进程退出restart 策略又会拉起它形成反复崩溃循环。这时候看日志会发现Connection refused刷屏非常搞心态。6. 最后一点个人体会做了这么多对比和剖析我最终的倾向其实很简单先想清楚环境方案的消费者是谁。如果环境只服务于你自己选你熟悉的——脚本也好、Compose 也罢怎么省事怎么来。如果环境方案要服务于一个团队那就要把这个方案的维护成本计算进去不只是我写着顺手还要考虑别人读起来顺不顺、改起来慌不慌。我在实际使用中的最大感受是Shell 脚本和 Docker Compose 的关系不是替代而是互补。脚本适合做一次性、面向人的交互Compose 适合做反复重现、面向状态的声明。把两者组合起来让脚本去调 Compose、让 Compose 去管环境这套组合在多个项目里都跑得很稳新同事上手的平均时间从以前的两三天缩短到了半小时以内。如果你现在正纠结要不要把项目环境迁到 Compose我的建议是挑一个周末把当前所有依赖服务和安装步骤列成清单对照文章里的四个维度打打分。如果服务数量超过 3 个、团队超过 2 个人迁过来大概率是值得的如果是纯个人玩具项目那继续用脚本就好了不用为赶时髦买单。