容器日志中出现 Exit Code 143 时，通常会先怀疑程序崩溃，但真实情况常常是进程收到了 SIGTERM 信号后，因为没有注册处理函数，直接按内核默认行为终止。理解这个退出码的由来，能够帮助我们在 Kubernetes 发布、Docker 停止容器、系统服务重启时，快速区分正常终止和异常崩溃。
退出码143是怎么算出来的
Linux 信号中，SIGTERM 的数字编号是 15。当一个进程因为信号终止时，它的父进程通过 waitpid 或 wait 获取子进程状态。Shell 为了把进程是被信号杀死这个信息暴露出来，会在信号编号上加上 128。所以 128 加 15 正好等于 143。也就是说，退出码 143 并不表示程序内部调用 exit(143)，而是 shell 对 SIGTERM 终止的一种编码方式。
这个约定在 Bash 里可以直接验证。先启动一个不处理 SIGTERM 的进程，再用 kill 发送 TERM 信号，最后打印 $?，结果就是 143。需要注意的是，如果进程自己调用 exit(15)，退出码会直接显示为 15，而不是 143。只有信号导致的终止才会加上 128。
# 启动一个不会处理 SIGTERM 的进程 sleep 1000 & pid=$! kill -TERM $pid wait $pid echo "exit code: $?"
上面例子中，sleep 没有为 SIGTERM 注册处理器，因此默认动作直接终止它，shell 最终输出的是 exit code: 143。如果换成 kill -KILL $pid，退出码就会变成 137，因为 SIGKILL 的编号是 9，128 加 9 等于 137。
SIGTERM 和 SIGKILL 的区别决定了能否优雅退出
SIGTERM 是 Linux 用来请求进程退出的信号，进程可以捕获它、忽略它，也可以在收到信号后执行任意清理逻辑。常见的优雅关闭流程是：停止接收新连接、处理完存量请求、关闭数据库连接池、刷新日志缓冲，最后再调用 exit(0) 或直接返回。正因为 SIGTERM 可被捕获，应用才有机会在退出前保持数据一致性。
SIGKILL 则完全不同，它不能被捕获、不能被忽略，内核会立即终止进程，不留给应用任何清理时间。容器平台在停止容器时会先发送 SIGTERM，给应用一个宽限期。如果超过宽限期进程还没有退出，平台才会补发 SIGKILL。Kubernetes 的 terminationGracePeriodSeconds 默认是 30 秒，Docker 默认在发送 SIGTERM 后等待 10 秒。如果应用没有正确处理 SIGTERM，最终大概率是被 SIGKILL 强杀，日志里也不会留下优雅关闭的痕迹。
因此，看到 143 说明进程至少收到了 SIGTERM，但看到 137 往往说明优雅关闭失败，只能被强制杀死。当然这里有一个前提：进程的 PID 1 确实收到了信号。如果信号被 shell 或启动脚本吞掉，表现出来的行为可能更隐蔽，这也是容器环境中最常见的坑之一。
如何在不同语言里实现优雅终止
实现优雅终止的通用思路是：监听 SIGTERM 信号，收到信号后把运行状态标记为关闭中，通知主循环或 HTTP Server 停止接收新任务，等待已接收的任务完成，最后清理资源并退出。下面用 Go 的 HTTP 服务作为例子，因为 Go 的 net/http 提供了 Shutdown 方法，很适合演示这个流程。
package main
import (
"context"
"log"
"net/http"
"os"
"os/signal"
"syscall"
"time"
)
func main() {
srv := &http.Server{Addr: ":8080"}
go func() {
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatalf("listen: %v", err)
}
}()
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGTERM, syscall.SIGINT)
<-quit
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatalf("shutdown: %v", err)
}
log.Println("server exited")
}这段代码在收到 SIGTERM 或 SIGINT 后，会等待 srv.Shutdown 关闭所有活跃连接，最多等待 10 秒。如果 10 秒内没有处理完，Shutdown 会返回错误，此时可以选择记录日志后退出。对于需要更长清理时间的任务，应把超时时间调大，并保证容器平台的宽限期比这个值更长。
Python 程序则可以通过标准库 signal 绑定处理函数。虽然在多线程程序里信号处理会有更多限制，但对于大多数单体服务，下面的写法已经足够。关键点是在主循环中检查标志位，而不是在处理函数里直接做大量清理工作。
import signal
import sys
import time
running = True
def handle_term(signum, frame):
global running
print("received SIGTERM, cleaning up...")
running = False
signal.signal(signal.SIGTERM, handle_term)
while running:
time.sleep(1)
print("exit cleanly")
sys.exit(0)如果服务使用 Node.js，也可以监听 SIGTERM 事件并调用 server.close。注意不要直接在回调里调用 process.exit，否则可能切断尚未完成的异步操作，正确做法是先关闭 HTTP 服务，等回调完成后再退出。
容器环境里信号转发的常见坑
Dockerfile 的 CMD 有两种写法：exec form 和 shell form。exec form 是一个 JSON 数组，例如 CMD ["nginx", "-g", "daemon off;"]，此时 nginx 直接成为容器 PID 1，能够收到 Docker 发来的 SIGTERM。shell form 看起来像 CMD nginx -g 'daemon off;'，Docker 实际会把它包装成 /bin/sh -c，这样 PID 1 就变成了 shell，而不是 nginx。
FROM nginx:alpine # 错误：shell form，信号只发给 /bin/sh，nginx 不一定收到 CMD nginx -g 'daemon off;' # 正确：exec form，nginx 直接作为 PID 1 CMD ["nginx", "-g", "daemon off;"]
如果一个容器使用 shell form 启动，停止容器时 Docker 向 PID 1 的 /bin/sh 发送 SIGTERM，但 shell 未必会把信号转发给子进程。结果是应用来不及处理 SIGTERM，直到宽限期结束被 SIGKILL 强杀。类似问题也会出现在用 shell 脚本作为入口的容器中，解决办法是在脚本里使用 exec 替换当前进程，或者直接用 exec form。
Kubernetes 里还需要关注 terminationGracePeriodSeconds 与 preStop 的配合。如果配置了 preStop hook，Pod 停止时会先执行 preStop 中的命令，然后再发 SIGTERM。preStop 的执行时间会被计入宽限期，所以宽限期必须大于 preStop 耗时加应用清理耗时，否则应用一样会被强制终止。
排查 143 退出码的实用思路
遇到容器退出码 143，第一步是确认它是否发生在正常发布、扩缩容或节点驱逐期间。如果在这些操作中出现，通常说明平台主动停止了容器，143 是预期的信号结果。第二步查看容器日志最后几行，有没有记录类似 shutdown signal received、gracefully stopping 的内容。如果有，说明应用捕获了 SIGTERM，并进入了清理流程。
如果日志没有任何清理信息，需要检查 PID 1 是否真的是应用进程，而不是 shell。可以在容器内执行 ps -ef 查看进程树，确认启动命令是否使用了 exec form。还可以手动测试：进入容器后执行 kill -TERM 1，观察进程是否在短时间内退出。如果杀不掉，说明应用没有处理 SIGTERM，或 PID 1 是 shell 但信号没有转发。此时可以调整启动方式，让应用直接作为 PID 1。
最后不要忽略退出码与信号编号的对应关系。除了 143 和 137，常见的还有 139 对应 SIGSEGV 段错误、134 对应 SIGABRT 中止信号、141 对应 SIGPIPE。掌握这些数字可以快速缩小故障范围，避免把平台正常停止误判成业务崩溃，也避免把真正的崩溃信号当成普通退出。