为什么要折腾这个官网？
最近手上没什么正经项目，就是想找个东西练练手。前阵子玩那个《TS变身退魔少女》，立绘挺戳我，但官网做得稀烂，信息东一块西一块。我琢磨着，闲着也是闲着，干脆自己撸一个玩玩，还能顺便把手里的前端技术再磨一遍。目标很明确，就是快，而且要稳定，不能三天两头出BUG。
确定技术栈：不选TS那就是给自己挖坑
我以前写纯JS写大项目，真是写到后面一团浆糊，维护起来要命。这回我直接拍板，必须用TS，没得商量。为因为它能提前帮我把错揪出来，不用等到运行才爆炸。我直接拽了Vite出来搭架子，轻量化嘛跑得贼快。框架选了React，不是说它多就是用顺手了，懒得换。
-
第一步：环境搭起来。Vite+React+TS，这三板斧一套，配置文件叮咣一顿改，主要就是把TS的路径映射弄顺溜了，不然导入组件的时候看着就烦。
-
第二步：资产先扒下来。我直接去网上找了几个高清的立绘图和LOGO。首页背景搞了个全屏大图，动效用了最简单的CSS过渡，性能比用啥库都强。毕竟我不想搞成那种花里胡哨，加载半天都出不来的网站。
-
第三步：核心功能敲定。官网要新闻公告、角色介绍、下载链接。我先把数据结构在TS里面定义这样后面写组件的时候，传什么参数，什么类型，一清二楚，完全杜绝了传错值的蠢事。这个提前定义结构的过程虽然麻烦点，但后面写代码省心多了。
过程中遇到的那些糟心事
写到一半，麻烦就来了。我发现扒下来的图文件格式五花八门，加载速度慢得像蜗牛爬。特别是移动端，打开主页直接卡死。我赶紧停下来，把所有图片都丢进一个在线工具里，压缩优化，能用WebP的都换了WebP。这一下，性能立马提上来了，手机上滑着也流畅了。
还有就是TS类型检查，虽然能帮大忙，但有时候也烦人。特别是处理一些动态数据的时候，总要我强制断言，不写它就报错。我琢磨了半天，发现是我一开始数据接口定义得太死板，没考虑到后端可能会传空值。赶紧把接口里该加问号的地方都加了问号，设好默认值，这才消停。要不然每写一个组件都要跟TS解释一遍“相信我，这里不会是空值”，太累了。
我还专门花时间把响应式布局搞定了，用的是最传统的Flexbox加媒体查询。虽然慢，但兼容性而且我用TS把所有视图层组件的Props都定义得清清楚楚，哪个组件在哪个断点下显示什么，都写死在类型里了。这保证了我在不同屏幕上测试时，基本不会出现莫名其妙的样式错误。
收尾与部署：成品还算能看
就是部署。我懒得搞后端那一套，这本来就是一个纯前端的展示页，直接打包成静态文件，就那么几兆大小，丢到我的云存储上面。CDN一挂，全球都能秒开。整个项目从开工到上线，我断断续续也就花了两个晚上。虽然只是个仿官网，但用TS约束着写出来的代码，回头看的时候心里踏实多了，至少知道它不会在奇怪的地方突然崩掉。
这回的实践算是验证了，小项目用TS可能感觉有点杀鸡用牛刀，但只要结构稍微复杂一点，TS带来的那种安全感，是纯JS给不了的。下次搞大点儿的项目，我肯定还用它。