本地开发别再手动起服务：用 Docker Compose 搭一套可复用的开发环境

新项目第一天，最耗时间的往往不是写代码，而是把环境跑起来：先装数据库，再改配置文件，接着启动缓存，端口被占用又要换一个，换了电脑或者换了同事，同一套步骤还要再来一遍。手动起服务看起来只是几条命令，实际上每一步都依赖记忆和运气，环境不一致带来的问题最后都会变成代码问题。

用 Docker Compose 解决这个问题的思路并不复杂：把环境写成文件，让启动变成一条命令。我的做法是只保留三个文件。第一个是 docker-compose.yml，它定义要启动哪些服务、每个服务用什么镜像、暴露哪个端口、依赖关系是什么。第二个是 .env，它放会变的东西，比如数据库名、密码、端口号，不同电脑改这里就行，不用改编排文件本身。第三个是 README 启动说明，只写三件事：先决条件、一条启动命令、启动失败时先看什么。三个文件分开后，新人不用再问前辈每一步该敲什么，照着文件走就能得到同一套环境。

这里最容易混淆的是两种挂载。数据持久化用 volume，也就是把数据库的数据交给 Docker 管理的卷保存，容器删了重建，数据还在，适合数据库和缓存的持久数据。代码同步用 bind 挂载，也就是把本地代码目录直接映射进容器，本地改了代码，容器里立刻能看到，适合开发阶段频繁修改。简单记一条规则：怕丢的数据用 volume，要频繁改的东西用 bind，两个不要混用，否则要么改了代码不生效，要么删了容器数据也没了。

端口冲突是本地开发最常见的拦路虎。处理办法是先分层：应用、数据库、缓存各用固定但不常用的端口，并在 .env 里集中管理；启动前用端口查看命令确认占用情况，冲突时改 .env 里的端口而不是改代码里的默认端口；团队内部约定一份端口表，避免每个人都用同一个默认端口。把端口写进文件而不是记在脑子里，换电脑时才不会重新踩坑。

固定镜像版本同样重要。不要在开发环境里写 latest，因为今天拉到的版本和下周拉到的版本可能不一样，问题排查会变得毫无头绪。写成具体的版本号，例如数据库用一个明确的大版本加小版本，升级时先改文件、再全量重建、再跑验证，让版本变化成为一次有记录的动作。

启动后不要只看容器状态是 running 就算完成，真实验证只需要三步。第一步，看日志有没有报错，重点是数据库是否完成初始化、应用是否真正监听了端口。第二步，用健康检查或者接口请求确认服务能响应，而不是只看进程存在。第三步，走一次真实业务链路，比如登录一次、写一条数据再读出来，确认数据库和缓存都参与了工作。三步都通过，这套环境才算可用。

这样做的好处不是炫技，而是可复用：同一份文件可以在自己电脑、队友电脑和演示环境重复使用，出了问题先看文件和日志，而不是重新装一遍服务。本地开发的目标从来不是把环境搭得多复杂，而是让启动这件事变得确定、可重复、可交接。把服务写进 Compose，把变量写进 .env，把步骤写进 README，下一次开新项目，你只需要复制这三个文件，改几个参数，就能直接开始写代码。