当上周我还在海上漂的时候，一位同学通过微博联系我，希望知道一些我对12306几个点儿上的事情。那会儿在海上漂处于失联模式，因此拖到现在才有时间来写点啥。

其实也一直打算有时间的话再写个12306总结的2016版（之前的两三年每年我都会写很长很长的东西来回顾当年的12306的），只是后来时间有限自己也疏于笔头，就暗搓搓地想要不直接当忘记好了。

既然有同学有需求的话，那还是来写点吧。这次可能不会太详细，很多内容之前都写过了其实。

由于我比较懒，就不具体展开了。只针对同学问我的点解释一下……

1.当初是什么原因促使你开发这款插件的？

这个问题比较经典了，其实原因很简单：我需要用，因为我是个很懒的人，是绝对不愿意反复输验证码不断重试的。所以我需要在一定的限度内解决繁琐冗余的环节。

具体的信息，可以参考之前很臭很长的故事会文章：2014 春运祭 ① 12306和插件们的前世今生

2.由于访问量激增，GitHub因此遭受了DDoS攻击。现在你的代码托管是怎么解决的？

这个问题的起因在上面的那个前世今生中其实有很详细的解释。之所以会导致那样的结果有很多因素共同作用导致的。简单说来，就是以下的原因：

• Chrome在某次更新后增加了同源限制策略（估计是在12年），HTTPS无法加载HTTP的资源
• 我没有HTTPS服务器，也没有相关证书
• 订票助手需要自动更新检查，这个是刚需
• 并没有找到比较简便的做法能绕过同源限制
• 那时候并没有接触过GitHub并不清楚其内部的区别和限制
• GitHub在流量略高的时候会返回错误（403）
• 经过调整的检测策略并没有对重试操作增加延迟和次数限制（虽然默认间隔并不短，但始终的高频率403导致请求越攒越多）
• 虽然后期我已经改用新的检测方式不依赖于Github和HTTPS（iframe代理模式），但之前的客户端因为GitHub不返回正确信息导致无法更新，也就无法降低请求量

综上所述，在GitHub越来越限制的时候，其承受的流量是逐渐增加的。只要能正确返回数据，流量是会直线降低的。可以说情况也始料未及，对GitHub认识不足导致其躺枪，因为这事儿众所周知也实非我所愿。

后来的解决方案分了好几个阶段。

2.1 SAE托管

此时开始尝试将检测更新的信息文件放在SAE上。然而SAE是个不靠谱的家伙，在13年12306闹事之后强制直接关闭并删除了我的托管（给我发信息说是因为公安部的文件要求）。

不过这些影响并不大，因为此时SAE上的信息文件只是过渡，最新版的更新代码已经改为iframe内嵌框架代理了。所以SAE的流量在短暂的高峰后，迅速下降。

2.2 iframe代理模式

虽然Chrome有Https同源限制策略，但并不影响内嵌的iframe来自于http。所以后期（也就是临近13年春节的时候）的更新已经全部更新为此模式。换句话说，就是内嵌一个隐藏的iframe，由它去加载检测更新的页面，然后通过参数传递版本信息并判断版本。

这个操作很灵活，但有个限制，就是提示必须在iframe里，对外层的窗口由于跨域也无法操作，所以提示方法很有限，并且无法保证是否能正确检测更新。

2.3 扩展检测更新模式

之前的订票助手一直使用UserScript模式，可以兼容Firefox、Chrome等。但由于13年春节12306做的手脚比较多，纯粹的UserScript能做的事情很少限制很大，所以开始放弃UserScript模式，转而全面使用Chrome扩展模式。此时，更新代码完全可以放到扩展的后台页面中，通过前台页面触发更新。

此模式直到最近的猎豹抢票大师都一直是这样的，只不过在用户交互和信息传递上略有差别。

3、您能谈谈从最早的版本到现在的插件版、客户端版、验证码识别等，在开发过程中，有哪些比较有代表性的技术演进吗？

首先，我们需要明确一点，就是在订票软件这条路上，12306始终都是大哥大，具有绝对的话语权和操作权。第三方的兄弟们再怎么折腾，都是隔靴搔痒，充其量让穿靴子的人觉得心里舒服点。

要说技术演进的话，从实现技术去分类比较合适。

3.1 最早的UserScript时代

其实最早这些东西是在Firefox上依托 GreaseMonkey/Scriptish 实现的，然后恰好Chrome也支持UserScript，所以可以跨浏览器使用。彼时各大浏览器厂商和IT厂商并没有意识到这个市场，甚至连黄牛软件都没有，12306除了卡慢也没有各种暗坑和意外状况，所以这是个很美好的时代。基本上只要你肯刷，刷到票都是你的，根本用不到自动识别验证码之流。

