直接在图表渲染引擎中用 static 关键字管理字体度量缓存，核心是利用其“单例生命周期+初始化一次+全局共享”语义，避免重复计算字体宽度、行高、基线偏移等高开销操作。
直接在图表渲染引擎中用 static 关键字管理字体度量衡缓存，核心不是语法本身，而是借助其“单例生命周期 + 初始化一次 + 全局共享”的语义，避免重复计算每种字体在不同字号、权重、语言子集下的文本宽度、行高、基线偏移等度量值——这类计算在 Highcharts、ECharts 或自研 Canvas/WebGL 渲染器中非常耗时，尤其当动态生成大量 Label、Tooltip、Axis Tick 文本时。
字体度量衡为何是高开销环节
浏览器原生不提供批量或缓存式字体度量 API。每次调用 ctx.measureText(text) 或依赖 getComputedTextLength()（SVG）时，引擎需：
• 触发字体加载（若未就绪）
• 解析字体文件元信息（如 ascender/descender、x-height、glyph advance）
• 按当前字号、字重、OpenType 特性做排版模拟
• 逐字符计算并累加宽度
这对高频更新的图表（如每秒重绘 tooltip 或滚动标签）极易成为 CPU 瓶颈。
用 static 实现缓存统一物化
以 TypeScript 为例，在渲染器工具类中定义静态度量缓存对象：
${fontFamily}-${size}-${weight}-${subset}关键点： • 缓存声明为 static，脱离实例生命周期，跨图表、跨 series、跨重绘帧复用 • key 设计包含字体家族、字号、字重、字符子集，确保精度与复用平衡 • 首次调用触发真实测量，后续全走内存查表，开销从毫秒级降至纳秒级
配合 next/font 或 BMFont 提升缓存命中率
单纯 static 缓存还不够——如果字体本身未预加载或格式不一致，key 会频繁失配。建议组合使用：
- 用
next/font（Next.js）或@font-face+ preload 提前加载字体，确保measureText不阻塞 - 对 UI Label 类文本，优先采用 BMFont 打包的位图字体，其度量值完全静态可预知，static cache 可直接固化为常量映射表
- 避免运行时动态拼接 font-family 字符串（如
font: `bold ${size}px ${userFont}`），会导致 key 泛化失效
注意边界：static 不等于线程安全
在 Web Worker 或多线程渲染场景（如 ECharts 的 WebGL 后端分离线程），static 缓存无法跨线程共享。此时应： • 主线程维护一份全局 static 缓存，Worker 通过 postMessage 查询 • 或改用 SharedArrayBuffer + Atomics 构建跨线程缓存结构 • 更推荐将字体度量预计算为 JSON 资源，在构建期生成并注入，彻底规避运行时测量
