今天真是吐了老血的一天......
当我浑浑噩噩的到了公司，坐在我的人体工学椅上，还没坐热。身后突然有一个声音，吓了我一跳，我知道这是后端又来提BUG了~
"你看看国际环境，怎么静态资源这么多403的，是不是公司限制海外域名访问国内CDN了？"
"奇怪，虽然有些请求是403，但是页面还是能打开啊......真是奇奇怪怪"
哎，既然要改那就改吧，看看啥情况......(⊙︿⊙)
"先不要用CDN吧，反正浏览器有缓存，我们发版频率也没那么频繁。"
方案1 直接回源
不用CDN这还不简单？我直接把vite里面的base参数给注释掉，这下就直接访问服务器的资源啦~然而在我发版后发现线上的页面打不开了......
打开调试器，一看网络，都是200。奇了怪了，再一看发现请求到的内容都是index.html，怪不得呢......原来是前端发布工具那边设置了路由，搞了半天，他会把/static映射到/assets目录，然而我的index.html直接请求/assets自然就啥都没有。
好家伙，我直接加了一个/assets -> /assets的全新映射，坐等成功~
跑了一次，确实能访问了，但是奇怪，怎么加载这么慢......检查了一下响应头，竟然不包含cache-control，每一次都是全新的感觉~我很震惊，也感觉很烦躁，就这么点小事怎么坑我这么久......而且是公司内部平台，查资料也不太方便。本着不想麻烦同事的想法，没直接去拉oncall。
下午仔细看了一下oncall群，说是为了保证cdn的正确性，不缓存，也不设置缓存，受不了就加cdn吧~
这......不又绕回去了，吐血。但我不死心，域名的流量是通过流量中台转发到前端去的，按理说流量中台应该可以设置代理规则，给响应头直接加个cache-control一年即可，毕竟我们打包出来的东西带hash，不需要重加载。然而流量中台直接把我整懵逼了，不大会用。直到晚上快吃饭了，才突然发现怎么用。然而那个时候系统又在维护，不给我更新......因此，我不太确定这个方法管用不。
方案2 继续用CDN
一份代码跑出多份结果，每份结果引用不同的CDN。目前需要生成3个环境，离线、国内、海外。常见的方法有：
新增代码编译仓库，变更流水线
在我前部门这种模式就很常见，一个环境开辟一条流水线，每份代码通过环境变量或者执行不同的sh脚本构建出不同的产物。但我懒得再去配多条流水线了，有点麻烦。
构建一次，但是生成多份index.html
最开始的设想是不就是js、css的引用域名不同么，我写一个脚本生成多份index.html不就行了，比如index.boe.html，index.cn.html，然而后面发现vite打包出来会通过js再往里面注入新的js，这个新的js还是源站的地址......因此似乎不太行得通了。
☑并行构建，并修改路由
在vite里通过vite build --mode env可以传入环境变量，然后生成不同的产物。于是我直接通过child_process的spawn并行跑了3个构建任务，每个任务都生成到/dist/env文件中......最后实测，构建速度还行，和执行单条流水也差不多噢。构建出来的dist会包含所有环境的文件夹，因此需要修改不同环境的路由，否则就需要https://xxx/boe/index.html 这样去访问了。
然后在每个环境的路由处把映射规则做好
- index.html -> index.boe.html
- /assets/ -> /boe/assets/即可，以此类推
反思
这次工作竟然尝试了一个早上+一个下午才得出一个可行的方案，而且搞得情绪也不好，出乎意料的事情还是蛮多的。直接在流量中台那边的nginx加上一行add_header其实是最方便的，上了缓存后速度上也不会无法接受，但因为赶上中台灰度测试，所有变更都被锁死，没有耐心去等一个不确定的结果。
今天的脑子里真的是一团乱麻，可能因为这个改动涉及到太多外部环境了，我需要猜测每个外部环境是不是支持我的想法，搞的我很烦，只能一个个去尝试。而且又是公司内部的基建，资料完整度和开源软件没法比，找资料也心烦，一不小心又得拉oncall。而如果只是写一个组件，我清楚会在什么环境执行，就至少能先构思好，直接动工......
资深的同事，往往也有很多坑无法避免。所以这是为什么呢？蛮痛苦的，但是又好像看不到有什么优秀的解法。所以公司选拔人才要不然选经验丰富精力充足的，要不然就是纯年轻精力旺盛的，因为遇上这些事还是蛮麻烦的捏......要不然根据经验规避，要不然一个劲的尝试，费劲。