碎碎念

最近接了个“刺激”的活儿。导师让我给咱们实验室之前的 cyclostrat.org 平台加上一个全新的白垩纪专属子库（/cretaceous）。

听起来不难对吧？我一开始也是这么想的。不就是切个新路由，拉个表格展示点地层数据嘛？

结果一上手，好家伙，直接给我干出了一部“性能优化血泪史”兼“跨网络提速大戏”。今天必须好好写篇博客复盘一下。

阶段〇：前端基建与“强迫症”大扫除（前期准备）

项目第一步，我必须先把历史遗留的那些“将就”给拔掉。

第一刀：砍掉丑陋的 Hash 路由。 之前项目的 URL 里都带着个 #，不仅看着不专业，SEO 引擎看了都得皱眉头。果断把 Vue Router 改成了 createWebHistory 模式。当然，为了防止一刷新页面就 404，我还特意去服务器的 Nginx 里配了一手 try_files 兜底。

碎碎念：改配置的时候还遭遇了服务器底层的 yanchang is not in the sudoers file 权限危机……当时满头大汗，主要是忘记root密码和用户密码了，还好腾讯云后台可以无障碍改密码。要是物理机难免有要一场折腾

第二刀：UI 与数据层双重净化。 新页面嘛。换主图、拉高数据表格占比这些都是基操。然后是面对 Comments 这类内部审查字段，我没有选择简单粗暴地改后端底层结构（容易牵一发而动全身），而是优雅地用了 Vue 的 computed 计算属性做了前端黑名单拦截。不仅页面干净了，用户点 Download 导出的 Excel 也绝不会带出敏感信息。
当然过程免不了导师的不停的各类修改建议：

第三刀：未雨绸缪的前端性能兜底。 虽然这次白垩纪的数据其实只有七八百条，理论上直接渲染也不至于卡死，但为了追求极致体验，我还是上了 Element Plus 的黑科技——虚拟滚动 (<el-table-v2>)。再加上 v-loading 骨架屏安抚用户情绪，以及利用 Session Storage 做的页面切换零延迟缓存。

本来以为到这里就可以交差了，然而，现实很快就给了我一记响亮的耳光。

阶段一：导师的“夺命连环 Call”与核心痛点

“你这页面做得挺好看的，但为什么我第一次点开的时候，转圈转了那么久？这怎么拿去给同行看？”

导师的一句话，直接把我从前端的“温柔乡”拽回了残酷的现实。

我抓了抓头发，百思不得其解：不对啊！满打满算也就七八百条记录，后端哪怕是用最蠢的 SQL 查，也只需要几毫秒，为什么前端要等好几秒？！

我掏出 SSH 登录进了 Linux 服务器底层，反手敲下一个 sudo netstat -tulnp | grep -E "java"，确认了负责干活的 Java (Spring Boot) 后端正健康地蹲在 8301 端口。服务器没崩，CPU 没满。

直到我顺着网络链路往下摸，才突然一拍大腿——草率了，我忽略了物理世界的距离！

破案了：罪魁祸首是“香港服务器 + 无备案”

咱们课题组的服务器是部署在香港的。并且因为种种历史原因，这个域名没有在国内进行 ICP 备案。说实话，我也懒得去备案了。

这就导致了一个致命问题：坐在成都的实验室里访问网站，必须硬生生挤过拥堵的跨境公网。

七八百条数据本身不大，但这漫长的网络延迟（Ping 值高）、动不动就丢包的跨网链路，外加 HTTPS 繁琐的跨域握手时间，硬生生把一个几百毫秒的请求拖成了好几十秒！ 物理定律限制了它的速度，能不慢吗？

之前虽然说进行了第一阶段的 EdgeOne（EO）边缘安全加速平台前端页面加速，但是后端API并没有加速。在请求表格数据的时候还是很慢了

阶段二：祭出大杀器，打破物理距离

没办法，逼上梁山了。前端搞不定，源站又搬不回内地，那就只能用魔法打败魔法！

既然物理距离远，那如果我把数据“复制”到离用户只有几公里的地方呢？我果断掏出了腾讯云的 EdgeOne（EO）边缘安全加速平台。

科普一下：因为没备案，传统国内 CDN 用不了。而边缘加速（EO）在全球有海量节点，正好能用来做这种跨地域的链路优化和节点缓存。

第 1 步：精细化“源站配置”，不能伤及无辜

通过检查前端代码，推断后端域名应该为test.cyclostrat.org

我把 API 域名 test.cyclostrat.org 直接接入 EO 节点。在“源站配置”里，IP 填我真实的香港服务器公网 IP，，端口填 80、443。

碎碎念：这就相当于让 EO 伪装成一个极度正常的浏览器请求去敲门，跨过千山万水来到香港，Nginx 老老实实接客，再转给内部的 8301。完美衔接，皆大欢喜。

第 2 步：注入灵魂！构建“核心规则引擎”

这步如果没做，EO 就是个纯纯的“传声筒”相当于一个VPN，每次依然得跑去香港拿数据虽然相对于直连，会稍微快一点但是还是有优化的空间，也就是让节点对数据进行缓存。我直奔 EO 的“规则引擎”：

• 精准打击：设定 URL Path 等于 /Cyclic/findAlldata。

• 死死锁住：节点缓存 TTL 设置为 12 小时。只要有一次请求，腾讯云就把这七八百条 JSON 数据扣留在全球各大节点的内存里，半天都不松手。

第 3 步：终极杀招，不让任何人做“小白鼠”

架构成型了，但还有一个小瑕疵：缓存是要等“第一个踩坑的用户”跨网跑到香港拉取后才生成的。我不允许任何人（尤其是导师）体验到哪怕一丝卡顿！

我直接杀回 EO 后台，找到“预热缓存”面板，输入接口地址，狠狠点击了执行！

碎碎念：此时此刻，腾讯云的机器大军正代替我的真实用户，走骨干网专线跑去香港把数据拉出来，并以光速分发到各地的边缘节点上。这感觉，爽爆了！

当然如果后续数据更新了，那么也要去清除缓存里面进行清楚对应的接口内容，然后重新预热，因此达到了进行更新加速缓存的效果。

结局：这才是真正的“物理级秒开”！

当然后续的网页前端加速和后端加速都是一个套路，同样的思路完成就好

预热完毕。

我深吸一口气，回到浏览器，按下 Ctrl + F5 强制刷新白垩纪数据库页面。

没有 几十秒的秒钟的等待，没有尴尬的等待图。即便隔着几千公里的物理距离，那七八百条地层数据仿佛从一开始就长在网页上一样，瞬间“贴脸”砸在了屏幕上！

从前端组件的极限调优，到拨云见日发现“香港+无备案”的网络硬伤，再到利用边缘加速的架构重组……看着如今快如闪电的系统，我长舒一口气。