去年三月，项目我们给一个连锁餐饮品牌做门店巡检系统。经验客户一开始的分享范文需求文档写了四十多页，核心诉求就一句话：让区域经理用手机拍照上传，项目后台能看报表。经验听起来简单得像个周末项目。分享范文结果上线那天，项目区域经理老周在电话里骂了十分钟——他站在后厨冷库里没信号，经验拍完照点了上传，分享范文转圈转到手机发烫，项目最后弹出一行红字：网络请求超时。经验

问题出在我们太迷信“移动端优先”这个说法。分享范文客户总部在写字楼，项目WiFi稳定，经验测试时一切顺畅。分享范文可门店后厨、仓库、地下冷库，信号盲区多得超出想象。更麻烦的是，老周们习惯一次巡检拍二三十张照片，等走到有信号的地方再统一上传。我们的设计是即拍即传，每张照片单独发请求。冷库里没信号，请求全堵在本地队列里，一恢复网络就并发几十个请求，服务器直接限流。

后来改了两点。一是照片先存本地IndexedDB，攒够一批再打包上传，压缩到原来体积的三成。二是加了个手动“同步”按钮，老周可以自己选时机。这个改动没写在需求文档里，是跟着老周跑了四家门店后蹲在后厨地上想出来的。有时候用户说不清楚自己要什么，你得去他干活的地方站一会儿。

项目中期还遇到个数据一致性的坑。区域经理提交巡检记录后，总部后台会生成整改单，推给店长。店长在另一个App里确认整改，状态回写。有次网络抖动，整改单生成了，但回写状态失败，店长那边显示“待处理”，后台却标记“已完成”。两边数据打架，客服电话被打爆。我们查了两天日志，发现是消息队列重试机制没做好幂等。同一个整改单号被消费了三次，状态覆盖来覆盖去。

解决方式不复杂，给每个操作加唯一流水号，数据库层面做去重。但暴露出的问题是，我们一开始把“最终一致性”想得太理想化了。餐饮门店的网络环境，丢包、延迟、断连是常态，不是异常。后来所有跨系统状态同步都加了补偿任务，每十分钟扫一次不一致的记录，自动修复。这个补偿任务上线后，客服相关投诉降了七成。

还有个小细节。店长确认整改时，需要填一段文字说明。很多店长直接写“已改”两个字。总部那边觉得信息不够，要求至少二十个字。我们加了个前端校验，结果店长们开始写“已经改好了改好了改好了”凑字数。后来改成下拉选项加可选备注，店长选“已整改”“部分整改”“无法整改”，备注非必填。数据质量反而上去了。强制填文字不如给几个靠谱的选项。

项目最后延期了两周，预算超了百分之十五。客户没扣钱，因为老周在验收会上说了一句话：“现在我在冷库里拍完照，走出来点一下同步，喝口水的功夫就传完了。”这句话比任何测试报告都管用。

回头看，这个项目教会我的不是某个技术点，而是一个挺朴素的道理：别在会议室里猜用户怎么用系统。去现场，看他们手怎么拿手机，看他们在哪停顿，看他们骂什么。那些骂声里藏着真正的需求。代码写得再漂亮，抵不过后厨没信号时的一个转圈图标。