为什么我要自己动手重做这个官网
我根本没想到这个叫《莉吉内塔的冒险》的官网，会落到我手上从头到尾重做一遍。这本来不是我的活儿，我一个主要负责游戏内资源打包的，谁知道变成了个全栈网站工程师。但没办法，之前那个官网，就是个定时炸弹，谁碰谁爆炸。
我们那个老官网，是三年前一个外包公司用一套早就没人用的PHP框架搭起来的。卡得要死，后台逻辑跟浆糊一样。每次游戏版本更新，尤其是这种大版本，比如从V1.0.0到V2.0.0这种，官网的“最新版本”提示、下载链接、还有那些动态活动的Banner，我们都得至少两个人花一天半的时间，手动去改十几个文件。稍有不慎，比如多打了一个空格，或者Banner图的路径写错了，整个页面就直接白屏了。
我记得最清楚的一次，就是上次“海之歌”资料片上线，我们急急忙忙赶着凌晨三点把更新包放上去。负责前端的小王，因为太困了，把版本号的数字顺序写反了。结果，官网显示最新的版本是“上上周”的。那两天客服电话直接被打爆了，玩家骂我们是草台班子，说我们根本没更新。老板当时脸都绿了，在办公室里摔了两个马克杯。我心想这活儿真不是人干的，我得想个法子彻底解决这个痛苦。
我怎么决定推翻重来
我当时就跟我们项目组说了，这种维护方式简直是在浪费生命，我宁愿花两周时间自己重新搭一套，也不能每次更新都像走钢丝。他们一开始不同意，觉得“能跑就行”。我直接把那份上次更新导致充值系统错乱的记录甩他们脸上，让他们自己看，两天流水直接腰斩了百分之三十多！这下他们闭嘴了，让我放手去干，但前提是不能影响日常的开发工作。我当时听着就来气，不影响？我一个人干三个人的活儿，你说不影响？
算了，吵架没用，干才是王道。
- 第一步：选个能快速搭起来的框架。我没有选那些Java或者Python的重量级东西，我选了那个叫*的玩意儿。简单，快，轻。前端用了一个很常见的Vue框架，随便找个模板改改就行，要的是速度和功能，不是花里胡哨的设计。
- 第二步：把核心逻辑抠出来。新的官网，我最看重的就是“版本信息”和“下载链接”这俩地方。以前是写死的，现在必须改成动态的。我搞了一个特别简单的JSON文件，就叫`version_*`，里面只存三个东西：当前版本号、更新时间、下载包的路径。
- 第三步：实现“一键更新”。这是最关键的。我把这个JSON文件，跟我们后端打包服务器的流程绑在一起了。只要我们把新的游戏包打完上传到CDN，那个脚本就会自动去修改`version_*`里的内容，然后把最新的版本号和链接推送到官网上。官网的前端每隔十分钟自动去拉取这个JSON文件。
实现自动化之后的细节折腾
说起来简单，做起来又是另一回事。尤其是对接那个“最新版本”的显示部分。
新的官网我一开始用了一个CDN加速器。结果，JSON文件改了，但是玩家那边看到的还是旧版本，怎么刷新都没用。我当时急得直挠头，以为我的推送脚本又出问题了。后来才发现，是那个该死的CDN，缓存时间设置得太久了！它把那个JSON文件也缓存起来了，玩家访问的是CDN的旧快照。
我当时就骂了一句，这种细节问题才最他妈烦人！我赶紧跑去跟运维的人沟通，让他们把那个`version_*`文件的缓存时间，直接设成零，也就是不缓存。但是运维那边不同意，说这样会增加服务器压力。我们折中了一下，把缓存时间降到了五分钟。五分钟，勉强能接受了，总比等半小时强得多。
我还得确保官网的样式文件和脚本文件更新后，浏览器不会读取旧的缓存。我直接在每次部署时，给CSS和JS文件名后面加了一串随机数字，就是那种类似`*?v=202308151430`的参数。这样浏览器就会认为这是一个全新的文件，强制重新下载。
现在我们团队更新《莉吉内塔的冒险》的新版本，流程简单到发指。后端打完包，确认上传成功，三分钟后，官网的“最新版本”信息就自动变了。我再也不用半夜盯着那些代码，担心哪个链接会崩掉。现在我晚上能踏实睡大觉了。虽然折腾了我两周，但把这个“定时炸弹”彻底拆了，我觉得值。