(资料图)
【本文来自《女子吐槽软卧车厢分配3男1女，这样的分配你们会觉得尴尬吗？》评论区，标题为小编添加】
巡山老腰想复杂了，其实提供表明性别的在线选座就行，由客户自主选择。然后再增加一个在线发起位置交换需求的程序。提供仅一次交换座位的机会。不一定非得让系统去判断和选择。冒昧地问你一个问题：你春运的时候买过票吗？
你看，问题就在于，你以为“自主选座”是一个非常简单容易实现的需求（可能是航空公司的在线值机系统给了你错觉），但你这个需求的实现难度，比让系统用算法判断和选择甚至还要更高……
问题的核心在于，铁路购票系统集齐了巨量瞬时访问+巨量SKU（最小库存单位）+极强的时效性要求，购买一张火车票根本不是你想的“指定某一个具体座位，然后买下它，就结束了”这么简单。
还是拿我之前举例的Z695次的软卧举例。当前情况下，购买一张软卧，有3种SKU（两段区间加全程），这已经是除了直达车以外最简单的情况了。而如果你要实现自主选座，意味着SKU数将至少会翻36倍（一节软卧车厢定员36人）达到108种不同的SKU，此处甚至没有考虑到一趟列车挂载多节软卧车厢的情况。
真程序员到此应该已经开始头皮发麻了，接下来的麻烦更恐怖：如果要求选座，几乎最简单的情况下一节车厢都有108种SKU，且售出一张牌将会导致另外2个SKU的实时变动。那么，如果这趟列车的经停站多一点……
我们说个刺激但也不是最刺激的，海口到哈尔滨的Z112次列车。这趟车经停站达到了24个，意味着当前情况下一个软卧席位将会绑定1+2+…+23=276个SKU，这已经够刺激了。而如果要实现选座还得乘上36，这……得，一节软卧车厢直接出现了9936个SKU，而且每一个SKU的变动都将牵动另外275个SKU。
恭喜，因为你的这一个需求，将整个系统的复杂度提升了至少36倍。而这个系统还需要面临春运时期堪称世界上最大的DDOS攻击，而且你甚至还要在这个系统里加入实时反馈的坐席购买情况和具体性别的标记（好了，又加了两种选项，复杂度继续提升。庆幸吧中国现在还没有上百种性别）……以人类目前的IT产业能力，我估计实现不了这个需求，至少无法在投入可控的情况下实现这个需求，饶了12306的程序员和铁路的服务器吧。
12306上线已经十几年了，目前做到的极限是高铁可以选择座位类型（ABCDF），但为什么不能实现指定座位？是不想吗？
是根本实现不了好吗……
