旧组件如何下线？设计系统迁移与替换清单

旧组件下线应分三步：先说明为什么停止新增使用，并提供替代方案；再按真实使用场景迁移，检查设计与代码两侧；最后确认仍在运行的页面已经处理、保留恢复材料，再移除旧资源。不能因为组件库里有了新版就立即删除旧版，也不能用“已经发通知”代替迁移完成。

以一个混合承担单日和日期范围的旧DatePicker为例：报表日期、请假起止、生日都在使用它，替代方案却不相同。如果团队尚未约定组件负责人、版本和发布入口，可先按设计系统的搭建与维护步骤补齐基础，再决定这个旧组件如何退出。

先说明停用原因，不把换外观当成必须迁移

组件需要下线，通常是旧结构已经无法准确表达任务，维护成本过高，或存在无法在兼容范围内修复的问题。仅仅觉得新版圆角更漂亮，不足以要求所有业务立即替换。先写清旧组件解决不了什么，以及继续使用会产生什么具体影响，业务团队才能判断优先级。

本例中的旧DatePicker用同一套属性切换单日和日期范围，业务文件又各自补了说明与校验。团队决定将它拆成单日选择器和范围选择器，让两种输入模型更明确。迁移理由因此是语义与行为分离，不是把控件名称换得更现代；旧页面是否受到影响，要逐个查看实际用途。

还应区分“不再推荐新增”和“立即不可用”。旧组件可能暂时仍支持现有页面，但不希望新项目继续增加依赖；这时应在文档和资源入口标明替代方式，而不是偷偷把它从所有位置隐藏，让维护旧项目的人找不到原定义。

Atlassian 的发布阶段说明区分计划弃用与已弃用，并要求在移除前公布过渡安排与替代方案。可以借鉴这种阶段意识，但不必照搬其版本号、时间长度或产品内部流程。团队需要的，是能说明当前可做什么、何时必须处理的清楚规则。

盘点使用方，比搜索一次组件名更重要

先从设计库里找主组件、嵌套组件与实例，再检查业务文件中的实际页面。一个旧DatePicker可能被嵌在搜索筛选区、请假表单或个人资料卡里，组件名没有直接出现在页面清单上。还可能存在已经解除关联的本地副本：它不会跟随库更新，却仍保留旧交互问题。

代码侧则要确认实际使用的组件、封装层与版本。设计稿里已经换成新控件，不代表线上实现已经升级；研发删除了旧依赖，也不代表设计团队停止向新项目输出旧版。两侧需要各自记录，再通过业务页面和任务关系对齐，而不是只统计一个总数量。

盘点表可以包含业务页面、使用目的、设计来源、实现来源、负责人、当前版本和迁移状态。涉及外部交付或长期维护的项目，还要确认谁能安排更新。没有找到使用方时标记待确认，不能把没有权限查看的文件当成零使用，也不能把某个工具的统计结果直接外推到所有历史项目。

同样检查说明文档、模板和新人入门材料。这些入口可能不断把旧组件带进新文件，造成迁移一边进行、依赖一边增加。先停止新的传播，再处理存量，才能让下线范围逐步收敛。只有确实影响本次旧组件的材料需要更新，不必顺手重写整套设计系统。

同一个旧组件，可能有两条替换路线

不要建立一张只有“旧名→新名”的表就开始全量替换。先看每个实例要用户输入什么：报表页面选择某一天，请假需要开始与结束日期，生日是历史上的单日。前两种任务的数据结构已经不同，生日还有自己的年份范围与空值规则。外观都带日历图标，并不能证明它们可以共用相同替代方案。

映射不仅覆盖默认外观，还应逐项核对状态、属性、事件、数据格式和内容规则。旧组件的禁用态是否仍能查看已有值，错误信息是否靠近字段，清空后代表未筛选还是没有结果，都可能影响任务。新控件少了某种业务能力时，应先补充合理配置或明确独立实现，不能用“统一规范”掩盖功能丢失。

