状态为何变灰？剖析事件总线漏接与异步锁误用导致的系统分叉

1. 现场还原：状态栏从彩色变成灰色，功能却还在跑

先说说我最初遇到的场景。那天下午测试群突然有人连发消息：某个内部自动化工具在状态面板上的在线标识变成灰色了，可实际上它手里的任务还在正常执行，日志也有心跳，进程没有退出，资源占用一切正常。这种"状态失踪"最折磨人，因为出问题的不是活没干完，而是整个协作系统认为它已经"不在场"了。

我当时第一反应是看部署平台的健康检查，怀疑是探针超时把实例标记成了下线。但翻了一圈，探针返回的是 200，进程没有重启记录，容器也没被调度器摘除。真正异常的只有一处：中心状态存储里这个工具的状态停留在上一次心跳之后从未更新，而工具自己内存里维护的状态却是"运行中"。也就是说，状态不是丢了，而是中心侧和本地侧发生了分叉。

这类问题有个共同规律：凡是需要多个组件协同维护同一份状态，一旦出现不一致，第一怀疑对象就是传递状态的那条链路；第二怀疑对象就是更新状态时用来保证原子性的并发原语。具体到这套系统，状态变更走的是 EventBus 广播，状态计算临界区用的是 asyncio.Lock。于是排查自然分成两条线：

先说结论：这两条线单独看都有毛病，但真正的状态失踪是两个缺陷叠加放大的结果。单纯修事件漏接，或者单纯修锁，都没法彻底复现稳定。下面我把整条排查链路展开讲，包括代码示例和修复方案，方便你直接对照自己的系统。

2. EventBus 漏接线：先发后听，是事件丢失最常见的一种姿势

2.1 先搞清楚"漏接"到底漏在哪一环

EventBus 的原理不复杂，无非是发布者把事件丢到总线上，订阅者在总线上登记自己关心的事件类型，总线把事件分发给对应监听器。但它不是可靠的持久化消息队列，更没有"消费者确认后我才算发布成功"这种语义，一个事件从发布到被监听器真正处理，中间任何一环断了都不会有人提醒你。

出问题后我做了个简单验证：在状态发布函数入口打了一条日志，在中心存储订阅方的处理函数入口也打了一条日志，然后触发一次状态切换。结果非常魔性——发布日志打印了，消费日志没打印。这就排除了"事件根本没发出来"和"监听器处理时抛异常退出了"两种情况，问题精准地落在事件发布时，订阅方还没有完成注册，总线找不到任何监听器，直接把事件当垃圾扔了。

后来看代码，订阅注册和状态发布确实没有先后约束。框架启动时，总线连接和订阅是异步流程，主程序启动完立刻去拉取了一批任务，其中一个任务在几十毫秒内就触发了状态变更。而订阅方的 subscribe 协程还在等待某个初始化锁，等它真正把回调挂到总线上时，第一波状态事件早就发完了。

这种"先发后听"在真实系统里非常隐蔽，因为不是每次都丢。只有状态初始化发生在订阅就绪之前的那一小段窗口才丢，窗口一过，后面再发的事件都正常。于是从表象上看，问题就是偶发的、无规律的、不可控的。

2.2 一个最小化的复现模型

假设总线实现长这样，这并不罕见，很多项目里都有类似的自研轻量总线：

python复制import asyncio
from collections import defaultdict

class EventBus:
    def __init__(self):
        self._subscribers = defaultdict(list)
        self._listeners_lock = asyncio.Lock()

    async def subscribe(self, event_type, handler):
        async with self._listeners_lock:
            self._subscribers[event_type].append(handler)

    async def publish(self, event_type, payload):
        # 注意：读取订阅者列表和调用 handler 之间没有加锁
        handlers = self._subscribers.get(event_type, []).copy()
        for handler in handlers:
            await handler(payload)

再配合状态管理器的初始化代码：

python复制async def bootstrap():
    bus = EventBus()
    state_store = CenterStateStore()

    # 异步订阅：协程被调度，但并不保证立即执行完
    asyncio.create_task(bus.subscribe("tool.state_changed", state_store.save))

    tool = ToolStateManager(bus)
    # 工具启动后立刻上报一次状态
    await tool.report_status("online")

    await asyncio.sleep(1)

