Docker vs 手动操作：效率对比实测
缘起：一次凌晨两点的环境灾难
先说说我为什么要做这个测试。去年接了一个老项目，PHP 5.6 + MySQL 5.5 + Redis，客户服务器上跑得好好的，但要在我本地搭一套开发环境。手动装了整整一个晚上：MySQL 5.5 在新版 macOS 上编译不过，换 brew 装旧版本又遇到依赖地狱，PHP 扩展一个一个折腾。凌晨两点，我盯着屏幕想：如果我一开始就用 Docker，会省多少时间？
于是我这周专门抽时间做了一次严肃的对比实测。同样的任务，手动操作一遍，Docker 操作一遍，全程计时、记录踩坑点。下面是完整的过程和数据。
实测任务设计
我选了三个最常见的开发场景，尽量模拟真实工作：
- 搭建 LNMP 开发环境（Nginx + PHP 8.2 + MySQL 8 + Redis）
- 给一个 Python 项目切换运行时版本（从 3.9 升到 3.12）
- 新同事入职，从零到项目能跑起来
测试机器：M1 MacBook Pro 16G，网络正常。手动方案用 Homebrew + 手动配置，Docker 方案用 docker-compose。
场景一：LNMP 环境
手动操作：52 分钟
我的步骤和耗时：
brew install nginx php mysql redis：约 8 分钟（下载时间看网络脸色）- 配置 PHP-FPM 与 Nginx 联动：18 分钟。这里踩了个大坑——brew 装的 PHP 配置文件路径在
/opt/homebrew/etc/php/8.2/，而网上大部分教程还是/usr/local/etc/的 Intel 路径，我照着改了半天没生效，最后发现 PHP-FPM 根本没启动 - MySQL 初始化 + 设置密码 + 建库：12 分钟
- Redis 配置 + PHP redis 扩展（
pecl install redis，编译失败一次，缺autoconf，又花 5 分钟装依赖）：14 分钟
最后能跑，但中间装好的环境污染了我的系统——本来的 PHP 8.3 项目被 brew 切换版本搞坏了，这是我后来才意识到的隐藏成本。
Docker 操作：7 分钟
写一个 docker-compose.yml：
services:
nginx:
image: nginx:1.25
ports:
- "8080:80"
volumes:
- ./src:/var/www/html
- ./nginx.conf:/etc/nginx/conf.d/default.conf
depends_on:
- php
php:
image: php:8.2-fpm
volumes:
- ./src:/var/www/html
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: dev123
MYSQL_DATABASE: myapp
ports:
- "3306:3306"
volumes:
- mysql_data:/var/lib/mysql
redis:
image: redis:7-alpine
ports:
- "6379:6379"
volumes:
mysql_data:
然后：
docker compose up -d
首次拉取镜像花了约 5 分钟（这是唯一的大头），之后每次启动只要 10 秒左右。如果需要 PHP 扩展，可以自己 build 一个镜像：
FROM php:8.2-fpm
RUN pecl install redis && docker-php-ext-enable redis
结果：Docker 快了 7 倍以上，而且不污染系统环境。这一点是手动方案完全做不到的。
场景二：Python 版本切换
手动方案：brew install python@3.12，然后处理 PATH 优先级、pip 混乱问题，约 15 分钟，而且旧项目可能被影响。
Docker 方案：
docker run -it -v $(pwd):/app -w /app python:3.12 python main.py
30 秒搞定，旧项目继续用 python:3.9 跑，互不干扰。甚至可以一行命令测试同一份代码在三个版本下的表现：
for v in 3.9 3.11 3.12; do
docker run --rm -v $(pwd):/app -w /app python:$v python -m pytest
done
这种能力手动方案基本没有等价物。Docker 完胜。
场景三：新同事入职
这是我认为最有价值的对比。手动方案下，我给新同事发了一份 40 页的安装文档（真的存在，还在不断过期）。对方花了一整天，还是卡在“我的 MySQL 版本和你不一样”这种问题上。
Docker 方案下，我发的是：
git clone xxx
docker compose up -d
docker compose exec php php composer.phar install
新同事 25 分钟跑通项目，其中 15 分钟在等镜像下载。
我踩过的坑（Docker 也不是银弹）
诚实地说，Docker 方案也有让人想骂娘的时刻：
- Mac 上文件挂载性能差。
vendor/node_modules挂载进去后，composer install比宿主机慢 2-3 倍。解法是用 named volume 缓存依赖目录，或者用 VirtioFS（新版 Docker Desktop 已默认开启，好了很多） - 镜像有学习成本。第一次写 Dockerfile 我写了 9 层
RUN，每次改一行代码都要重装全部依赖。后来学会利用层缓存——把COPY composer.json和composer install放在COPY . .之前，构建时间从 4 分钟降到 40 秒 - 数据库数据丢失。忘了挂 volume，
docker compose down之后数据全没了。现在 volume 是必配项 - 调试变绕了。看日志要
docker compose logs -f，进容器要exec -it xxx bash，手动方案里tail -f就完事了
最终数据汇总
| 场景 | 手动 | Docker | 提速 |
|---|---|---|---|
| LNMP 环境（首次） | 52 分钟 | 7 分钟 | 7.4x |
| 环境重建/迁移 | ~40 分钟 | 1 分钟 | 40x |
| Python 版本切换 | 15 分钟 | 1 分钟 | 15x |
| 新人入职 | 1 天+ | 25 分钟 | ~20x |
首次搭建的差距其实是 7 倍，但环境重建才是 Docker 的杀手锏——手动方案每次重装都要重走一遍坑，Docker 只是一行命令的事。
实用建议
- 首次搭建也别裸写 compose 文件，去 composeexamples.com 或官方文档找模板改一改，能再省一半时间
- 动手前先把
docker compose down -v和docker compose down的区别搞清楚，前者会删数据 - 把开发数据库的初始化 SQL 放进
docker-entrypoint-initdb.d/，容器第一次启动就自动建表 - 给镜像打明确的版本号（用
mysql:8.0而不是mysql:latest），避免某天 pull 到大版本更新直接起不来
诚实的结论
如果你的项目就一个、环境简单、只在你自己机器上跑，手动装一装完全没问题，还少一层抽象。但只要满足下面任意一条：多项目、多版本、多人协作、需要频繁重建环境——Docker 的投入产出比就高得离谱。我实测后的结论是：前 3-4 个小时的学习成本，会在第一次换机器或第一个新同事入职时全部赚回来，之后全是净赚。