之前貌似在知乎上有讨论过 12306 的实现思路了， LZ 可以搜索一下整个背景。 从技术角度，你可以自己实现一个，再实现一个抢票版，看看效率，看看高并发和高速计算下的技术难点各在哪里。不要迷信程序能解决一切问题。当然，正确的程序能解决大多数问题，难点永远在于保证程序的“正确”、保证程序在人类需要它完成的时间内完成计算。 从实际角度， 12306 是全世界最复杂的购物系统。第一它和铁路网相关，供方绝无可能迁就需求方的需要动态改变供应计划。第二，一个静态的铁路网，从 A 点到 B 点，还有 A 绕道 C 至 B ， A 绕道 D 至 B ， A 到 D 的车同时也是 E 途径 D 到 F 、 G 绕道 D 到 B 的车， A 到 B 的直行车途经 HIJK ，则该车次某个座位的售票计划就有 AB 、 AH 、 AI 、 AJ 、 AK 、 HI 、 HJ 、 HK 、 HB 、 IJ 、 IK 、 IB 、 JK 、 JB 、 KB （排列组合嘛），这些商品互相存在排他关系，这个冲突也要实时反馈在购票系统里。如果让顾客只提出线路需求（假定包括换乘），抽号系统就要在符合要求的所有换乘 or 直达路线上所有车次里进行操作，同时可能还存在数千个所需求路线有部分重叠的客户，其中或许有几千个客户又与另百条线路有重叠……系统再处理所有线路票务之间的排他关系，那么问题来了，在这个复杂度爆表的算式里，一人拿到号，会直接阻断之后多少条线路上多少人的计划？导致这些人根本丧失了摇号的机会？那么如何拍定摇号的顺序，从谁开始摇号？如何保证这个算法对所有线路的客户是公平的？全过程处理速度要求有多快？ 抢票一个重要功能，就是先来后到，把车票之间的卡位关系转换成按时间先后顺序排队的绝对公平。另一个作用就是把以上复杂的路线冲突规划过程分散到十亿人的大脑中进行，每个人各自求局部最优解，你可以理解为变相的云计算。