标准答案
- 先用依赖图找出受影响应用和使用频率最高的组件或 API。
- 破坏性变更通过 major 版本、兼容层或迁移期逐步推进。
- 提供迁移指南、示例、codemod、lint 规则或弃用告警。
- 选择低风险应用先灰度，再扩大到核心应用。
- 升级后观察错误率、样式回归、构建失败和用户路径指标。
题目解析
共享基础库的风险来自影响面。一个按钮组件、主题 token 或请求 SDK 的变化，可能同时影响多个业务线。
降低风险的关键是分批和可回滚。先识别使用方，再给兼容期，最后逐步收敛旧 API。
设计系统升级还要关注视觉回归。样式变量、间距、颜色、弹窗层级变化，都可能在业务页面里产生非预期效果。
常见误区
- 基础库一次性全量升级所有应用，没有灰度和回滚。
- 删除旧 API 前没有迁移指南和弃用期。
- 只跑构建，不做视觉、交互和核心路径验证。