企业官网建设流程全解析

设计 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 再次膨胀，也能让剪枝在将来更有依据。

审查时重点看语义是否准确，而不是只看变量名是否简短。名称漂亮却无法指导使用，仍会让主题覆盖和组件维护变得混乱。