就是闲不住。看到那种三五天就能搞定的小项目，总想插一脚。这回这个《舞姬》的官网，说白了，就是个高配的落地页，目的非常明确——让人点那个“立即下载”。
接下这单子，我是怎么开始折腾的？
话说这事儿得从头说起。我有个老朋友，做独立游戏的，平时穷得叮当响，但是人仗义。他跑来找我，说他们那个新游戏《舞姬》要上线了，预算拉得很低，大厂那种华丽官网搞不起，就想弄个单页，把游戏截图和那个巨大的“立即下载”按钮放上去，越快越
我一听“越快越好”，心就凉了一半。经验告诉我，甲方说“越快越好”，往往意味着“要求最高，预算最低”。但看在朋友面子上，我接了。我立马告诉他，不搞那些花里胡哨的框架，什么React、Vue，全扔掉。要的是速度和稳定，就用最老实的HTML5和CSS3怼上去，加点原生的JavaScript做做用户判断和简单的交互动画。
第一步，选图。 朋友把他们美术组赶工出来的一堆原始素材扔给我。好家伙，一个背景图就快20M，全是大尺寸的PSD文件。我坐在电脑前，对着这堆素材，简直比当年通宵写毕业论文还头疼。这要是直接扔服务器上，用户打开页面不得等半小时？
- 我1跑了一遍图片压缩。
- 然后手动切了几个关键的宣传图，把它们的尺寸和格式全部优化了一遍。
- 3定下来一套扁平化的设计，确保在手机上也能看得清楚。
这一通折腾下来，几个小时没了，但至少页面加载速度是稳住了。
核心——那个“立即下载”按钮的实现
页面再好看，那个“立即下载”按钮才是核心。朋友的要求是，它必须足够醒目，而且要有“跳动感”。我当时就在想，静态页面哪来的跳动感？
我抠了抠脑袋，决定用CSS的动画属性来解决。我调了一个简单的`Keyframes`，让按钮每隔几秒钟就微微放大缩小一次，再加点阴影和渐变色，模拟那种急切想被点击的感觉。这玩意儿说起来简单，但要让它在所有主流浏览器上表现一致，简直要命。
最烦人的部分来了，链接跳转。 游戏是双端的，iOS和安卓。我得确保用户是用什么设备访问，就跳到对应的下载商店去。我本来想用后端逻辑来判断，但为了省事，我写了一个小小的JS脚本，让它去读取用户的User-Agent。如果检测到是苹果设备，就指向App Store的链接；如果是安卓，就指向他们内部的APK下载地址。
这个脚本不复杂，但朋友那边三天两头给我换一次下载地址，一会儿是测试服的链接，一会儿是正式服的。每次他们一换，我就得半夜爬起来，改一遍那个JS文件，再重新上传。那段时间，我手机里设的闹钟，都不是用来叫我起床的，是用来提醒我“换下载链接了”。
为什么我总在做这些修修补补的活儿？
你可能好奇，我一个正经IT出身的人，怎么老是接这种边角料的活儿？
我以前是在一家大厂做系统架构的，每天面对的都是几百个微服务和复杂的权限管理。听起来光鲜亮丽，但实际上？天天开会扯皮，写个功能要等七八个团队的接口，推来推去，什么都没落地。我当时在那个岗位上，感觉自己快被流程和表格淹死了。
正好是前几年，我父母身体不需要我回去多陪陪。我一咬牙，把大厂的工作给辞了。当时领导和我说，你这么一走，损失可大了，等你回来岗位就没了。
我当时是怎么想的？没了就没了！我宁愿自己接点散活儿，虽然辛苦，虽然要熬夜给朋友改下载链接，但至少我做的东西是看得见摸得着的，是真真切切能跑起来的。我用空闲时间自己捣鼓了一个简单的服务器集群，专门跑这些小网站，成本低得吓人。这个《舞姬》官网，就是我众多实验品里的一个。
现在回头看，这套“土办法”做的官网，上线后稳如老狗。页面秒开，下载链接的跳转也没出过错。朋友高兴坏了，立马给我结了款。虽然钱不多，但这种快速实现、立刻见效的成就感，是当年在大厂写一年报告都换不来的。
所以说，很多时候，技术不一定要追求最炫酷的，能解决问题、快速交付的，才是王道。这回折腾《舞姬》官网，我总结下来就是，跑通比完美重要，稳定比花哨重要。