Sketch Symbols是可复用的主组件与实例关系：主组件定义结构，实例可以覆盖部分内容，主组件更新后实例继续继承变化。真正使用时要先划分稳定结构与可变内容，再检查覆盖是否会阻断更新。迁移到在线工具前，还需核对Symbol、文本覆盖、状态和资源路径能否保留。
先阅读Sketch与墨刀的协作和迁移场景对比，明确你是继续维护Sketch文件，还是需要在线评审与多人交付。下面用登录卡片完成一次从创建、覆盖到更新的练习，再判断哪些内容值得迁移。
主组件先拆稳定结构
登录卡片中，容器、标题层级、按钮位置和错误提示区域相对稳定；品牌名、插图、按钮文案和状态是可变内容。先把稳定结构做成Symbol，再暴露必要的文本、图片和状态覆盖，不要把每个图层都开放为可改字段。
| 部分 | 建议处理 | 原因 |
|---|---|---|
| 卡片容器 | 主组件统一控制 | 保证圆角、间距和阴影一致 |
| 品牌名称 | 文本覆盖 | 允许不同产品复用 |
| 按钮状态 | 分别建立状态 Symbol，按需替换嵌套实例 | 避免用临时颜色表达加载 |
| 错误提示 | 保留可见区域 | 长文案和多语言不挤压表单 |
做一个能复用的登录卡片
先在 Sketch 中准备品牌名称、标题、账号输入区、按钮和错误文案五组图层。把图层命名为 Brand、Title、Fields、Submit、Error，比“文本 12”“矩形 7”更容易在覆盖面板里找对象。错误文案准备“账号或密码有误，请重试”，不要用短横线占位，否则测试不出两行内容对卡片高度的影响。
- 先把按钮做成 Button/default Symbol，再创建 Button/loading，分别展示“登录”和“登录中…”。保持它们的基本尺寸和内部命名一致，方便替换及检查。
- 将一个 Button/default 实例放入登录卡片。选中卡片的相关图层，使用 Create Symbol 创建 Login/Card。按钮现在是卡片内部的嵌套实例，后续调整按钮 Source 时，可继续沿这条关系更新。
- 插入 Login/Card 的两个实例，分别用于企业登录和合作方登录。Source 留在组件管理位置；业务页面上使用实例，不复制一份不关联的普通图层来凑外观。
- 分别把品牌文字改成“企业工作台”和“合作方门户”，把第二个实例的按钮文案改成“继续”。此时两个卡片仍应共用结构，内容可以不同。
Sketch Symbols 官方说明区分了 Source、Instance 和嵌套关系。Source 管“这类卡片共同长什么样”，Override 管“这一张卡片具体显示什么”；这两个问题分开处理，后续才能统一改版而不丢业务内容。
只开放真正需要变化的覆盖项
选中卡片实例后，在 Inspector 中查看文本、图片、颜色及嵌套 Symbol 等覆盖项，先只调整品牌名和按钮文案。回到 Source 的 Symbol Settings，按团队需要关闭不应由页面随意修改的覆盖项，例如统一的标题样式；不要为了让实例“什么都能改”，把组件规范变成建议。
按钮状态需要变化时，替换卡片内的嵌套 Symbol，例如由 Button/default 换成 Button/loading。不要仅把按钮涂灰就表示加载：加载文案、图标、可点击条件和结束后的去向都需要成套考虑。不同状态是否接受点击，要在原型连线或交互说明中明确。
对单个实例做覆盖，不会把其他实例或 Source 的默认内容一起改掉。需要恢复默认时，可重置对应覆盖项，尽量不要重置整个卡片，把已经正确填写的品牌名和提示语一并抹去。覆盖的具体操作见Sketch Overrides 文档。
长文案撑开卡片，靠布局而不是手动拉高
登录卡片适合纵向布局：标题、输入区、错误提示和按钮依次排列。先约定卡片内边距及组间距，再处理各层宽度。标题和错误文案需要容纳多行；容器高度应随内容增长，不应由一张短文案截图决定固定高度。
新组件可用 Stack Layout 组织这些层。卡片可按内容设置 Fit 高度，输入区在父容器内使用合适的 Fill 宽度；图标保留明确尺寸。嵌套 stack 各有自己的尺寸规则，别只改外层就期待所有内层自动正确。Fixed、Fill、Fit 等具体适用对象见Stack Layout 官方说明，普通图形与文字并非在每个轴上都有同样的选项。
把标题换成“登录后继续查看企业协作项目”，错误提示换成两行，再隐藏错误提示做对照：按钮应随内容移动，卡片仍保留内边距。如果错误消失后留下大空洞，检查隐藏图层是否保留占位。老文件可能使用 Smart Layout；先测试既有响应行为，不能只因名称不同就拆掉所有历史组件重建。
实例更新要做三次检查
先改主组件结构，确认所有实例位置和尺寸没有异常；再修改默认文案，确认有覆盖的实例不会被误改；最后切换错误和加载状态，检查实例是否仍能表达完整任务。对于嵌套Symbol，要单独记录覆盖层级，否则问题很难定位。
| 对 Source 的改动 | 企业登录实例 | 合作方登录实例 | 异常时查什么 |
|---|---|---|---|
| 卡片内边距由24改为32 | 结构间距应更新 | 结构间距应更新 | 实例是否仍连接同一Source、布局是否被固定 |
| 默认标题改为“欢迎登录” | 未覆盖标题的实例应更新 | 已覆盖标题应保留业务内容 | 这项文字是否已有Override |
| 调整Button/default内部图标间距 | 使用默认按钮的卡片应跟随 | 换成Button/loading的卡片按其Source处理 | 当前嵌套实例究竟指向哪个Source |
| 重置一个品牌文本覆盖 | 该项恢复默认内容 | 其他实例不受影响 | 是否误重置了整个覆盖区 |
这一组检查能区分“更新失败”和“覆盖正在按预期工作”。实例没跟随某项文字变化，不一定是坏了；它可能正是在保护当地页面的业务内容。相反，所有实例突然变成同一品牌名，也未必是统一成功，可能是覆盖被重置。
组件越来越难改，先查这三个信号
- 每个页面都要拆开实例才能使用：说明开放的覆盖项或组件边界不合适。把经常一起变化的部分拆成嵌套 Symbol，不要继续积累脱离 Source 的副本。
- 换按钮后文字消失或位置异常：先看替换的是哪个 Source，以及内部层级、命名和尺寸是否兼容。不要凭两个按钮外观相似就认为覆盖一定能保留。
- 一次小改动影响所有卡片：确认改的是单个实例还是共用 Source。把需要全局修改和只服务当前业务的差异分开，再动手调整。
迁移前做小样本验收
不要一上来迁移整套设计系统。选登录卡片、表格行和弹窗三类组件，各准备默认、长文案、错误和禁用状态。迁移后逐项检查主组件—实例关系、字体、图片、交互连接和标注。任何无法保留的能力都写入差异清单，由设计和研发决定重建还是降级。
为每个小样本留一行迁移记录：原 Source 名称、实例数量、覆盖项、嵌套按钮、字体与目标工具中的对应对象。导入后的第一眼相似只证明外观接近，不能证明后续仍可统一更新。需要重建时，优先重建高频且结构稳定的组件，而不是把全部历史图层同时搬过去。
例如合作方登录卡片可按“品牌文字保持—长错误提示不截断—加载按钮可替换—修改公共间距能同步”四项验收。任何一项不成立，就注明需要调整的层级和组件；对无法保留的原型动作重新连线，不让迁移后的评审者误以为静态卡片仍能完整操作。