如果 asyncio.create_task(bus.subscribe(...)) 还没被事件循环调度到，report_status("online") 已经开始 publish，事件就会落入空集合。很多人会争辩 create_task 在 await 之前通常也会被执行，但注意上面 report_status 内部可能先有自己的异步初始化，时序完全不可控。

2.3 订阅就绪门闩：最直接的修复

对这种场景，我不建议把 subscribe 改成同步阻塞，那会牺牲事件循环的并发性。更稳的做法是引入一个显式的"总线就绪"信号，所有发布者在真正发布前必须等这个信号被置位：

python复制class EventBus:
    def __init__(self):
        self._subscribers = defaultdict(list)
        self._ready = asyncio.Event()

    def mark_ready(self):
        self._ready.set()

    async def wait_ready(self):
        await self._ready.wait()

    async def subscribe(self, event_type, handler):
        self._subscribers[event_type].append(handler)

    async def publish(self, event_type, payload):
        await self.wait_ready()
        handlers = self._subscribers.get(event_type, []).copy()
        for handler in handlers:
            await handler(payload)

然后在启动流程里把所有关键订阅做完后再 mark_ready()：

python复制async def bootstrap():
    bus = EventBus()
    state_store = CenterStateStore()

    await bus.subscribe("tool.state_changed", state_store.save)
    bus.mark_ready()

    tool = ToolStateManager(bus)
    await tool.report_status("online")
    await asyncio.sleep(1)

有 mark_ready() 之前和之后，行为差异一眼就能看到。这里必须强调，subscribe 本身如果设计成异步，也一定先把它 await 完再 mark_ready，不要用 create_task 之后立刻 mark_ready，那等于门闩没装。

2.4 就算就绪了，也不代表永远不丢：监听器异常隔离

门闩解决的是"启动窗口期"的漏接，但 EventBus 还有一种丢法——监听器抛异常，导致后续监听器不执行，或者整个消息循环退出。很多自研总线的 publish 是这样的：

python复制async def publish(self, event_type, payload):
    for handler in self._subscribers.get(event_type, []):
        await handler(payload)

第一个 handler 抛了异常，异常向外传播，第二个 handler 连执行的机会都没有。假如状态存储订阅方排第一个，它写中心库时网络抖动抛错，排在后面的日志收集器、指标上报器全部收不到这次状态变更，表现同样是"状态失踪"。

所以修复要两条腿走路：

python复制async def publish(self, event_type, payload):
    handlers = self._subscribers.get(event_type, []).copy()
    for handler in handlers:
        try:
            await handler(payload)
        except Exception as exc:
            logger.error("event handler failed: event=%s err=%s", event_type, exc)

单点监听器失败不能拖垮整条事件分发链，这个原则和消息队列里的消费者隔离是一个道理。不过异常隔离只是兜底，真出现中心存储写失败，你还需要额外的重试或回源机制，不能光靠打印一条 error 日志就完事。

3. asyncio.Lock 并发线：不是锁不够，而是锁的边界没划对

3.1 从日志时间线看到超时取消

事件线修完以后，启动窗口期的漏接明显少了，但运行一段时间后，状态失踪仍然零星出现。这次我换了思路，不再只看事件日志，而是把状态更新函数的调用栈和等待时间都打了出来。

状态管理器的代码原本是这样的：

python复制class ToolStateManager:
    def __init__(self, bus: EventBus, store):
        self.bus = bus
        self.store = store
        self.state = "unknown"
        self._lock = asyncio.Lock()

    async def update_state(self, new_state: str):
        async with self._lock:
            self.state = new_state
            # 注意：publish 在锁内部执行
            await self.bus.publish("tool.state_changed", {
                "tool_id": self.id,
                "state": new_state,
            })

这段代码乍看没问题。所有状态更新串行化，事件在临界区里发布，绝不会有"状态值已经改了但事件还没发"的中间态。但问题恰恰出在临界区太长。publish 在锁内执行，而 publish 会去调用中心存储的监听器，这个监听器要写网络存储，一次耗时多少完全取决于网络。

某个时刻，协程 A 进入临界区发布事件，中心存储响应变慢，锁迟迟不释放。协程 B 想执行另一条状态更新，在 async with self._lock 处等待。协程 B 的调用方是一个带超时的 HTTP 接口，超时时间设的是 500ms，别问为什么这么短，问就是领导要求接口必须快速返回。500ms 一过，接口层直接取消协程 B 的任务，B 在等锁的过程中就抛出了 CancelledError，本次状态更新压根没进去。

