Docker Compose 把 Node 和 Nginx 放一起后，哪些边界最容易乱
Docker Compose 刚开始用的时候特别有吸引力，因为你很快就能把 Node.js 服务、Nginx 代理、数据库一起拉起来。可 2017 年我自己真正把它放进开发流程后，最大的感受不是“真方便”，而是“边界太容易乱了”。
如果只是为了让容器启动成功，Compose 很快就能给你成就感；但如果你希望这套环境长期可维护，就必须先分清谁负责什么。
第一条边界：谁暴露端口，谁只走内部网络
很多人一开始会把每个服务都直接映射到宿主机端口，图的是省事。
可 Node、Nginx、数据库全都对外暴露之后，调试路径会越来越混乱，你甚至分不清前端请求到底打到了哪里。
我后来更习惯这样拆：
- Nginx 对外暴露端口
- Node 服务只在内部网络里被代理
- 数据库默认不直接暴露，除非明确需要本机调试
这样做最大的好处，是请求入口稳定，职责也清楚。
第二条边界：配置是写在镜像里，还是写在环境里
Node 服务里最容易乱的是配置来源。
一部分写进镜像，一部分放 .env，一部分又塞在 Compose 文件里，最后谁覆盖谁，全靠猜。
那几年我吃过几次亏之后，慢慢形成一个偏保守的习惯：镜像负责运行基础，环境负责实例差异。
也就是说，代码和依赖跟镜像走，域名、端口、后端地址、日志级别这些跟环境走。
第三条边界：日志从哪里看
如果 Nginx、Node 都在打日志，而团队又没有说清楚“线上问题先看哪层”，排障会非常绕。
我更喜欢在一开始就约定：
- 请求进没进来，先看 Nginx
- 业务有没有报错，再看 Node
- 不是每层都承担全量诊断责任
日志是为了缩小范围，不是为了让大家在两份输出里来回翻找同一件事。
第四条边界：Compose 是开发编排，不是万能部署设计
这是我后来非常认同的一点。
Compose 很适合本地联调、演示环境和轻量部署，但它不是一份什么都能承载的架构说明书。
如果把服务依赖、发布策略、健康检查、日志采集、扩缩容预期都硬塞进一份 Compose 文件里，最后只会得到一份越来越难懂的配置集合。
结尾
Docker Compose 的价值是把多服务场景变得容易启动，但真正让它长期可用的，不是多写几行 YAML，而是把入口、配置、日志和网络边界先分清。2017 年我对容器化最大的体会之一，就是“能拉起来”和“能长期维护”根本不是同一件事。