发布后的冒烟集
每次发布或重启后跑一套固定的最小用例：健康端点、模型列表、非流式对话、流式对话、长上下文、并发小压。全部通过再放量，任何一项失败就停止并进入回退。用例固定、每次都跑，结果才有可比性。
基本信息
| 用例数量 | 固定六项左右 |
|---|---|
| 通过标准 | 全部通过才放量 |
| 失败处理 | 停止放量并保留现场 |
| 执行方式 | 脚本化，纳入发布流程 |
| 关键 | 用例固定不随意改 |
典型使用场景
- 每次发布后的自动验证
- 实例重启后的自检
- 新环境首次上线的确认
- 把人工检查替换成可重复的脚本
- 把冒烟脚本纳入发布流水线，失败即阻断继续发布
冒烟命令
冒烟命令
curl -sf http://127.0.0.1:8000/health && echo OK
curl -s http://127.0.0.1:8000/v1/models | head -c 200
curl -s http://127.0.0.1:8000/v1/chat/completions \
-H 'Content-Type: application/json' -d @smoke.json | head -c 300
# 同一套用例每次发布都跑，结果留档对比六个用例各验证什么
| 用例 | 验证什么 | 失败说明 |
|---|---|---|
| 健康端点 | 进程可用 | 启动即失败 |
| 模型列表 | 模型已加载 | 权重或目录问题 |
| 非流式对话 | 基础链路 | 核心功能异常 |
| 流式对话 | 分块与结束标记 | 缓冲或代理问题 |
冒烟集要脚本化并纳入发布流程：手工清单容易被跳过，脚本化才能保证每次发布都真的跑过。
用例保持稳定：频繁修改会让历史结果失去可比性，需要新增时另起一份扩展集。
用例要覆盖鉴权与错误路径：只测正常请求，鉴权配置改错要等业务方来发现。
并发小压要有明确的通过标准：多少并发、持续多长时间、延迟与错误率各是多少，标准写清才可判定。
记录每次冒烟的输出摘要：出问题时能对比这次与上次的差异，比重新试一遍快得多。
冒烟结果与版本号一起留档：事后回看某次发布是否健康时，这是最直接的依据。