从中心存储的视角看，A 那次变更可能只是把状态从"busy"改成"idle"，B 要把状态改成"error"却因为超时被丢弃，状态就一直停留在"idle"，可工具实际已经处于 error 的故障处理流程中。状态又失踪了——这次不是事件没发，而是用于保护状态计算的锁，把事件发布也一起锁住，导致等锁的人被外部超时杀掉。

3.2 asyncio.Lock 的 acquire 天生没有超时参数

很多人刚用 asyncio.Lock 时会踩一个坑：Lock.acquire() 不像 threading.Lock.acquire(timeout=5) 那样支持超时参数。它的签名是 async def acquire()，要么拿到锁，要么一直等到天荒地老、或者任务被取消。

所以一旦外层有人用 asyncio.wait_for 或框架的请求超时机制，任务在等锁期间被取消是常态。被取消后，如果你的代码没有在 CancelledError 里做清理，可能会出现各种半初始化状态。这里最隐蔽的是：锁等待本身不会破坏数据，但你没法区分任务是因为业务逻辑退出还是因为超时被取消，这在日志里如果不单独打印，排查起来极其痛苦。

我后来的一个习惯是：所有涉及跨协程共享状态的锁，等待处都会包一层显式超时，并且记录等待耗时：

python复制import asyncio
from contextlib import asynccontextmanager

@asynccontextmanager
async def acquire_with_timeout(lock: asyncio.Lock, timeout: float, lock_name: str):
    try:
        await asyncio.wait_for(lock.acquire(), timeout=timeout)
    except asyncio.TimeoutError:
        logger.warning("lock acquire timeout: lock=%s timeout=%s", lock_name, timeout)
        raise
    try:
        yield
    finally:
        lock.release()

超时不是为了让业务更快失败，而是让问题变得可见。你总要知道锁被谁占着，持有了多久，等待了多久，才能定位到是临界区代码太慢，还是并发量真的超出了设计预期。

3.3 三个常见误用：实例不唯一、锁不可重入、临界区跨 await 太久

排查过程中我又顺带扫了一遍代码库里其他 asyncio.Lock 的使用点，发现了三类典型问题。

第一类，锁实例每次调用都新建：

python复制async def update_state(self, new_state: str):
    lock = asyncio.Lock()   # 问题：局部变量，每次新锁
    async with lock:
        self.state = new_state

这把锁保护了寂寞。每次协程进来都拿一把新锁，锁之间互不相识，并发更新照旧乱入。asyncio.Lock 不是值对象，它代表一个共享资源的使用权，必须让所有竞争同一资源的协程看到同一个实例。

第二类，没意识到 asyncio.Lock 不可重入。同一个协程里如果已经持锁，再次 await lock.acquire()，必然死锁：

python复制async def update_state(self, new_state: str):
    async with self._lock:
        await self._update_db_and_broadcast(new_state)  # 内部又试图获取同一个锁

async def _update_db_and_broadcast(self, new_state: str):
    async with self._lock:  # 第二次 acquire，当前协程等自己，卡死
        ...

单线程异步里一旦出现这种锁，别的协程不会被阻塞，但这个协程会永远睡下去。表现出来就是状态更新从某个时间点开始再也没反应。

第三类，临界区跨多个 await 并且内部包含慢 IO。比如在临界区里访问 Redis、发 HTTP、写对象存储，所有等待都会放大持锁时间，导致上游大量协程排队等锁。EventBus 的 publish 如果设计成同步遍历监听器并在锁内执行，等于把一个长事务包进了全局锁，这是设计层面最需要避免的。

我的建议是：asyncio.Lock 最合适的保护范围是内存变量的读改写，不是跨网络 IO 的长时间业务操作。如果你想保护的是"状态值更新 + 事件广播"这个复合操作，那不如把复合操作变成一个独立的串行任务，而不是靠锁在外面卡所有竞争方。

4. 双线交汇：锁和事件各自的缺陷，是怎么共同放大的

4.1 重新推演一次完整的事故时间线

单纯看事件漏接，或者单纯看锁导致取消，都解释不了所有现场。我把两条线合在一起画了张时间线，缺陷的叠加关系立刻清楚了：