所以很多早期的同学会怀念这个时代，觉得这个时代的插件很牛，看到票绝不失手，其实不是插件牛，而是那会儿的环境太纯洁了。

3.2 Chrome扩展时代

后期由于几大互联网公司的浏览器的介入，市场的推波助澜，导致12306意识到问题的严重性，开始着手封堵。UserScript工作于页面级别，能做的事情非常有限，针对12306的限制（比如12306曾经依据User Agent封堵访问、判断Refer来源等）几乎无事可做，所以后来渐渐放弃了UserScript模式，转而全面使用Chrome扩展模式。

在Chrome扩展的后台页中，可以实现修改请求信息、长驻留任务等，可以做的事情比较多。

这个模式一直发展到14年春节，基本上达到了登峰造极的程度，功能和实用性最为丰富。但可惜的是，14年春节12306出来的新版，让这个工作模式开发难度陡增（因为新版的12306大量使用了闭包和第三方库封装，代码实在太臃肿了），并且12306在高峰时会因为自己的原因甚至直接卡死浏览器（同步XHR，我之前说过很多次了，有兴趣的可以阅读14年总结相关章节），导致用户体验极差（甚至会有不少人觉得这是插件的问题），所以在这之后，Chrome扩展也渐渐取消了UI界面。

3.3 独立页面购票时代V1

早在14年春节的时候，某数字就搞出了独立页面订票。在这之前，其实我也是考虑过这种模式的，但是当时在独立页面和内嵌12306两种模式之间衡量的时候，觉得内嵌12306更为稳妥，然而事实证明我的观点是错误的，因为难度极大不说，12306掉的链子会带上我一起掉链子，并且还光荣背锅。

所以在14年春节后，我也走上了全面独立页面的道路。独立页面其实更容易实现，用户体验和功能都容易做得比较好。这个模式一直延续到现在。

简单地说，就是通过独立的页面来实现对接12306接口，实现订票。

3.4 独立页面购票时代V2

在实现独立页面购票后，由于是独立页面，所以可以做的事情是比较多的。此时我开始考虑做一些原来想做却没法做的事情，或有一些新的情况（如限售）是否可以通过技术手段降低些影响。

在14年中到15年，我设计并实现的这些功能包括：

• 跨站推荐：如果一趟车因为长途因素限售，自动检测并监控临近的车站，尽可能提高发现车票的概率
• 中转推荐：通过服务器后端算法找出可以中转的线路并提供相关信息
• 辅助信息提示：如当前车站以及始发站起售时间提醒、购票难度提醒等等
• 聊天室：刷票路上做个伴

以上这些功能可以说订票助手都是首推并做得最好的。后来其中的一些功能也为其它的浏览器厂商所借鉴，但并不是他们的重点。很多的浏览器厂商（如数字、某狗、黄易等等），他们更多的把精力放在了全自动上面（如验证码识别）。

3.5 客户端版

软件版并没有什么可说的，因为基本上都是独立购票页面的套路，不过既然是独立软件，那么当然可以无视浏览器的各种环境限制，容易做得功能非常强大。

但这也是双利刃，取决于软件作者的素质。一把刀你可以切出好菜，你也可以拿去杀人，看你是怎样的人。

所以第三方的黄牛软件、收费软件等，都是独立的客户端，至于功能设计的变态程度，完全取决于作者的素质。甚至有些时候他们还会利用12306未披露的漏洞，乃至服务器集群等各种手段来抢票。

具体这怎么说呢，我只能说没素质的人太多太多吧。

4、国内众多的浏览器厂商根据您的版本纷纷推出了各自的抢票版，您怎么评价这些版本或者说这些产品？

可说的并不多。其实这个情况只在独立购票之前才有。

总的来说，就是：1.开源在国内意味着可以免费用没限制想改就改想抄就抄；2.反正吹牛不课税我说我第一就是我第一（简称不要脸）；3.天下大一统你好我也好。

在这些版本中，有比较多的浏览器厂商是经过我许可的，比如猎豹浏览器，淘宝浏览器，百度浏览器等等。

也有个别浏览器（如某卖鞋的），想要跟我合作被我拒绝后，转而搞出来一个自己内部的人假模假样的装个人开发者借用我的开源代码自己搞一套，然后还是伪开源，跟12306对抗的时候还抄我的代码。
就更不用说手机版最早的版本是完全把我代码复制过去改改文字和图片就上线的了（13年我曾为猎豹手机浏览器写了一个手机版订票网页，上线不到一个星期被整站复制走）。

