设计 Token 升级别让缺失变量静默回退设计 Token 最麻烦的地方是变量缺失时页面不一定报错。它可能安静地回退成透明色、继承值或浏览器默认样式等你看见时已经是一块“说不上哪儿不对”的界面。因此Token 改动比普通函数改名更需要发布前检查。先区分三类改动新增 Token通常风险小但仍要说明语义。旧名改别名保留兼容期并在构建或运行检查里提示迁移。删除或改变语义按破坏性变更发布先找出使用方再安排迁移窗口。用脚本找引用不替人做决定const removed new Set([--space-small]); export function findRemovedToken(value) { return [...removed].filter((name) value.includes(var(${name}))); }实际扫描应覆盖 CSS、组件样式和模板字符串也要允许有意识的例外。结果要包含仓库、文件和引用位置让维护者判断能否改成新语义简单的字符串替换很可能把品牌色或业务状态改错。发布前的最低检查为别名写回归用例编译一组代表性页面检查关键主题和状态的截图。发布说明写清废弃项、替代项和移除时间。把 Token 当公开接口管理升级时才不会出现“构建过了页面却坏了”的盲区。