用 Docker Compose 固化本地开发环境：一份可提交、可复现的编排文件

先说结论：把本地依赖从「口口相传的操作步骤」变成一份能提交进仓库的编排文件，是消除「我这里能跑、你那里跑不起来」成本最低的办法。下面用一个 Node 服务 + PostgreSQL + Redis 的最小组合，讲讲实践中真正影响体验的几个细节。

一、镜像别写 latest

postgres:16.3-alpine 比 postgres:latest 稳得多。写死小版本，半年后同事拉下来的还是同一个镜像；写 latest，上游某天发个版，所有人的本地环境同时变脸，而且没人知道为什么昨天还好的代码今天挂了。

二、depends_on 要配 healthcheck

只写 depends_on 只保证容器“启动了”，不保证数据库“能接受连接”。PostgreSQL 初始化数据目录的那几秒，应用已经在疯狂重连。加上 healthcheck，并用 condition: service_healthy，才真正解决启动顺序问题。

三、数据卷用具名卷

匿名卷在 compose down 之后容易变成孤儿，down -v 又会把同事三个月的数据一起清掉。具名卷至少在 docker volume ls 里一眼能认出来，删的时候要打全名，多一道心理防线。匿名卷在 compose down 之后容易变成孤儿，down -v 又会把同事三个月的数据一起清掉。具名卷至少在 docker volume ls 里一眼能认出来，删的时候要打全名，多一道心理防线。