当观澜中枢里常驻上报的机器超过十来台、每台机器又攒了几个月的高精度实例级历史曲线之后，性能瓶颈开始露头了。特别是在手机蜂窝弱网或者出门在外连回家里中枢的时候，点开首页或者切换设备详情页，明显能感觉到白屏等待变长了，中枢容器的 CPU 占用也比以前高了一截。

2026 年 10 月 20 日到 24 日，我专门停下新功能开发，给前端和中枢做了一次彻底的减负手术。

7 阶段加载性能工程：首屏 JS 从 213 KB 砍到 137 KB

在 10 月 20 日合入的一组连续更新（PR #74 至 #82，v3.0.161，Commit 43ec16f）中，我分 7 个阶段重整了全平台的加载链路：

  1. 本地缓存视图秒出：点开应用先用本地快照立即渲染骨架与上次已知状态，不等网络请求回来再画界面；
  2. 摘要优先于重型图表：首屏只拉轻量的实时状态胶囊，重型历史折线图按需延后下发；
  3. 目录与日历脱离全量历史：以前打开设备目录和在线日历会傻乎乎地去扫全量历史表，现在全部改走预聚合轻量接口；
  4. 弱网切页自动 Abort：快速在不同设备或时间范围之间切换时，自动调用 AbortController 取消还在路上的陈旧请求，防止旧数据晚到覆盖新视图；
  5. 打包体积精简：经过路由拆包与组件按需加载，首页与设备页的 First Load JS 从 213 KB 硬生生压到了 137 KB，直接缩减了 36%。

中枢服务端大扫除与静态产物托管

前端跑快了，后端中枢也不能拖后腿。4 天后的 10 月 24 日（PR #95 至 #96，v3.0.167，Commit 0390fa1），我把中枢服务端的代码从头到尾梳了一遍，砍掉了遥测数据写入、分钟/小时级聚合、Redis 读模型更新以及历史查询里的多处重复序列化与冗余计算，并将生产环境的 Web 控制台改为由 Fastify 直接高效静态托管，让中枢在高频推流下依然保持极低的内存和 CPU 开销。