本地开发别再装一堆软件：用 Docker Compose 一次跑起可复用的开发环境

本地开发最浪费时间的，往往不是写代码，而是搭环境。新机器上装数据库、缓存、消息队列，版本稍有不同，跑起来就报错；换一台电脑，又要从头折腾一遍。把环境写成代码，是解决这个问题的最直接办法，Docker Compose 就是最顺手的那一个。

Compose 的核心思路很简单：一个项目对应一个 compose 文件，里面写清楚需要哪些服务、用什么镜像、开什么端口、挂什么数据卷、服务之间怎么联网。应用、数据库、缓存不再是散落在各台机器上的安装记录，而是一份可以提交到代码仓库、可以反复执行的配置。

一个最小可用的例子通常包含三个服务：业务应用、PostgreSQL、Redis。应用通过服务名访问数据库，不用记 IP；数据库把数据存在命名数据卷里，容器删了数据还在；Redis 只给本地开发用，不对外暴露不必要的端口。版本号要写死，比如 postgres:16、redis:7，不要图省事写 latest，否则今天能跑、明天拉到新版就可能出问题。

日常命令其实只有几个：up -d 在后台启动，logs -f 看日志，ps 看状态，exec 进容器排错，down 停掉服务。down 和 down -v 的区别一定要分清：前者只停容器，后者会连数据卷一起删，本地有重要测试数据时千万别随手加 -v。

新手最容易踩的三个坑，第一是端口占用：本机已经跑了同端口服务，容器起不来，先查占用再改映射端口；第二是环境变量乱放：密码、密钥放 .env 文件，.env 不要进代码仓库，仓库里只留 .env.example 做示例；第三是把开发配置直接当生产配置用：开发环境可以开调试、挂本地代码目录，生产要另外做镜像、资源限制和健康检查。

想让这套配置真正复用，还可以再加两步：一是用 compose 的 override 文件区分本地和测试，公共部分放主文件，差异部分放 override；二是给项目配一个简单的启动说明，新人照着 up -d 就能跑起来，不用再口头传授一堆安装步骤。

环境即代码的好处，在换电脑、换同事、回滚版本时最明显。配置变了，改文件、重新 up 一次就行；出了问题，logs 和 exec 就能定位，不用先怀疑是不是谁的机器装错了版本。对个人开发者来说，这也是成本最低的工程化习惯：先把本地环境固定下来，再谈部署和自动化。

最后留一个自查清单：服务名能不能互相访问、数据卷是不是命名卷、镜像版本是不是固定、敏感信息是不是在 .env 里、停掉重起后数据还在不在。这五项都通过，这份开发环境就可以放心复用了。