Petlibro的Granary 2智能喂食器，官网标价120美元，卖点就一句话：出差上班也能让猫按时吃饭。这周这句卖点直接崩了——一次App后端故障，让不少用户的喂食计划要么没执行、要么迟到、要么重复喂了两遍。一位Reddit用户说得很直接：“我已经失去信任，而且马上要出门旅行，没时间再找新方案了。”
比故障本身更值得琢磨的是官方的说法。Petlibro从头到尾都在强调，设备本地保存的喂食计划应该照常离线运行，断网不该影响喂食。可现实是，大量用户反馈自己的猫饿了整整一个上午，这句承诺和用户实测之间，出现了一道很难忽视的裂缝。
断了近40小时，官方说“已恢复”
按Petlibro官方状态页的说法，故障从8月11日凌晨5点左右开始，公司先是承认“部分用户访问App或远程控制设备有困难”；当天晚上7点，官方说“识别到服务问题”，开始恢复；到8月12日晚7点，官方宣布App服务“已全面恢复并正常运行”。前后差不多近40小时。
官方还留了一句免责声明：故障期间产生的部分记录，包括设备操作历史、喂食/猫砂盆记录、通知、云端视频，可能永久无法找回。这句话本身就说明，这次不是小范围抖动。
“本地照常喂”这句承诺，为什么没兑现
Petlibro产品页写得挺明白：Granary 2断网后，App远程控制会失灵，但“喂食计划会继续自动运行”；One RFID的页面也写着“网络错误期间，计划喂食照常进行”。这是厂商对“离线兜底”做出的明确产品承诺。
但Reddit上的说法完全不是一回事。有人说设备整个故障期间一次没喂，有人说喂了一部分漏了一部分，还有人说喂食时间明显推迟。CEO York Wu对The Verge的回应是，计划本该直接写在设备上、不需要联网指令也能跑，但公司“注意到部分客户设备表现不符合预期，正在逐案审查”。
这句话翻译一下就是：官方也说不清为什么本地兜底没兜住。合理的猜测是App后端故障连带触发了固件或软件层面的问题，也可能是设备判断“在线/离线”状态的逻辑本身出了错——但Petlibro至今没有公开完整事故复盘，也没有确认或排除固件原因。故障表现还不统一，不是所有设备都中招，这更像是特定固件版本或绑定逻辑的问题，而不是单纯服务器宕机那么简单。
云端说“已恢复”，饭碗那头未必跟着恢复。
同样断网，差距在设计里
同类产品在离线这件事上的思路并不一样。PetSafe的Smart Feed第二代官方说明，断网状态下会按已有计划继续喂食，还支持D型电池作为断电备用；Whisker的Feeder-Robot说明书写得更直接，喂食计划存在设备本地，可以直接用物理控制面板编程，压根不完全依赖App或云端。
差别不在营销话术，在工程实现：本地存储是不是真的“自主运行”，还是仍然要靠App周期性确认状态才敢执行。Petlibro这次暴露的问题，恰恰是后一种——设备看起来离线可用，实际运行逻辑可能还挂着一根看不见的网线。
- 风险.出差、独居宠物这类“无人值守”场景，一旦厂商云端出问题，用户往往要等几小时甚至一天才发现宠物没吃上饭，且部分用户反映没收到任何故障通知。
技术意义上的“incident resolved”，和用户意义上的“宠物没挨饿”，从来不是一回事。Petlibro可以说App服务已经全面恢复，但没法替那些错过的一顿饭道歉，也没法把丢失的喂食记录找回来。古人说“民以食为天”，放到宠物身上，这句话一点不夸张——喂食这件事，最不该是那种“服务器好了就等于没事了”的问题。
如果真要为宠物选一台“出差也放心”的喂食器，看App好不好用是次要的，先问一句：断网之后，它到底能不能自己转起来。这次Petlibro给出的答案，暂时是不能。