Docker Compose 入门里最实用的一点：服务名就是网络地址

刚开始用 Docker Compose 做本地联调时，最容易犯的错误就是还在用宿主机思维理解容器之间的访问关系。比如 API 容器去连数据库时，配置里还写 127.0.0.1，结果明明数据库已经启动了，应用还是一直报连接失败。这个问题其实不是 Compose 配错了，而是没有建立起一个很关键的认知：同一个 Compose 网络里，服务名本身就是彼此访问时最方便的地址。

容器里的 localhost 只代表它自己

这件事看似基础，却足够让很多本地环境卡很久。应用容器里写 localhost:3306，连到的不是宿主机上的 MySQL，也不是另一个数据库容器，而是它自己的网络命名空间。只要这个前提没想通，后面的端口映射、启动顺序、健康检查都会越看越乱。

一旦改成服务名，比如 db:3306、redis:6379，整个心智模型就会立刻清晰很多。你是在一个由 Compose 组织起来的小型内网里做互访，而不是一堆进程共用宿主机的 localhost。

端口映射主要是给宿主机访问，不是给容器互访

另一个常见误区是看到 ports 配了 3307:3306，就以为应用容器里也应该连接 3307。其实这个映射主要是让宿主机上的客户端方便访问容器。对同一网络内的其他容器来说，直接走容器内部端口就够了。

这个区别一旦搞混，配置文件里就会同时出现两套端口语义，排查起来非常痛苦。一个简单原则就够了：容器互访看服务名和容器端口，宿主机访问才看映射后的端口。

Compose 最适合本地还原“多服务协作”

我很喜欢用 Compose 做本地开发，不是因为它高级，而是因为它能把 API、数据库、缓存、管理工具这些服务关系放在一份文件里。你读配置时，就能顺着服务名看清谁依赖谁，哪个端口只给内部使用，哪个端口要暴露给宿主机。

对团队协作来说，这比口头说明“你先起这个，再改那个 host”要靠谱得多。别人只要把配置拉下来，基本就能按同样方式启动。

把网络关系想明白，Compose 会简单很多

很多人觉得 Compose 难，是因为一上来就被卷进一堆参数和概念。其实入门阶段最值得先掌握的，就是这条最实用的规则：服务名就是默认网络里的访问入口。只要这个点建立起来，数据库连接、缓存配置、服务联调都会顺很多。

本地容器编排并不复杂，复杂的是宿主机思维和容器思维混在一起。先把这个区分拉开，很多“神秘错误”都会失去神秘感。