# SC000：优雅关闭验证通过

> SC000（优雅关闭验证通过）是检查通过的结果：说明 shutdown-check 证明了服务的哪些行为、没有覆盖什么，以及如何在 CI 中持续运行。

Source: https://shutdown.jscrate.dev/zh/docs/codes/sc000
Last updated: 2026-09-23

`SC000` 表示按配置检查的优雅关闭（graceful shutdown）行为全部通过：进行中的请求都已完成，进程在截止时间前正确退出，端口也不再接受连接。

| | |
| --- | --- |
| 诊断码 | `SC000` (PASS) |
| 阶段 | 通过 |
| CLI 退出码 | 0 |
| 含义 | 每个进行中的请求都以预期的响应结束，服务在截止时间前以预期的退出码退出，并关闭了端口。 |
| 输出信息 | `Graceful shutdown verified` |
| 首先检查 | 无需修复。把检查保留在 CI 中，一旦出现回归，构建就会失败。 |

## 这次测试证明了什么？

服务通过了配置中启用的每一项检查：

1. 启动前，测试端口是空闲的。
2. 服务成功启动并进入就绪状态。
3. 发送 `SIGTERM` 前，测试请求已在进行中。
4. 每个进行中的请求都返回了预期的状态码和响应体。
5. 进程在截止时间前以预期的退出码退出。
6. 进程退出后，端口已关闭。

如果你启用了撤回就绪状态、拒绝新请求或重复发送信号，这些检查也都通过了。

## 测试没有证明什么？

结果只覆盖配置里的路由和条件。它不验证数据库写入、队列消费者、WebSocket、HTTP/2 流，也不验证 HTTP 响应返回后仍在继续的工作。它同样不测试 Kubernetes 的 endpoint 传播，也不测试容器的 `preStop` 钩子。

选一个能代表真实慢操作的测试请求，并把测试保留在 CI 中，这样关闭行为一旦出现回归，在部署前就会失败。

## 怎样让这个结果一直有参考价值？

路由、启动命令或平台的截止时间有变化时，重新检查配置。如果测试请求变得快很多，或者部署的入口换了，测试可能仍然通过，却已经不能代表生产环境。

在 CI 中保留完整的时间线或 JUnit 报告。正常通过时，时间线的顺序是：`SIGTERM` 之前工作已在进行，之后响应完成，然后进程退出，最后才是 `shutdown verified`。

## 相关内容

- [了解每个阶段](https://shutdown.jscrate.dev/zh/docs/how-it-works)
- [选择贴近真实的测试请求](https://shutdown.jscrate.dev/zh/docs/in-flight-work)
- [在 CI 中运行测试](https://shutdown.jscrate.dev/zh/docs/ci)
- [兼容性与限制](https://shutdown.jscrate.dev/zh/docs/compatibility)