日期范围的具体状态，可以衔接日期范围选择器的边界设计，本篇只负责迁移映射。若旧资源还涉及变量重命名，也要单独列出变量映射，避免把组件替换与全站命名调整混成一次难以恢复的变更。

在 Pixso 画布中保留旧组件及三种业务实例，右侧放新单日与范围组件，用连线连接各自去向。给每条线附上最关键的保留条件，例如“生日保留历史年份选择”“请假保留开始结束校验”。这张映射图应能解释为什么同一个旧组件不能一键统一替换。

先迁移一条完整业务路径，不只替换孤立控件

选择范围清楚、负责人明确的页面做试点，例如先处理报表日期。迁移前保存可恢复的设计版本与实现版本，记录默认值、常用选择和异常状态。迁移后从进入报表、改变日期到查看结果走完整条路径，确认控件变化没有破坏查询参数、数据显示或键盘操作。

再选择结构不同的请假场景验证范围组件，而不是因为报表通过就认为全部场景通过。请假要检查只选开始日期、结束日期早于开始、不可选日期以及返回修改等状态。生日则重点看年份导航、旧数据回显和未填写的表达。每个试点的通过条件来自实际任务，不需要机械重复同一套截图。

Carbon 的设计迁移指南不仅介绍换库，也提醒检查未能完成的样式替换与嵌套组件覆盖。这类问题同样说明：库层操作完成只是迁移中的一步，业务文件里仍需确认结果。具体菜单和迁移工具要按实际平台核对，不能把其他工具的步骤直接当成Pixso操作。

试点出现缺口时，先判断是新组件缺少必要能力、映射错误，还是旧页面本来就有独立例外。把解决办法记录下来，再推广到下一批。不要让每个业务各自打补丁后仍宣称已经统一，否则旧组件虽然删掉，新一轮分叉已经产生。

用退出条件管理兼容期，不只写一个截止日期

可以把过程分成三个可理解的阶段。第一阶段停止新增依赖，旧项目仍按约定维护；第二阶段分批迁移，每个使用方有负责人、替代方案和进展；第三阶段达到移除条件，清理旧资源并保留可追溯记录。三个阶段都应清楚说明新项目和旧项目分别该做什么。

截止日期能推动安排，但不能替代证据。到期时如果仍有正在运行的项目未迁移，应该评估延期、限制支持或安排专门处理，而不是单方面删除后让业务自己发现故障。反过来，也不要因为一个无人确认的历史副本就让全系统永久停在迁移中；需要区分仍在运行、仅归档保留与已废止的项目。

移除前确认：活跃使用方已经接受替代方案；必要状态与数据回显验证完成；代码依赖和设计资源都已处理；文档与模板不再引导新增使用；剩余例外有明确处置与负责人。若还有无法解释的依赖，保持待处理状态，不用一个“完成百分比”掩盖它。

出现严重回归时，恢复方案应能指向具体旧版本和受影响范围，而不是一句“回滚即可”。哪些业务先恢复、哪些可以继续使用新版，也要按依赖判断。旧版材料保留用于恢复和追溯，不代表重新推荐给所有新项目。

组件移除后，留下能解释决定的记录

保留旧组件用途、停用原因、新组件入口、迁移映射和处理过的例外，让后来的设计师能查到为什么做过这次拆分。否则几个月后有人看到旧截图，可能又按原结构建出一个同名组件，把同样的问题带回来。

这份记录不需要很长，但应能回答三个具体问题：报表日期迁到了哪里，请假范围为什么不能用单日控件代替，生日保留了哪些配置。将它与Pixso中的组件对照文件和团队维护文档关联，后续新增业务就能沿用已解释清楚的选择，而不是重复讨论一遍。

旧组件是否成功下线，最终看业务任务还能否正常完成、新项目是否采用明确的新方案，以及是否还存在无人负责的旧依赖。组件库里少了一个名称只是操作结果，设计与实现的使用关系处理清楚，才是迁移真正结束的依据。