1. 系统启动。工具的 ToolStateManager 初始化完成，立刻上报初始状态。此时 EventBus 的订阅方（中心存储）可能还在初始化，事件发布直接丢进空集合。中心存储里没有这个工具的初始状态，这是第一个分叉的起点。
2. 中心存储自身有兜底逻辑：它会周期性地向工具拉取一次全量状态。也就是说，哪怕初始事件丢了，只要后续有周期性同步，分叉也会被修正。
3. 但周期性同步本身也会触发一次状态变更。这次变更已经避开了启动窗口期，EventBus 能正常把事件发给中心存储。坏就坏在，触发变更的协程需要先抢 ToolStateManager 的状态锁，而另一个协程正持锁发布某条慢事件。由于 EventBus 的监听器是串行执行的，其中一个监听器要写数据库并等待网络响应，持锁时间被拉长，处于等待中的同步协程超过外层超时被取消。
4. 于是周期性同步也没完成。中心存储里工具的状态继续停留在旧值。本地侧状态其实已经正常切换过多次，但中心侧完全没有感知。
5. 多次同步失败后，前端显示的"最后在线时间"逐渐过期，最终被判定为离线。整个过程中，工具进程没有崩溃，业务也正常，唯一坏掉的就是那条从本地状态到中心状态的传播链。

这解释了我之前看到的所有现象：为什么本地日志显示状态正常，中心面板却判它失联；为什么修复订阅时序后问题没有彻底消失，因为还有一部分状态变更被锁等待取消拦截在半路。

4.2 真正的设计缺陷：把事件总线当成了状态权威源

复盘时回头看，EventBus 漏接和 Lock 误用都只是表象，更深层的问题是架构设计里没有区分"通知"和"状态存储"。

EventBus 的正确用例是告诉大家"状态可能变了，请自行确认"；但当时的代码把 EventBus 当成了中心存储更新状态的唯一途径——中心存储只会在收到事件时写一次数据，没有主动回源，也没有版本比对机制。只要事件链路任何一环出问题，中心存储就永远停留在旧状态，没有任何自愈能力。

这就像公司里 A 部门更新了员工名单，不直接改人事系统，而是给 B 部门发一封邮件说"名单变了"，B 部门收到邮件才去改系统。邮件丢了，名单就永远不对。正常做法应该是人事系统本身有权威名单，邮件只是通知，B 部门发现名单对不上时有权随时去人事系统拉最新版。

后面我重构这套逻辑时，给每个状态都加了一个单调递增的 version。本地状态管理器每次变更，版本号加一。中心存储不再被动依赖事件总线，而是每次收到事件后拿事件里的 version 和本地存储的 version 做比较，如果事件里的版本比本地低，说明可能漏了中间状态，直接触发一次全量拉取。事件丢失不再需要零容忍，因为状态同步多了一条回源兜底路径。

python复制class CenterStateStore:
    def __init__(self):
        self._state_by_tool = {}
        self._version_by_tool = {}

    async def on_state_event(self, event):
        tool_id = event["tool_id"]
        new_version = event["version"]
        local_version = self._version_by_tool.get(tool_id, 0)

        if new_version <= local_version:
            # 重复事件或乱序事件，直接忽略
            return

        # 版本出现跳跃，说明中间有事件丢失，回源拉一次最新状态
        if new_version - local_version > 1:
            await self.pull_full_state(tool_id)
            return

        self._state_by_tool[tool_id] = event["state"]
        self._version_by_tool[tool_id] = new_version

这段代码的核心思想是：状态变更的真相只能由一个权威来源决定，事件总线负责高效传播变更通知，但如果传播链路出现缺口，系统必须有能力自己发现缺口并回源补上。

4.3 测试验证：模拟并发翻转 1000 次

代码改完后，我写了个压力测试，场景是同时跑 10 个协程，共同向同一个 ToolStateManager 发起 1000 次状态翻转，每次翻转之间随机 sleep 几毫秒，中心存储模拟为一个只通过 EventBus 接收状态的监听器，并在每 200ms 触发一次网络抖动。

改动前的结果是：中心存储的最终状态与本地状态不一致的概率非常高，日志里能同时看到"发布成功但无人消费"和"等待锁超时被取消"两种错误痕迹。改动后的结果是：状态最终一定一致，即便存在事件丢失，也会在下一个事件到达时通过版本跳跃检查触发回源；就算某段时间完全没有事件到达，周期性的回源任务也能保证最终收敛。

