从零开始：把TS和下载服务硬凑成一个官网
最近我接了个挺有意思的活，给一款独立游戏做个官网，就是那个叫《TS变身退魔少女》的。听着名字就一股子二次元的味道，但我拿到需求的时候，心里就咯噔一下：要求用TS写前端，而且要集成一个超大的游戏下载包。老板的要求是，官网要显得“技术先进”，但核心诉求就俩字：能用。
我立马就意识到，这又是个技术栈大杂烩的活。因为要快，要稳，我不可能为了一个官网从头写一套服务。所以我的思路是：前端界面用TS搭一个架子，下载服务直接拿我以前写好的、用Go语言搞定的老系统魔改。没错，TS配Go，前端和后端隔着一条长江，谁也看不上谁，但我就是要把它们硬塞到一起。
选材与搭建：从框架到服务器的折腾
动手的第一步，我得把门面搭起来。
- 前端选型：虽然要求用TS，但框架太多了。我没多想，直接抓起一个我最顺手的TS组件库，开始堆积木。界面要求简单大气，几张宣传图，一个大大的“立即下载”按钮。我花了不到两天时间，就用TS把页面框架给撸出来了。看起来挺唬人，就是个壳子。
- 下载服务的挑战：重头戏在下载。游戏包有几个G，直接放在云存储上带宽费能把我吃穷。所以我决定用公司以前淘汰下来的几台小服务器，自己搭建下载节点。我把以前用Go写的文件分发服务扒拉出来，这套代码虽然老，但处理大文件传输特别稳定，这是它的优势。
- 接口的对接与冲突：这是最头疼的环节。TS前端写得漂漂亮亮，用现代的Fetch API去请求Go后端的文件链接，结果Go那边老代码里一堆陈年老旧的CORS策略，死活不认我的请求。我尝试在前端加各种头，不行；尝试在Go服务里加中间件，还是不行。气得我直接把Go那边负责处理请求头的几百行代码复制过来，硬着头皮一行一行地看，找到了那个该死的校验逻辑，直接把它注释掉了，加了个“无脑通过”的配置。
就是这样，一个现代化的TS界面，后面拖着一个三年没更新的Go下载服务，强行被我用几行魔改的代码连接在了一起。结构上，别提多难看，但功能上，完美实现。
真正的地狱：断点续传的旧账
服务能跑起来，只是完成了百分之六十。接下来就是处理历史遗留问题。
我那套Go写的下载服务，虽然能传大文件，但有个要命的缺陷：断点续传的逻辑有漏洞。只要用户网络稍微波动大一点，或者手机屏幕锁屏了，下载链接就会断掉，然后恢复失败，玩家必须从头开始下。一个G的游戏包，谁受得了重下五六次？
我知道这必须修，否则投诉能把我淹死。我一头扎进了那个Go服务的文件传输核心代码里。那感觉，就像考古一样。当初写这段代码的同事早就离职了，代码注释少得可怜，逻辑绕来绕去，充满了各种“看起来像Bug但它能跑”的玄学设计。
我花了整整四天，抽丝剥茧、定位问题、反复测试。发现问题出在一个非常细微的地方：Go服务在处理HTTP Range请求时，对文件指针的定位有一毫秒的延迟。一旦客户端请求恢复下载，服务端给出的起始点总是错开一点点。这个小小的偏差，导致数据校验失败，连接中断。我真是差点把键盘砸了。
我没敢大改，只是在那个文件指针定位的代码块里，加了个强制的延迟补偿逻辑。很粗暴，但有效。跑了上百次测试，终于把这个老毛病给治住了。现在玩家断网了，再连上，能顺利地从99%继续下载。
我的无奈与妥协
你可能会问，既然这么麻烦，为什么不干脆用统一的技术栈重写？
我当时接这个项目，是处于一个非常尴尬的时期。我正忙着搬家，家里一团乱麻，根本没时间搞什么优雅的架构设计。我手上只有一周时间来搞定这个官网和下载。如果我选择用TS/JS全家桶来搞定下载服务，我得从头去学习*怎么稳定处理高并发的大文件分发，我哪有那个时间？
我只能用我最快的方案：TS负责漂亮的脸蛋，Go负责粗糙但可靠的体力活。这是速度优先的产物。
就像我以前在老东家待的那两年一样，公司里什么技术栈都有。Java写权限系统，Python跑数据分析，Go写中间件，前端全靠Vue，大家各自为战。出了问题，互相推诿。我这回搭的这个官网，就是我自己给自己挖的坑。下次维护的时候，我得同时切换TS和Go两种思维，去修两个完全不搭嘎的系统。
没办法，独立制作人看的是结果，玩家看的是下载速度。至于我用什么技术，是不是大杂烩，他们才不关心。能快速把这个“退魔少女”送到玩家手里，我的任务就完成了。