主题：【原创】身为码农，为12306说两句公道话 -- 代码狗

比如 用户在打开12306网站的购票页面的时候，12306的后台服 务器就同时开始计数，这个时间可以限定一个数字比如说60秒。只有过了这60秒才可以正常的购票程序，而这60秒的时间里，12036的后台可以给这个用户的IP排队，进入排队序列。

当用户正确输入验证码之后，12306的后台在给用户第二次排队60秒到180秒，这样理论上可以防止抢票插件带来的时间优势，因为这个时候，如过没有这个限速的化，使用插件的机器永远比人快。

同时这第二个限速时间也正好可以使12306的后台，有足够的时间来完成给用户购票的任务。

当用户确认购票之后，在来个二次确认，这个时间段在来个60秒左右的限时限速。同时使12306的后台把下个要购票的用户IP进入排队序列。

总的来说就是认为的放大12306购票时间的，这样的化，理论上就给了12306后台足够的时间来处理一系列看似变态的数据处理任务。

既然不能无限制的扩大后台的处理能力，那在后台处理能力的范围内，限制前台进入后台的进入量和进入时间，给后台留下足够的处理时间，可否。

同时 12306网上购票本身也要做个限制。就是把提前购票的时间放大，把结束购票的时间放短，比如楼主说的的G71 如果以前12306的购票时间是车次发车前的7-1天，现在（或是单单的春运及节假日），把它改成30-7天。