这里有个关键点：只加版本号不够，回源任务必须真的存在。如果事件一直丢失，而周期回源任务又依赖 EventBus 触发，那等于没有兜底。正确做法是回源任务走 REST/HTTP 直连，独立于事件总线之外。

5. 修复落地清单：如果重写一次，我会怎么设计

5.1 事件总线层的三个强制要求

第一，发布前必须等待所有关键订阅注册完成，用 asyncio.Event 做门闩，而不是依赖启动顺序的巧合。第二，监听器执行必须异常隔离，单个监听器的故障不能影响同事件的后续监听器。第三，所有事件必须携带源端 version，接收方不得盲目覆盖，先比较版本号，再决定是更新还是回源。

下面这个是简化版的 EventBus 实现，把上面三点都融进去了：

python复制import asyncio
import logging
from collections import defaultdict

logger = logging.getLogger(__name__)

class ReliableEventBus:
    def __init__(self):
        self._subscribers = defaultdict(list)
        self._ready = asyncio.Event()

    def mark_ready(self):
        self._ready.set()

    async def subscribe(self, event_type, handler):
        self._subscribers[event_type].append(handler)

    async def publish(self, event_type, payload):
        if not self._ready.is_set():
            await self._ready.wait()

        for handler in self._subscribers.get(event_type, []):
            try:
                await handler(payload)
            except Exception:
                logger.exception("subscriber handler error: event_type=%s", event_type)

实际业务线里，publish 前还要检查订阅者数量，如果关键事件发布时一个订阅者都没有，应该直接报警，而不是默默丢弃。这能帮你早一步发现订阅注册漏了，而不是等到状态分叉。

5.2 状态管理层的推荐方案：从锁演进到单一订阅队列

对于"状态值更新 + 事件广播"这类复合操作，用 asyncio.Lock 强行串行只适合非常简单的场景。一旦临界区里掺杂网络 IO、事件监听器、外部存储调用，锁的等待和取消就会变成排查黑洞。

我更推荐把状态管理器改造成一个独立的 Actor：所有外部请求往队列里提交状态更新命令，只有一个消费者协程从队列里取命令并按序执行，天然串行，不需要锁。

python复制class StateActor:
    def __init__(self, bus: EventBus):
        self._bus = bus
        self._queue = asyncio.Queue()
        self._state = "unknown"
        self._version = 0
        self._task = None

    async def start(self):
        self._task = asyncio.create_task(self._run())

    async def submit_state(self, new_state: str):
        # 外部只投递，不等待结果
        await self._queue.put(new_state)

    async def _run(self):
        while True:
            new_state = await self._queue.get()
            self._version += 1
            self._state = new_state
            await self._bus.publish("tool.state_changed", {
                "tool_id": self.id,
                "state": self._state,
                "version": self._version,
            })

为什么队列比锁更适合这个场景？因为队列天然接受任务取消。外部协程投递任务后自己等超时被取消，不影响队列里的任务；消费者协程仍在按序处理状态更新。但用锁的方式，外部协程被取消的同时，如果它已经持有了锁，那还得处理好锁释放问题——一个 await 过程被打断时，async with 能释放锁，但如果你用自定义的获取锁流程，极容易在 finally 里漏掉 release，造成永久死锁。队列避免了锁的整个生命周期管理复杂度。

队列方案的代价是状态更新的实时性：从提交到生效之间多了排队时间，但大多数场景下的状态切换根本不需要纳秒级实时。如果确实需要更强的实时性，再考虑锁 + 短临界区的组合。

5.3 状态同步的兜底：回源比任何事件重放都可靠

事件总线设计得再好，也不可能 100% 保证不丢消息。网络抖动、进程重启、bug 导致的静默丢弃，这些都存在。所以状态同步系统里必须有没有事件总线也能运转的兜底路径。

我在项目里加的兜底路径，是一个独立的定时任务，每隔 10 秒从本地状态管理器直接拉取全量状态快照，和中心存储做比对。不是等事件丢了才回源，而是定期强制拉齐一次。这个任务的频率可以根据状态重要性调整，但不建议关闭。事件总线负责秒级响应，回源任务负责最终一致，两者互补。

