143 是怎么算出来的
Linux 里进程被信号终止时，退出码按 128 加信号编号表示；15 号信号是 SIGTERM，于是 128+15=143。docker stop、编排层的滚动更新、宿主机有序关机，默认动作都是给容器主进程发 SIGTERM，应用没有捕获信号就直接退出，留下 143 属于预期行为而不是故障。真正值得关注的是退出之前有没有完成收尾：连接排空、缓冲数据落盘、向注册中心注销实例。
基本信息
| 含义 | 128 + 15，即被 SIGTERM 终止 |
|---|---|
| 常见来源 | docker stop、编排滚动更新、宿主关机 |
| 关注点 | 退出前是否完成优雅收尾 |
| 容易混淆 | 137 对应 SIGKILL，多与超时强杀或内存超限有关 |
典型使用场景
- 发布后核对：确认旧实例是收到信号正常退出，而不是崩溃
- 告警分诊：把 143 与 1、137 区分开，避免把正常下线当故障上报
- 零丢失验收：检查被停止的实例是否完成了数据落盘
- 流水线断言：部署脚本里判断退出码是否符合预期，作为发布成功的条件之一
- 复盘对照：用退出码与操作时间线互相印证
确认与取证
确认与取证
# 停止容器
docker stop web
# 读退出码与状态
docker inspect -f 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} finished={{.State.FinishedAt}}' web
# 看退出前的最后输出，判断收尾有没有执行
docker logs --tail 50 web | tail -20
# 观察容器状态变化的时间点，和操作记录对照
docker events --since 30m --filter container=web --filter event=stop常见退出码对照
| 退出码 | 对应信号 | 典型场景 |
|---|---|---|
| 0 | 无 | 进程正常执行完并结束 |
| 1 | 无 | 应用自身报错退出，需看日志 |
| 130 | SIGINT(2) | 被中断信号终止，前台调试常见 |
| 137 | SIGKILL(9) | 宽限期超时被强杀，或内存超限被杀 |
| 143 | SIGTERM(15) | 被正常停止或编排替换，属预期 |
镜像里若用 STOPSIGNAL 指定了别的信号，退出码会随信号变化，排查前先看镜像配置。
若业务要求零丢失，应用需要自己捕获 SIGTERM 并完成收尾，这属于应用改造，不是容器参数能解决的问题。