总的来说，和12306对接的接口没那么复杂也并不是什么机密，所以在这之后的各大独立app、软件等，其实可以说是大一统的场景，并没有基于谁的版本。
如果说非要评价一下的话，那就是在我之后，其实并没有让我感觉眼前一亮的新功能设计，可以说超越我设计的功能的产品（无论是独立软件还是app还是独立购票页面）并没有出现。

5、最近前端界存在一些技术路线的争论，您是否关注？以及您怎么看待前端技术的发展？

我本人并非大牛级别的人物，所以不好说什么，主要怕误导人。

在我关注的情况里，可以看到新技术新标准（如HTML5，WebGL，NodeJS乃至Reactive本地化等）推行的越来越快，受众越来越广，是很值得高兴的事情。
前端界往往和开源界挂钩非常紧密。只是前端界的各种技术百花齐放却并没有多少沉积，学习成本越来越高，各种新规范新技术新框架层出不穷应接不暇。
以前我觉得搞C++的都是大牛，因为C++实在是太高深了。现在我觉得搞前端的都是折翼的天使，因为前端水太深了。

除此以外，前端和移动结合也越来越紧密，比如淘宝的app很多地方都是内嵌的HTML5页面。可惜我总觉得这些都有点过度膨胀了，本人是很不喜欢这些APP的，因为它们共同的特点是卡、费流量、慢，交互复杂而诡异。

总的来说，前端界给我的感觉就是，技术日新月异推陈出新，但却是很混沌的一种状态。期待未来向比较明朗统一有序的方向发展。
再就是目前而言，在我的感知里，受限于技术和性能，前端会继续发展，但暂时无法取代所有事物。比如Chrome应用已经有很多能做到传统独立软件相同的事情了，但是相比而言，无论操作便捷、功能还是速度，都还无法相提并论。

总的来说，看好前端的发展，也看好移动的发展，但是感觉大伙儿有点自我膨胀了，也许发展的时候适当冷静一下会更好（换句话说，我感觉发展得有点浮躁）。
啥？具体的路线争论吗？……好吧我没怎么关注，因为最近几个月都在关注12306……

6、有一种观点认为，抢票软件造成了人为的不公平，您怎么看待这个观点？

我前面说过了，具体抢票软件会做成什么样子，取决于作者的素质。

我们首先需要明确的是，车票作为一种稀缺资源（相对于需求来说），是不可能每个人都惠及的。因此无论你怎么做，总有人拿不到票。如果每个人都有票了，那也就没有抢票一说了。
当一种资源无法普及给每个人并且依赖个人去自己争取的时候，那就是没有平等可言的。总有人手快，总有人眼神好，总有人网速快，总有人电脑快，总有人购票经验丰富，等等等等。这些都会导致每个人买到票的概率不同，这是无法平等的，只能保证构造一个良好的秩序去保证每个人购票的机会和权利。因此，在购票这件事情上来说，我们只能尽可能要求不要有明显可控却放任不管以及有意而为之导致的不公平和秩序错乱。

同时，作为IT公司、软件开发者，也是具有一定的社会责任的，就是说，他们需要在这整个过程中，拥有了技术资源和服务能力，那么他们就要有相应的社会意识，维护一个正常的、合理合法的购票秩序。而作为购票软件的开发者，是不是使用了特殊的、异于常规的技术手段，以一种常人所不能及的速度和功能去进行操作，决定了它是不是会导致不公平。

作为市场的受体，用户往往是盲目的，因为他们的目标就是买一张票，有票就行别的什么都不会讲究。在缺乏监管的情况下，不少软件作者和企业为了吸引用户获得市场，会利用用户的无感知以及无监管的特点，做着看起来为人谋福利实则破坏秩序的行为。这些行为的典型代表就是离线抢票和验证码识别。它们利用自己所拥有的常人不具备的硬件设备资源、服务器资源以及机器手段，肆无忌惮地破坏购票秩序对12306设置的购票秩序肆意践踏，然后标榜自己是在为自己的用户抢票，然而这些手段都极大地损害了正常用户的购票过程，乃至对12306正常的经营活动造成强大的干扰。
与此同时，不在市面上流通或为一小部分人使用的黄牛软件，也会无视种种秩序，竭尽所能占用12306服务资源，在此同时对其他正常用户造成极大的干扰，对秩序也会有极大的破坏。

所以说，是不是会造成人为不公平，要看软件具体怎么做。
说到这里，也许市面上只有我做的软件才不会导致人为的不公平的软件，其它的软件和那些IT公司，只能呵呵了。

感谢阅读本文，欢迎扫描下方二维码关注鱼的公众号（微信内长按识别哦）