我在12306上发现了候补订单的缺陷，如果我要优化？

12306大家再熟悉不过了，一个作为承载亿级流量的国家基础设施，每次打开必须在‘完美体验’与‘系统稳定’间做残酷取舍：修复低频小概率事件的边际成本极高，而贸然整合独立外挂系统可能动摇高并发下的稳定性根基。产品没有绝对的完美，只有基于商业逻辑与现实约束的最优解——盈亏本同源，取舍即智慧。

春运返程票历来都是一票难求，12306也提供了候补订单帮助顾客自动抢票。

如果有旅客退票或者改签，这退出来的票就可以按候补顺序分配给排队抢票的人。确实很多人通过候补订单买到了想要的票，解决了旅客的买票难题。

然而，最近微博热搜爆出了一个候补订单的缺陷，有旅客提交了候补订单后，又幸运地抢到了自己想要的车票。

不幸的是，他忘记取消候补订单。结果，凌晨三点熟睡之际，12306通知他候补订单成功了。更不幸的是。等他醒来看到消息，已经发车了。发车后不能退票，只能改签，而且要承担高额的改签费用——他这个候补订单1700多块！

事情经过大概是这个样子。

果然，“人人都是产品经理”，众多网友提出了优化建议。

1）最简单的方法：凌晨的提醒能不能改成语音电话提醒，毕竟短信很难注意到。

2）前端优化提醒：候补订单截止时间不要设置为默认截止，而是让旅客自己选择是否默认或者设定截止时间。

3）彻底解决问题办法：相同时段的候补订单检查旅程是否高度重叠，重叠后不执行候补订单（目前正常订单是有防止重复旅程购票的）。

上面的优化建议看起来都合理，12306会不会改不知道。从个人角度来分析一下这三种方式。

第1种方式看似简单，但是会有两个问题：

一是语音提醒并不能百分百解决问题，如果是免打扰或者睡得太沉一样无法接收到提醒。

二是，语音提醒会带来额外的成本，短信可能是2分钱一条，语音提醒就会到1毛左右了。

12306这巨大的流量，成本会高不少。

第二种方式，从实现角度也不难，牺牲点用户体验而已，因为大部分人其实都会设置默认，毕竟主要需求是抢到票。当然，实际上也不能完全解决问题，毕竟类似重复的订票也可能在截止时间前发生。

第三种方式，普通人可能会觉得，既然你正常订单都已经能够排除重复旅程了，候补订单应该也很容易处理这个问题。不过，就我个人推测，候补订单系统应该和正常订单系统是独立的。毕竟是后面推出来的，类似一个“外挂系统”。要将这个外挂系统整合到12306庞大的系统，成本和风险都很高。

首先，12306不仅仅是一个订票软件，实际上是全国人民的出行基础设施。如果整合过程除了问题，那会影响上千万乃至上亿人的出行。

其次，12306的流量实在太大了，早些年12306的崩溃是家常便饭。经过多年的持续优化迭代，目前12306已经能够应付超高的并发请求了。如果将外挂系统整合进来，必然会影响系统效率，而要达到整合前的性能，且不说开发成本，日常运维成本都会大幅增加。

说到底，候补订单重复是一个低频小概率事件，像这次这种半夜候补成功早上发车的事件更是少之又少。花大钱办小事，从商业角度来看肯定不划算。

引起公众争议的其实就是一部分人把12306当做了一个政府机构，认为就应当面面俱到，系统做到完美。

然而，我们做产品都知道，很多时候都要权衡利弊，做取舍来确定产品功能和优先级。一个产品，不可能不计成本100%满足用户的所有需求。事实上，如果真的这样做了，必然在其他方面会影响用户体验。

盈亏，本同源。