简要定义
状态回答”现在能不能用”，事件回答”为什么变成这样”。排查时把它们放在一起读，才能区分输入错误、执行失败、健康检查失败和访问层未就绪这几种完全不同的情况。
为什么存在这个概念
只看当前状态无法判断”是刚开始变差还是已经稳定在这个状态很久了”。事件时间线提供了变化的因果链，配合当前状态一起看，才能判断应该继续等待、直接重试，还是需要回滚。
常见信号对照
| 你看到的信号 | 先检查 |
|---|---|
| 部署失败但旧版本仍可访问 | 新部署的事件、构建日志、健康检查 |
| 运行时健康但域名不可访问 | 代理状态、DNS、TLS 证书、路由规则 |
| 预览页面不存在 | Pull Request 状态、预览清理事件、部署产物 |
| 状态长时间停留在 pending | 运行中的任务、服务器连接、最近一次事件时间 |
如果状态和事件看起来互相矛盾，以事件时间线确认最后一次变化到底改变了什么，再决定是等待、重试还是回滚。
在 Web / CLI / API 中的体现
# 查看部署当前状态
appaloft deployments show <deploymentId>
# 跟随实时事件时间线
appaloft deployments timeline <deploymentId> --follow --json排查顺序
- 找到当前对象 — 先确认你在看的是项目、环境、资源、部署还是预览环境。不同对象的状态可能不同，不要把预览的失败当成生产环境失败。
- 读取最后一次变化 — 查看最新事件的阶段、时间和错误码。如果最后事件只是”已接收请求”，说明任务可能仍在运行；如果最后事件已经是失败，进入恢复流程。
- 对照健康摘要 — 事件解释历史，健康摘要解释当前观察结果，两者要一起看。
- 记录恢复证据 — 重试或回滚前记录失败状态、错误码、相关日志和访问地址，恢复后用同一组信息确认状态确实改变了。
常见误区
- 把
pending当成卡死：DNS 刚修改、部署刚提交时出现短暂的pending是正常的，先看最近事件时间再判断。 - 忽略预览环境和生产环境的区别：预览环境的失败不代表生产环境有问题，反之亦然。