最近有个朋友找我吐槽说新同事按文档搭了两天环境最后卡在一个诡异的端口占用上。我过去一看setup.sh里写了一句pkill -f node结果那台机器上恰巧有个无关进程也匹配了这个模式。这种场景我见过太多次了。从 Shell 脚本到 Docker Compose表面上是把一串命令换成另一个工具本质上是环境管理方案的一次思路切换从“告诉机器怎么做”变成“描述想要什么状态”。这篇文章就把两种方案掰开揉碎聊一聊包括各自的适用边界、迁移决策框架、以及我在实际项目里踩过的坑给正在纠结选型的同学一份可参考的清单。1. Shell 脚本的看家本领以及它藏不住的短板Shell 脚本作为环境管理方案历史比绝大多数读者接触编程的时间都长。它至今没有消失反而在无数项目里继续服役说明它确实有自己的生存空间。但它的短板也同样明显尤其是当项目复杂到一定程度时问题会集中爆发。1.1 “零依赖”和透明性为什么很多项目还在用 ShellShell 脚本最大的优势是零基础依赖。任何一台装好 Linux 的机器、任何一个 macOS 终端天然就能执行.sh文件。你不需要预装 Docker、不需要配置镜像加速、不需要担心版本兼容——只要系统有/bin/sh或bash脚本就能跑。这一点听起来平平无奇但实际价值非常高它意味着环境管理方案本身不需要被“安装”。另一个优势是透明性。Shell 脚本是一行一行命令组成的每条命令执行什么、输出什么、报错怎么提示都是直接暴露在眼前的。调试的时候你可以在任意位置插入echo 当前执行到xxx也可以直接复制脚本里的命令到终端手动跑一遍。这种从“命令即步骤”的映射几乎没有任何中间层对新手来说门槛很低对熟练工来说效率也很高。我自己在一些轻量项目里依然会倾向用 Shell。比如一个内部工具脚本只需要拉一次代码、装一次依赖、拷贝几个配置文件这种场景下一份 20 行的setup.sh比任何容器方案都轻快。脚本里写清楚每一步做什么别人看一遍就能理解整个环境的搭建流程——这也是一种文档价值。另外Shell 脚本特别擅长处理“胶水”性质的工作调用 Git 命令拉分支、通过rg检查进程、用sed改配置文件、把测试结果汇总成日志。这些操作本质上是编排本地工具链而不是应用环境本身用容器反而多余。1.2 环境漂移、非幂等与依赖地狱脚本维护者的噩梦不过Shell 脚本的透明既是优点也是风险的来源。环境漂移是出现频率最高的一个问题。开发者小张的机器上装的是 PostgreSQL 15项目文档却假设你装的是 12小李的机器上 Python 默认命令指向 3.11另一个人指向 3.9。脚本里那些”检查是否存在、不存在就安装”的逻辑在不同机器上会走完全不同的分支结果看似跑通了实际状态却天差地别。”在我机器上能用”这句话本质上就是环境漂移的产物。更麻烦的是非幂等性。一份合格的安装脚本应该具备幂等性——即运行一次和运行十次最终状态应一致。但实际项目中很多 Shell 脚本做不到这一点。比如一条apt install命令重复执行问题不大但一条echo xxx /etc/hosts的追加操作重复执行就会产生重复行一条mysql -e CREATE DATABASE app重复执行会直接报错。为了让脚本可重复运行你得手动加上各种判断先检查目录是否存在、先检查服务是否在运行、先检查端口是否被占用。这些判断逻辑越加越多脚本的复杂度就会快速膨胀比业务代码还难维护。依赖地狱在 Shell 方案里也非常常见。项目需要 Node 18 和 Python 3.10但系统自带的版本都不匹配某个工具链需要 OpenSSL 1.1另一个却需要 3.x。你不得不用nvm、pyenv、apt-key、update-alternatives这些工具层层叠加来凑齐环境。好不容易把本机调通换一台新电脑或者来一个新人又要从头折腾一遍。脚本本身的逻辑可能没问题问题出在脚本运行的环境基数太大、变数太多。1.3 还有哪些场景Shell 依然是正确答案讲清楚问题之后也得说句公道话。Shell 脚本在几类场景里依然是正确答案硬换 Docker Compose 反而是在制造麻烦。第一类是单机、单服务、少依赖的环境准备。比如项目只需要一个数据库和一个 Web 服务系统里现成装了 MySQL 和 Nginx那写个脚本调整配置、初始化表结构就够了。第二类是进程管理和日常运维动作比如重启服务、清理日志、打包备份这些操作和“环境”关系不大纯粹是命令编排Compose 的抽象层次反而不合适。第三类是极简交付场景对方只有一台机器目标是不想引入任何容器层你给一个脚本他就能跑起来。这种场景下Shell 脚本依然是最优解。说到底Shell 脚本输给 Docker Compose不是输在“能不能把环境搭起来”而是输在“能不能把环境稳定地、可预期地复现出来”。2. Docker Compose 重新定义了环境管理的思路Docker Compose 的流行本质上是把环境管理从命令式带入了声明式时代。这一步跨越的影响范围比大多数人意识到的要更大。2.1 从“先做什么、再做什么”到“最终应该是什么样”命令式思维的核心是步骤先安装依赖再初始化数据再启动服务。每一步都必须按顺序执行一旦中间某一步失败后续步骤的结果就不可预期。而声明式思维的核心是状态你定义好“最终环境里应该有哪些服务、每个服务用什么镜像、暴露哪些端口、挂载哪些数据卷”剩下的执行逻辑交给工具去处理。我用一个生活类比来解释这个差别。命令式像是在餐厅点一份”主厨推荐套餐“你得听服务员说明这道菜怎么做、配菜是什么、按什么顺序上声明式则像是直接告诉服务员“我要一份七分熟牛排、配芦笋和一杯干红”——你描述的是结果不是过程。至于厨房怎么备料、用什么锅、几分钟出锅那是后厨的事。映射到 Docker Compose 里一份compose.yaml文件描述的就是“最终状态”services: web: image: nginx:alpine ports: - 8080:80 db: image: postgres:16 environment: POSTGRES_PASSWORD: example你不需要关心nginx:alpine是怎么下载的不需要关心 Postgres 的数据目录初始化逻辑。你只需要声明“我要这两个服务并且 web 的 8080 端口对应容器内的 80 端口”。docker compose up -d一执行Docker 引擎会自动处理镜像拉取、容器创建、网络连接等所有细节。这种心智模型的转变对团队协作的影响是巨大的。Shell 脚本里隐含的执行顺序、分支判断、错误处理逻辑在 Compose 里几乎全部由 Docker 引擎接管。阅读一份 Compose 文件比阅读一份几百行的 Bash 脚本要轻松得多——因为前者描述的是**“是什么”后者描述的是“怎么做”**。2.2 镜像与数据卷为可复现性量身定做的两件法宝Compose 能够实现可复现环境根基在于两个机制镜像和数据卷。镜像是环境在某一时刻的“冻结快照”。它会将操作系统层面的库文件、运行时、应用代码、环境变量等封装为一个不可变对象。你在自己机器上构建了一个镜像交给别人拉到本地得到的是同一个运行环境而不会受宿主机上全局依赖版本的影响。这就解决了 Shell 方案里“环境漂移”的根本问题——环境与宿主机解耦了。数据卷则负责处理“可复现环境里的可变部分”。镜像本身是只读的容器销毁后数据会丢失数据卷将容器的某个目录映射到宿主机或 Docker 管理的卷上实现数据持久化。这样你就可以放心地销毁容器、重新创建容器而不必担心数据库里的记录一起消失。这其实是环境可复现性不可或缺的一环环境可以重建但数据要保留。这里有一个关键点值得展开说一下。很多人以为 Docker Compose 的可复现性只靠镜像其实 Compose 文件里的环境变量、网络配置、依赖启动顺序同样重要。比如services: backend: build: ./backend environment: DATABASE_URL: postgres://app:passdb:5432/app depends_on: - db这份配置描述的不只是“跑一个后端容器”还包含了“后端连接数据库的地址是什么、和数据库服务的依赖关系是什么”。这些信息在 Shell 场景里通常散落在脚本的各个角落——也许是某个export语句也许是某个配置文件模板维护起来极易遗漏。Compose 把这些环境相关的信息统一到了同一个声明文件里大大降低了心智负担。2.3 Compose 也不是万能药哪些情况用它反而添乱Docker Compose 解决了很多问题但它在实际应用中也有明显的边界。首先是性能敏感型任务。容器技术在隔离了环境的同时也引入了额外的系统调用层和网络转发层。如果应用对延迟和吞吐极其敏感比如高频交易的撮合引擎、实时音视频处理直接跑在宿主机上依然有明显优势。不过对绝大多数 Web 后端和数据处理场景这点性能损耗可以忽略。其次是需要访问宿主机硬件或内核的场景。比如某些性能分析工具依赖宿主机内核模块某些工业软件需要直连 USB 设备、GPU 直通等能力容器化会比较复杂。想完全避免这些麻烦Shell 方案反而更容易实现。另外如果项目的核心服务只有一个不依赖任何外部组件那用docker run就够没必要上 Compose——一个 YAML 文件的管理成本对小项目来说依然是成本。再有是团队对 Docker 的熟练度问题。如果团队里没人熟悉容器技术只有一个人会写 Compose 文件那这个方案带来的交付风险可能比 Shell 方案更大。工具本身好不好和团队能不能驾驭它是两回事。这一点我在后面的决策框架里会详细展开。3. 迁移决策框架你到底该选哪个我不是一个“容器原教旨主义者”不认为所有环境管理都得用 Compose。下面这套决策框架来自多个真实项目的复盘大家可以按顺序对照自己的情况。3.1 判断标准一团队协作规模与认知负荷先问一个问题这个项目的环境是只有你自己搭还是会有多个同事反复搭单人项目用 Shell 没有任何问题。你自己写的脚本自己知道每一步在干什么出了问题也能顺着脚本排查。但一旦有第二个、第三个人需要搭建环境Shell 脚本的问题就开始暴露每个人的机器状态不同脚本报错的位置不同你作为脚本作者会反复收到“我这里报错了为什么”的求助。我印象很深的一个案例是某内部项目用的是模拟项目X环境依赖包括 JDK、Maven、MySQL、Redis、Nacos 五个组件。原来有一份 300 行的init.sh创始人自己用得很顺手但每个新同事来都要花一到两天时间才能跑通。后来花了半天时间把环境管理迁到 Compose新同事从拉取代码到服务全部就绪只花了二十分钟。这不是说 Compose 一定比 Shell 简单而是说Compose 把环境的差异封装在一个更可预期的层里。团队协作规模越大这个优势就越明显。3.2 判断标准二服务数量与依赖拓扑第二个问题是你的项目由多少个服务组成它们之间有没有依赖关系如果只是一个单体应用加一个数据库两者没有复杂的启动顺序或网络交互需求Shell 脚本完全够用。但如果服务数量到三个以上且存在相互调用、共享网络、顺序启动等需求手写脚本去管理这些关系会非常吃力。举个例子。两个服务之间需要共享一个内部网络在 Shell 方案里你可能会创建虚拟网卡、手动配置路由规则、或者干脆通过宿主机 IP 访问但这在团队协作时非常容易踩坑。在 Compose 里只要两个服务定义在同一个 YAML 文件里它们天然就在同一个网络内可以直接通过服务名互相访问。这个”服务名即主机名“的机制把服务发现的一部分工作直接内建到了配置里复杂度下降非常明显。依赖拓扑还有一个被忽略的点启动顺序。Shell 脚本靠睡眠等待或者端口轮询来决定先后顺序写起来繁琐、也不可靠。Compose 提供了depends_on来声明依赖虽然它默认只保证“先启动容器”不保证“服务内部就绪”但你至少有了一个明确的依赖声明。配合健康检查和condition: service_healthy可以实现非常可靠的启动顺序控制。3.3 判断标准三目标环境与交付物形态第三个问题最容易被忽略你的环境最后要交付到哪里去如果环境只在本地开发使用Shell 脚本的宽容度还是比较高的因为所有开发人员的目标是“能跑起来就行”对精确的状态一致要求没那么高。但如果环境需要作为交付物传给其他人或者需要尽快在 CI 流水线里复现那 Shell 脚本的脆弱性就会暴露无遗——CI 里的机器比开发机更干净也就更容易因为缺一个系统包、少一条环境变量而失败。我经常和朋友说一个观点你选择的环境管理方案本质上就是你对环境可复现性的期望值。期望越高越应该走向声明式方案。Shell 可以做到可复现但要求你写脚本的人极其自律、把所有的分支和判断都考虑周全Compose 则把大部分可复现性交给了 Docker 引擎只要镜像构建成功、Compose 文件语法正确结果是相对可预期的。交付物形态也很关键。如果你的交付物是一个软件包或者可执行文件环境管理可能只需要在构建阶段起作用Shell 脚本是合理的。但如果交付物本身是一整套可运行的服务环境——比如一个开箱即用的演示系统、一个给客户部署的统一平台——Compose 几乎是唯一的理性选择。3.4 混合策略Shell 和 Compose 是互补的不是对立的说了这么多对比最后我想强调一个比较容易误解的地方Shell 和 Compose 不是二选一的关系而是在实践中高度互补的关系。你会发现用上 Compose 之后你依然需要 Shell——只不过它的角色变了。以前 Shell 要负责整个环境搭建现在 Shell 只需要做容器外的辅助工作检查 Docker 是否安装、确认.env文件是否存在、调用docker compose up -d启动服务、启动后跑几个健康检查命令。我通常会在项目里加一个Makefile来封装常见操作。比如up: docker compose up -d down: docker compose down logs: docker compose logs -f init: ./scripts/init-db.sh这套结构的好处是日常开发只需要记几个简短的 make 命令而无需每个人都去研究 Compose 的细节同时环境本身的管理依然是 Compose 的声明式模型。Shell 管“操作”Compose 管“状态”各司其职。如果在复杂的开发场景里还可以结合开发容器Dev Container等方案把整个开发工具链也容器化。此时 Compose 提供服务编排Shell 只负责容器内的一些初始化动作例如安装 vim 插件、拉取依赖等。这种混合模式在我实际体验中比纯粹用 Shell 或纯粹用 Compose 都要顺滑。4. 实操对比模拟项目 X 的两种写法理论讲再多不如直接看代码。这一节用我实际做过的模拟项目 X 来演示——需求很简单一个 Web 后端服务需要用到 PostgreSQL 和 Redis。4.1 Shell 版本一份依赖繁多的 setup.sh最初这个项目用的是 Shell 脚本文件大概长这样这是精简版本实际要更长#!/bin/bash set -euo pipefail # 检查必要的命令 for cmd in node npm psql redis-server; do if ! command -v $cmd /dev/null; then echo 缺少命令: $cmd exit 1 fi done # 初始化数据库 if ! psql -h localhost -U app -lqt | cut -d \| -f 1 | grep -qw app; then psql -h localhost -U postgres -c CREATE USER app WITH PASSWORD secret; psql -h localhost -U postgres -c CREATE DATABASE app OWNER app; fi # 启动 Redis redis-server --daemonize yes # 安装依赖并启动后端 npm install export DATABASE_URLpostgresql://app:secretlocalhost:5432/app export REDIS_URLredis://localhost:6379 node server.js 听着很合理对吧实际跑起来问题一堆。psql的参数在不同版本 PostgreSQL 里有差异redis-server --daemonize yes在已经有一个实例时会产生告警日志node server.js 启动进程的方式在关闭终端后进程容易被终止还得用nohup。而且最关键的问题是这套脚本假设你的机器上已经有了 Node、PostgreSQL、Redis版本还得兼容。如果新人机器上没有装 PostgreSQL脚本第一行检查就会直接退出接下来全靠手动。这里set -euo pipefail是个好习惯它能让脚本在对变量引用出错时及时停下避免带病执行。但即便做到了这个程度环境问题依然是防不胜防的。比如系统自带的 PostgreSQL 默认监听localhost:5432但 Mac 的某些数据库工具会占用这个端口又比如 Node 版本如果是 18 以下项目里用到的最新语法直接报错。Shell 版本的维护成本在项目进入第二个月后开始明显上升。几乎每次新同事加入都要花一两个小时排查环境差异。4.2 Compose 版本docker-compose.yml 的结构化表达换成 Compose 之后整个环境管理文件变成了一份 YAMLservices: db: image: postgres:16 environment: POSTGRES_USER: app POSTGRES_PASSWORD: secret POSTGRES_DB: app ports: - 5432:5432 volumes: - db_data:/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 volumes: - redis_data:/data backend: build: ./backend depends_on: db: condition: service_healthy redis: condition: service_started environment: DATABASE_URL: postgresql://app:secretdb:5432/app REDIS_URL: redis://redis:6379 ports: - 3000:3000 volumes: - ./backend:/app - /app/node_modules volumes: db_data: redis_data:对照 Shell 版本这份 Compose 文件有几个核心变化值得注意。一是数据库配置里增加了健康检查。pg_isready -U app会探测 PostgreSQL 是否真正可以接受连接而不是仅仅“容器进程已经启动”。这样后端容器启动时数据库大概率已经可用。在 Shell 版本里你靠的是sleep 3这种赌运气的方式二者的可靠性完全不在一个量级。二是后端代码通过数据卷挂载进容器。./backend:/app让本地修改能实时反映到容器内配合- /app/node_modules排除 node_modules 目录避免和宿主机冲突。这样开发体验和本地跑几乎一致但依赖安装在容器内部不污染宿主机。三是所有环境变量集中管理。DATABASE_URL和REDIS_URL中数据库地址写的是服务名db和redis而不是localhost。因为容器内这些服务不在宿主机回环地址上而是通过 Compose 内部的 DNS 解析到对应服务。这个设计让环境升级变得异常简单如果想在本地用 Managed PostgreSQL只需要改环境变量指向外部地址即可不需要改动代码。实际使用命令也很简单docker compose up -d docker compose ps docker compose logs -f backend docker compose down新同事加入后唯一要做的就是安装 Docker Desktop 或 Docker Engine然后执行docker compose up -d。不再需要逐个排查 Node、PostgreSQL、Redis 的版本和安装状态。4.3 迁移过程中踩过的坑从 Shell 迁移到 Compose 不是一帆风顺的。我帮别人迁移时遇到过几个高频问题这里集中记录。第一个坑是POSTGRES_USER 和数据库默认库的关系。如果POSTGRES_DB不显式指定镜像会用POSTGRES_USER的值作为默认数据库名。我在初期经常漏写POSTGRES_DB: app结果客户端连app库总是提示不存在。Shell 脚本时代建库逻辑都是手写的容易忽略镜像的这套默认行为。第二个坑是depends_on 的默认行为不是“服务就绪”。Compose 里depends_on只保证依赖容器先启动但容器启动不等于内部服务可用。比如 PostgreSQL 容器已经创建但数据库实例还在初始化中如果后端立即尝试连接会报连接拒绝。后来我改用healthcheckcondition: service_healthy才解决了这个问题。这个坑在文档里其实写得很清楚只是很多人包括我自己都会先被直觉带偏。第三个坑是数据和权限问题。第一次用volumes挂载 PostgreSQL 数据时宿主机目录如果没有正确的权限容器会直接启动失败返回Permission denied。后来换成具名卷db_data就绕过了这个问题。我的建议是数据持久化尽量用具名卷除非你有明确理由要把数据目录暴露到宿主机特定路径。第四个坑是构建与本地代码同步的冲突。build: ./backend在构建时会复制一份代码到镜像运行时又通过挂载覆盖项目目录。如果Dockerfile里RUN npm install的时机不对镜像里的node_modules会被挂载的宿主机目录隐藏掉。解决方法是把node_modules也加入挂载排除区或者在Dockerfile里先复制package.json再复制代码确保依赖安装步骤能利用构建缓存。5. 常见问题与排查技巧实录最后整理一份我在实际切换过程中沉淀下来的排障清单和一些零碎心得。5.1 问题速查表症状常见原因解决方案docker compose up报端口被占用宿主机已有服务占用了目标端口换端口映射或先停止冲突进程后再启动后端容器反复重启depends_on只保证了启动顺序数据库还没就绪为数据库容器配置健康检查并设置condition: service_healthy容器内访问不到数据库连接地址误用了localhost容器集群内改用服务名如db、redis数据卷目录权限报错宿主机目录权限与容器用户不一致改用具名卷或在 Compose 中手动设置用户 ID 映射配置文件修改不生效未挂载配置文件或挂载路径不对检查卷映射是否正确以及文件路径是否被镜像内文件掩盖容器能启动但执行 SQL 报表不存在环境变量POSTGRES_DB未设置显式声明POSTGRES_USER、POSTGRES_PASSWORD、POSTGRES_DB本地日志时间不准容器默认使用 UTC 时区在 Compose 中设置TZAsia/Shanghai或映射/etc/localtime构建镜像时 npm install 很慢未配置镜像源或缓存层失效在Dockerfile中先复制package.json配置国内 npm 镜像源再复制源码这个表我会直接放进项目的README里新同事遇到问题时能先自查一轮大大减少”问作者“的频率。5.2 从实践中沉淀的几点经验写环境管理方案本质上是在写一份可执行的文档。既然是文档就要考虑阅读者是谁、使用场景是什么。以下几点是我反复踩坑之后总结出来的分享给大家借鉴。第一点是把 Compose 文件也纳入代码评审。很多人会把docker-compose.yml当作配置随手提交不做评审。但环境文件一旦出错影响的是整个团队的开发效率。我在团队里会要求环境相关的变更和业务代码走同样的评审流程这一条看似增加成本实际省掉了大量排查时间。第二点是固定镜像版本不要用未打标签的镜像。postgres:latest这类写法在某个时间点之后可能指向新的主版本导致某天突然环境行为和昨天不一样。我会把镜像版本精确到主版本比如postgres:16或者再带上小版本号。如果追求最大确定性可以把镜像摘要digest也锁住。第三点是正确区分.env文件、Compose 变量和容器内环境变量。docker compose会从项目根目录读取.env文件用于在 Compose 文件内部做变量替换environment:设置的变量则属于容器内部。这两个概念容易混淆。我见过有人把配置项写在容器环境变量里却试图在.env里引用它导致取不到值。理解这一层区别能避免很多莫名其妙的配置问题。第四点是给每个服务定义健康检查尤其是那些有依赖关系的服务。上一节提到过depends_on本身不等同于“服务就绪”。如果要做到类似 Kubernetes 探针那样的精确控制Compose 里就必须搭配healthcheck。这一步多花十分钟省的是后端服务“每次启动都先报错几秒钟再恢复”的尴尬体验。第五点也是最后一点不要用 Compose 管理一切。像日志切割、系统级调优、内核参数配置这类操作放在容器外反而更合适。整个环境管理体系的边界应该由实际诉求决定而不是由技术偏好决定。我在实践中的体会是Shell 和 Compose 不是前后两个时代更像是一把螺丝刀和一个电动工具的差别——大工程用电动工具省力小修补用螺丝刀更顺滑。能根据项目体量、团队形态和交付目标灵活选择才是环境管理这个命题最核心的能力。