设计 Token：别把“剪枝”当成性能万能药

设计 Token别把“剪枝”当成性能万能药Token 变多后确实值得关注构建产物和主题切换的成本但不能只凭变量数量断定浏览器一定慢。先测实际页面主题切换影响了哪些组件样式计算、绘制和布局各花了多少时间。没有使用路径的百分比没有参考价值。静态扫描只能给候选项静态分析可找出源码里的var(--token)引用却看不到运行时拼接、主题覆盖和外部组件。把扫描结果作为“待复核 Token”而不是直接删除清单生产构建和文档示例都要覆盖到。const used new Set(scanSourceForTokenReferences(sourceFiles)); const candidates allTokens.filter((token) !used.has(token.name)); writeReviewReport(candidates);观测的是用户路径PerformanceObserver 可以记录长任务和布局偏移但无法指出长任务一定由样式重算引起。把它和浏览器性能轨迹、发布版本和页面路由关联才有排查价值。采集时只传聚合指标和匿名页面标识不上传 DOM 内容或用户输入。删除候选 Token 前先在预发布环境打开所有主题并跑一遍组件文档。某些变量只在节日主题、空状态或第三方组件的覆盖层里出现源码扫描很难碰到。若确认无引用再把删除项和替代关系写进变更说明出问题时可以快速恢复不必从压缩后的 CSS 里反推名称。Token 的问题常在命名和层级看起来数量很多不一定说明需要剪枝。有时真正的问题是同一个语义被命名成了多个层级页面里写品牌蓝组件里写主按钮蓝主题里又写强调蓝却没人说清谁该引用谁。先整理基础色、语义色和组件别名之间的关系才能判断哪些变量只是重复哪些是为覆盖场景保留的必要边界。直接把名称相近的 Token 合并容易让一个局部改色牵动不相关的组件。主题切换性能也不只由变量个数决定。若切换时给根节点换一组变量浏览器需要重新计算哪些元素受影响实际成本取决于页面规模、选择器和使用方式。测试应覆盖真实的组件密度和主要路由并把首次切换与重复切换分开看。只有在明确的用户路径里观察到问题才值得为构建裁剪或拆分主题包增加复杂度。删除动作要能安全撤回把候选 Token 分批处理每批关联一个小范围的组件或主题并在变更记录中留下旧名、替代名和删除理由。这样出现颜色异常时排查不会变成全库搜索。文档站、邮件模板和嵌入式页面有时与主应用使用不同构建链路发布前要确认它们是否仍能读取同一份变量定义。对于第三方组件优先在边界层做映射不要把对方的私有变量复制进自己的全局 Token 表。映射层可以清楚表达依赖关系也能在第三方升级时集中调整。Token 管理的目标不是让表格变短而是让每次改色都能找到来源和影响范围。文档中最好为每个语义 Token 放一个简短的使用例子尤其是成功、警告、边框和层级阴影这类容易被滥用的值。示例不需要长篇解释只要说明适用场景与不该使用的场景。新增变量前先搜索是否已有能表达同样含义的名称如果确有例外说明例外来自主题、组件还是内容状态。这样的约束能减缓 Token 再次膨胀也能让剪枝在将来更有依据。审查时重点看语义是否准确而不是只看变量名是否简短。名称漂亮却无法指导使用仍会让主题覆盖和组件维护变得混乱。