从成本角度看，如果中心存储的状态只用于展示和告警，10 秒级别的延迟几乎无感。定时回源又是最简单的实现，不用做复杂的消息重放。我后来在好几个项目里都沿用了这个套路，不管用的是什么事件框架，状态类数据的底座永远是"定时全量对比 + 事件被动更新 + 版本号防乱序"。

6. 复盘方法论：状态消失类问题，照着这个顺序查能少走弯路

6.1 第一步永远是区分消失在哪一层

遇到"状态失踪"，别急着怀疑代码，先回答三个问题：

• 本地进程视角，状态真的变了吗？
• 事件总线视角，事件真的发布成功了吗？
• 中心存储视角，数据真的被更新了吗？

这三个答案组合起来基本能锁定方向。本地没变，查状态计算逻辑；本地变了事件没发，查发布路径和锁；事件发了存储没更新，查订阅注册、监听器执行、版本比对。用这种分层排查法，比漫无目的地翻日志高效得多。

6.2 链路里的每个异步环节都要有序列号和确认机制

我原来总觉得系统内部的事件不用做得像消息队列那么重，后来发现不行。状态变更这种数据，本地侧、总线侧、存储侧三方都需要一个共同的参照物来判断自己有没有落后，序列号就是最简单的参照物。

发布方给事件加自增版本号，订阅方记录已经处理到的版本号，两边的版本号对上才能说明分叉不存在。一旦出现版本跳跃，立即走回源拉全量。这不是什么高深理论，就是借鉴了 TCP 序列号和消息队列 consumer offset 的思路，在进程内同样是有效的。

6.3 asyncio 并发排查的铁律：先看取消点，再看锁等待

在 asyncio 环境里排查并发问题，有一个和线程环境完全不同的重点：线程问题往往是数据竞争，异步问题更多是协程在某个 await 点被打断后留下半成品状态。锁等待超时导致任务被取消，存储写入写到一半被取消，事件发到一半被取消，这些都属于典型的取消点问题。

所以排查时先找出代码里所有 await 的位置，看看每个 await 前后状态是否一致；再查锁的获取和释放有没有被 asyncio.wait_for 包住，包住的超时时间是否合理；最后在日志里把所有 CancelledError 的堆栈打印出来，看看取消到底发生在哪个 await 上。这一步能过滤掉大半无头绪的并发 bug。

6.4 给可观测性加两件趁手的工具

第一件，给每次状态变更生成一个 trace_id 并且贯穿到事件监听器的日志里。没有 trace_id，你根本没法把发布日志和消费日志对应起来，只能靠时间猜，效率极低。

python复制async def update_state(self, new_state: str, trace_id: str):
    self._version += 1
    logger.info("state update: tool=%s from=%s to=%s version=%s trace=%s",
                self.id, self._state, new_state, self._version, trace_id)
    await self._bus.publish("tool.state_changed", {
        "tool_id": self.id,
        "state": new_state,
        "version": self._version,
        "trace_id": trace_id,
    })

订阅方处理时把这同一个 trace_id 打到自己的日志里。排查时只要拿 trace_id 一搜，整条链路谁处理了、谁没处理、处理到哪一步挂了，一目了然。

第二件，准备一个状态快照对比脚本。它能直接连接本地状态管理器和中心存储，拉出两个侧的状态快照逐字段比对，并把差异打印成结构化结果。整个状态失踪事件，我之前手工拉日志比对了半小时，后来写成一个脚本只需几秒就能定位到是哪个字段、哪一侧发生了分叉。这些小工具看起来不起眼，关键时刻能救全组人的命。

线上问题排查到最后一层，你会感受到一个很朴素的道理：分布式也好，异步并发也好，真正可靠的状态同步只有一条准则——所有参与者认准唯一的事实来源，用版本号判断新旧，用定期回源兜底一切丢失，事件总线只负责让这个事实更快被大家知道，而不是成为事实本身。

回到那个工具状态失踪的 Case，我最后没有去责怪任何人，因为代码里那两个 bug 单独看都很像"正常写法"。可生产环境不会在乎你写的时候觉得它正不正常，它只在某个凌晨把问题还给你。后来我带团队做状态类功能评审时，总会多问一句：如果事件总线一条事件都没发出去，你的状态能自愈吗？能拿出这个答案的系统，才有资格说自己状态是可靠的。