compose 编排规范虽不强制无状态，但通过扩缩容、健康检查、存储与网络策略及可观测性机制，倒逼业务服务必须实现无状态；状态须外移至redis、minio等专用组件，初始化需幂等，配置须注入，连接须可重连，监控指标差异大即暴露隐藏状态。
直接说结论：Compose 编排规范本身不强制无状态，但它通过部署约束、服务生命周期和扩缩容机制，天然排斥有状态行为——只要你想用好它，业务服务就不得不往无状态方向改。
部署模型倒逼状态外移
Compose 的 replicas 和 scale 能力要求同一服务的多个实例完全可互换。一旦某个服务在本地内存存 session、缓存计数器或未持久化的临时文件，扩到 3 个实例后用户请求轮询到不同容器，状态就断了。
- 必须把会话数据迁到 Redis 或 DataStore，不能靠
ConcurrentHashMap存在 JVM 里 - 计数类逻辑（如限流、频次）得走分布式锁或原子操作，不能依赖单机变量
- 上传的临时文件必须写入共享存储（如 MinIO、NFS 卷），不能写
/tmp
健康检查与自动重建切断“状态依赖”
Compose 支持 healthcheck 配置，配合 restart_policy 可让故障容器秒级重建。如果服务启动时要加载本地配置文件、初始化内存索引、等待某个外部连接就绪，那每次重启都可能失败或延迟就绪。
- 所有初始化逻辑必须幂等且快速，不能假设“上次运行留下的状态还在”
- 配置从环境变量或 ConfigMap 注入，不读取容器内固定路径的 properties 文件
- 数据库连接、下游服务发现等必须支持重连，不能靠启动时一次性建立并长期持有
Volume 与网络策略划清“有状态边界”
Compose 允许声明 volumes 和 networks，但明确区分“谁该管状态”：
- 数据库、对象存储、消息队列这类真正有状态的服务，应单独定义为 service，并挂载专用 volume；业务服务只通过网络调用它们
- 业务服务自己的
volumes只用于日志落盘或临时缓冲，且需标注read_only: true或明确清理策略，避免误当成状态载体 -
depends_on只控制启动顺序，不解决状态同步问题——你不能指望 MySQL 启动完，你的服务就自动读到它最新的某张表快照
可观测性暴露隐藏状态
Compose + Prometheus/Grafana 的标准观测栈，会持续采集每个容器的 CPU、内存、重启次数、HTTP 错误率。如果某服务内存持续上涨、重启频繁、或各实例指标差异极大，大概率说明它在内部维护了不该有的状态。
- 内存泄漏、未关闭的流、静态集合缓存未淘汰，都会在多实例下被放大暴露
- 日志中出现
Connection refused但下游服务明明健康？可能是本机连接池复用失败，本质是连接状态没做隔离 - 监控告警建议加一条：“同服务多实例间关键指标标准差 > 30%”，这是隐藏状态的强信号
不是 Compose 在改造业务，而是当你认真按它的规则写 docker-compose.yml 并跑起来，那些过去被忽略的“小状态”会立刻变成故障点、扩容瓶颈或监控红灯——改造，其实是被逼出来的清醒。
