一个看似不起眼的BUG最近在开发米家生态24G毫米波雷达产品时遇到一个隐蔽的BUG。开发阶段一切正常因为测试时手机与服务器时间基本同步。直到米家实验室反馈复现视频我们才意识到问题。米家实验室BUG复现在视频的3~4秒之间米家APP也有类似现象我们原以为这只是插件开发的问题直到后来测试发现米家APP本身也存在同样的时差现象。比如在APP的卡片列表中状态数据在时差大的手机上不会变化或变化不同步。在插件中订阅APIDeviceEvent.deviceReceivedMessages.addListener也不会有反应。时差问题在IoT场景中远比想象中普遍。连官方APP在某些边界情况下都会出现类似表现我们作为开发者更需要在设计之初就把这类异常场景纳入考量。原型机与商业化的差距这个BUG让我深刻体会到原型机可以快速完成功能验证但原型机在商业化过程中还有很长的路要走。原型机阶段我们关注的是“能不能实现功能”。BLE连接、毫米波雷达检测、米家网关上报、手机端展示——链路打通了demo跑起来了就认为“OK了”。但商业化阶段关注的是“在各种真实场景下能不能稳定工作”。真实用户不会像开发环境那样时间同步不会像测试环境那样网络稳定不会像实验室那样环境理想。鲁棒性被忽视的成本鲁棒性问题引发的成本是非常多人和公司忽视的。这个60秒的“补丁”看似简单但背后是问题定位、复现、修复、回归测试的全流程。如果问题更复杂比如网络异常、设备离线、数据丢失等场景成本会成倍增加。很多团队在原型机阶段投入大量精力追求功能创新却对鲁棒性投入不足。结果就是产品发布后线上问题不断客服压力巨大用户口碑受损最终商业化失败。结语从原型到商业化每一个BUG都是对产品鲁棒性的考验。这个“闪跳”问题虽然简单但提醒我们真实世界永远比实验室复杂。