修改两个服务之间的消息：为什么要先上线消费者

事件驱动系统里的经典问题：有人在后台修改了一条记录，但改动始终没有同步到客户端。两个服务都在运行，队列也正常，错误日志里什么都没有。下面是我排查这类问题的方法，以及避免它再次发生的规则。

在每一跳都找到证据

追踪数据，而不是代码：API 请求、数据库记录、队列里的消息、消费者、第二个数据库。在未修改的代码上、按每个服务锁定的依赖版本复现问题。本地用了更新版本的共享库，很可能会“证明”一个错误的结论。

有一次，字段其实被丢了两次：生产者只转发了改动字段中的一个，而消费者的消息模型本来也会拒绝其余字段。只修一边，代码评审时看起来没问题，上线后仍然会失败。

严格的消费者要先上线

如果消费者对消息做严格校验，而生产者先开始发送新字段，消费者就会拒绝它看不懂的消息。如果它在校验失败时仍然确认（ack）了消息，这些消息就直接消失了。所以顺序是：先更新并部署消费者，让它能接受新的消息格式，再部署发送新格式的生产者。共享库要先打标签发布，再上线使用它的服务。

小心“回声”

当两个系统双向同步时，一次更新可能被反弹回来，用旧值覆盖原本的修改。记录每次改动的来源，并确保服务不会把刚收到的数据再发回去。

把部署顺序写下来

写进工单里：哪个服务先上、用哪个库版本、需要调整哪些权限或配置。测试和负责部署的同事不应该再自己摸索一遍。两行字的说明，能避免两个小时的事故。