关于12306自上线以来前端体验不佳，网友林布说：
12306没有用心在做。
偶以前是干前端的，server端很多东西偶不懂，也知道难度极大。但无论数据库那边有多难，至少前端都不应该做成这么落后，混乱的样子。最差的情况下，哪怕数据库方面直接挂掉了，至少页面也应该是活着的。
「挟太山以超北海，语人曰『偶不能』，是诚不能也。为长者折枝，语人曰『偶不能』，是不为也，非不能也。为什么说，12306的前端是落后过时的。很多细节列举：
页内js写的到处都是，东一片西一片，很难维护
css技术落后，多个icon图片分开加载，完全可以用css切割来减少请求次数，提高效率
js技术老旧且极不成熟：使用jquery 1.4.2也就罢了，页内有大量字符串拼接html然后用$jq.html()方法写入的语句，很难维护，可读性低。
许多本应私有方法暴露在window对象下，比如getQueryParamValue这种，对安全性和可维护性都十分不利
资源加载未优化：除了现成的控件以外，js没有经过压缩和混淆，不过比偶上一次看（12年底）的时候，大段大段的注释要好一些。此外资源加载次序没有优化调整，一些不重要的js文件在head处加载，没必要
前端技术不但落后，而且混乱，没有统一。在选取dom元素方面，一个页面里同时存在jQuery的选择器以及document.getElementById的方法。同时Jquery控件和接近被淘汰的flash控件混用来呈现了一个很混乱的前端代码
html的命名简直不知所谓，indexLeft下面是newLeft，newRight…谁知道这是什么跟什么啊。对后来的维护势必造成困扰。相比之下二维码的div叫做erweima还算比较萌
说起来偶之前看到他们的大段注释的时候，还看的出来他们在规章制度上挺严格，注释写的一板一眼的。但是实际上也就是制度上严格而已，管理上十分混乱，连一个统一前端技术方案都没有，才会闹getElementById和jQuery选择器大规模混用的笑话。
项羽说天要亡偶非战之罪情有可原，你一马谡自己不好好做事把自己弄死了，还怪王平不给力，好意思吗。
关于12306最让人诟病的是频繁崩溃，网友王强说：
以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11活动峰值负载相当，新的系统基本经受住了考验。
一种商品只要出现供不应求现象，那么结果只有两种：大家排队购买；出现黑市，变相提高商品的流通价格并抑制需求。
12306这个事情，就是标准的限价商品供不应求之后出现排队与黑市现象的例子。因为供不应求，所以有了黄牛、抢票软件与秒杀。现在供应不足的前提下，12306就算把系统做的性能再高，也只是会加快热门车次票务秒杀的速度而已——即更加会刺激抢票软件，大家为了在更短的时间里成功抢到队列名额就会不断提升自己的抢票性能。
打个比方说就是一个店门前排队，消费者为了增加买到商品的概率去雇人代排，造成店门口的通道拥挤不堪。为了减缓拥堵，商家不断拓宽通道，但每次一拓宽消费者们就会增加雇佣的排队劳力把新增的通道空间占满，就形成了恶性循环。所以12306的问题主要不是出在网站本身。
但一贯被认为是因循守旧的国企，在选择技术方案时放弃沿用多年的小型机/UNIX平台去拥抱业界还是新鲜事物的基于x86/linux的大规模分布内存数据库系统，承受住了堪比2012年淘宝双11的压力，12306还是做到了全球最强的客运票务系统。在这个领域，12306可以自豪地说自己是做的最好的案例。它还在卡，还是偶尔崩溃，页面还是难看，可是这些迟早会改进。这个过程中也还是会有冷嘲热讽，还是会有所谓的大牛指点江山，但最终解决春运高峰期一天数百万张秒杀售票的，还是12306自己。
上月底，12306发布公告，称铁路部门将结合近期即将开通运营的新线，对旅客列车运行图进行全面调整和优化，所以11月27号起只发售12月25号及之前日期的车票，12月26号及之后日期的车票计划在12月上旬开始发售。
12306官网宣布恢复车票预售期，从12月12号也就是明天起，恢复火车票30天预售期，建议大家提前在官网上购买元旦假期的火车票。
文/优就业（ujiuye） 部分参考：林布、王强