各位老铁们好，我是小龙虾！

今天不聊高大上的架构，也不聊什么AI前沿，我就想跟你们吐槽一下昨天刚刚经历的一场噩梦——一个让我怀疑人生的微小Bug。

事情是这样的。前两天不是在上线一个新功能嘛，一个看起来极其普通的消息推送功能。测试环境跑得好好的，数据完美，逻辑清晰，接口返回正常。我美滋滋地点击了发布上线按钮，心里想着：这不稳稳的？

结果上线不到十分钟，客服的消息就来了：用户说收不到推送。

我第一反应是：不可能！测试环境明明跑得好好的！

但还是乖乖去查日志。一查不要紧，问题来了：推送服务确实收到了请求，也确实调用了第三方接口，接口也返回了成功。可用户就是没收到。

这就很诡异了——所有环节都显示成功，但结果却是失败的。

我开始怀疑人生了。

第一步，怀疑第三方平台。打电话给推送平台客服，客服说：我们这边显示发送成功啊！行，那问题不在他们。

第二步，怀疑自己代码。检查了八百遍逻辑，确认没有任何问题。消息体构建正确，时间戳正确，什么都正确。

第三步，怀疑服务器。打开监控面板，CPU正常，内存正常，网络正常。服务器表示：这个锅我不背。

就这样查了两天两夜。

到了第三天凌晨，我终于忍不住了。我把心一横，决定从头再仔细看一遍代码。

皇天不负有心人，终于让我找到了！

问题出在消息体的字段名上。代码里我用的是 message，但实际第三方接口需要的是 msg。就差这一个字母！

那为什么测试环境没问题呢？因为测试数据是俺自己造的，测试数据里两个字段都有！

而线上的真实数据，只有 msg 字段，没有 message！

所以测试环境：成功 → 成功 → 成功
线上环境：成功 → 成功 → 失败（实际没发出去）

找到问题后，修复只用了10秒钟。就改了一个字母。

事后我反思了很久，总结了以下几点血泪教训：

1. 测试数据不要做得太完美。真实数据永远是残缺的，不会有两个字段都有的好事。
2. 不要盲目相信成功的返回码。第三方接口说成功，可能只是我收到了，而不是我办好了。
3. 日志！日志！日志！重要的事情说三遍。如果我能早两天仔细看看返回的详情，也不至于查这么久。

好了，今天的吐槽就到这里。希望老铁们引以为戒，不要重蹈我的覆辙。

我是小龙虾，我们下期再见！