号码停止工作：如何找出原因
已连接号码停止工作时，原因几乎从来不是代码。请按发生频率依次排查：访问令牌过期、重新连接后丢失 Webhook 覆盖设置、14 天不活跃导致断开连接、质量下降，最后是账户限制。
为什么手机上看不出任何问题？
因为 WhatsApp Business 应用和 API 是同一个号码上的两个独立界面，几乎所有故障只会影响其中一个。
访问令牌过期，但应用不受影响。Webhook 覆盖设置被卸载，但应用不受影响。质量下降，但应用不受影响。每种情况下，企业仍能回复客户，看到正常行为，也没有理由报告问题。
这正是应该进行监控，而不是依赖有人查看控制台的原因。故障确实存在，却没有明显提示，而最接近该号码的人反而最不容易注意到。
应该按什么顺序检查？
先检查访问令牌，因为这是最常见、修复成本最低的问题。过期或失效的凭据会让每次请求以相同方式失败，看起来就像号码已被移除。针对同一账户保留第二个凭据，才能区分这两种情况。
然后检查 Webhook 覆盖设置。如果发生过重新连接，目标设置会随应用一起被卸载，因此发送和监控仍然有效，但消息不会显示任何提示地无法送达您的服务器。
然后检查断开连接：account_update 事件会带有 PARTNER_REMOVED 和原因；其中 PRIMARY_INACTIVITY 表示应用大约 14 天未被打开，重新连接即可修复。
接着检查质量。质量是通过轮询获取，而不是主动推送。最后检查限制，这是提供商无法解除的账户级强制措施。
几乎从来不是什么原因？
如果代码昨天还正常运行，而且没有部署，那么通常不是您的代码。
Cloud API 很稳定，请求格式不会在您毫不知情的情况下改变。当运行数月的集成突然停止时，最可能的原因是凭据、路由变化或账户级事件，这些都可能在无人修改代码库的情况下发生。
唯一值得特别提到的例外，是有人编辑了模板。改变模板中的变量数量，会悄悄改变每个发送方所使用的约定，看起来像代码故障，但其实是其他人在 WhatsApp Manager 中修改了内容。
常见错误
- 先重新连接号码。如果是访问令牌过期，这会让企业负责人进行完全不必要的操作。
- 认定是代码出错。API 稳定且没有部署，问题通常在其他地方。
- 检查手机上的症状。几乎所有这些故障发生时，应用仍可正常工作。
EasyCoexistence 持续检查这 5 项，并在连接时间线中分别记录，因此排查可以从带日期的事件开始，而不是靠猜测。
常见问题
号码在手机上能用，但什么都发不出去。我该从哪里开始？
先检查访问令牌。这是最常见的原因，也最像号码已被移除。
我重新连接了，但消息仍未送达服务器。
Webhook 覆盖设置随应用一起被卸载了。必须重新应用，我们会自动处理。
如何知道是不是 14 天规则导致的？
断开连接会在 account_update 事件中带有原因 PRIMARY_INACTIVITY。
编辑模板会导致消息发送失败吗？
会，而且这是最像代码故障的原因。改变变量数量会改变每个发送方使用的约定。
继续阅读
准备开始了吗？
几分钟即可设置 WhatsApp Coexistence，而不是几个月。应用会继续在手机上运行。
开始免费试用验证时间