记一次使用共享单车的糟糕体验，讨论一下从业务流程上如何避免此类事故的发生

事件经过

今晚下班打算骑共享单车回家，但是未能成功开锁，在一段时间的等待后，APP 提示网络错误。

看到周围很多人也在扫该品牌共享单车，但是无一成功，看来是单车服务出现了故障，于是我打算改为步行回家。然而步行十分钟以后，再次打开 APP，发现我的状态是骑行中。没办法，只好折返去找那辆车，但不出我所料，那辆车已经不在原地了，大概率是被别人骑走了。

于是我在 APP 中寻找相应问题的处理流程，但是没有找到。最接近的选项是 "扫码锁未开但已开始计费"，这个选项会将我带到报修页面，但报修提交后仍需要手动关锁，且 "强制关锁" 选项仅用于处理 "关锁后未结束计费" ，并要求对有问题的锁环拍照。

这种情况下，人工客服介入是很有必要的。但 APP 里并没有接入人工客服的入口，机器人客服也只能展示那几个常见的问题选项。此时，问题陷入了一个死局，摆在面前的只有一条路，强制关锁，上传报错截图，并说明问题。但这个操作是不规范的，实际上并没有关锁，审核人员多半不会相信我的说辞，判定为忘记关锁，面临高额罚款的同时，还有可能影响个人信用。到时候想要维权也很难举证。即使是调路边摄像头，也不一定看得出锁开没开。

不知不觉中，一个多小时过去了，正在我准备点强制关锁时，APP 提示骑行结束。应该是骑走这辆车的人关了锁。此次事故有惊无险地结束了，但它浪费了我宝贵的休息时间，也暴露出了该品牌单车业务上存在的缺陷。

问题分析

事故发生后应该有所思考，是什么导致了事故的发生。如果我要搞共享单车的开发，我又应该如何避免此类事故的发生呢？

第一种可能：开锁请求失败，但用户点击 "我知道了" 之后，客户端又自动重新尝试发起请求。后续的请求成功，车开锁。这种业务流程显然是不合理的，我认为这种规模的公司不会犯这样的低级错误。

第二种可能：请求是异步的。先发起开锁请求，然后不断轮询，等待服务端更新开锁状态。开锁的请求发送成功，但由于某些原因，后续的轮询请求没有得到服务端的及时响应。而由于车锁没有打开，说明单车没有收到服务端的开锁请求，这有可能是因为网络故障，有可能是开锁请求还在消息队列中排队，也有可能两者都是。但一段时间后，服务恢复正常，车锁成功打开，客户端也成功从服务端得到了状态更新。

解决方案讨论

虽然不是内部人员，不了解实现细节，但大致可以认为是上面说的第二种可能。基于这种假设，我认为从两方面可以改进：

首先是客户端的文案。当告知用户 "开锁失败"，应该意味着客户端和服务端都已经确认了这次失败，用户可以选择放心地离开去做其他的事情，或者重新尝试开锁。所以如果开锁的请求成功，但在轮询开锁状态时没有得到服务端的响应，应该告诉用户 "服务忙，请耐心等待"，同时页面应保持不可交互，直到服务端响应。这样，用户知道自己的操作处于一个中间状态，过一会儿车锁可能会开，因此会更多地选择等待，而不是离开。

其次，服务端也应该考虑到这样的特殊情况。消息队列中的消息时效应该合理设置。现实中没有人会愿意为一辆共享单车等好几分钟，所以当一条开锁的消息在队列中积压了超过一分钟甚至半分钟未被消费（如果有消费失败重新入队的机制，这个起始时间应该从首次入队算起），就应该抛弃掉。

如果上面这两件事能做好，基本上就不会出现锁开了而人不在的情况。

有关客服

好歹也算半个大厂，竟然连人工客服的入口也没有。当年用过的其他几款现在已经凉了的共享单车，虽然排队时间长，服务质量也参差不齐，但至少可以接入人工客服。在遇到无法自助处理的紧急问题时，不至于陷入僵局。