使用约定 · 第 12 期
你可能会拿一条组件变更去跟评审对齐，也可能把整期变更记录导出来发给合作团队。下面把翻阅、引用、导出这几件事分开讲：哪些直接做就行，哪些记得写上出处，哪些先来一句确认。
适用于第 12 期版本说明
规范只有真的被用起来才算数，所以能放开的范围我们尽量放得宽一些。
在浏览器里打开版本专区，按栏目翻到某一期，随时回看。想打印一份贴在工位上，或者投屏给团队一起看，都可以，不用事先问过我们。第 1 期到第 12 期的内容都留在原位，新一期上线不会把旧期覆盖掉。
把某条界面规范或交互模式的片段复制进你们自己的规范文档、需求稿、代码注释，都是正常用法。建议顺手写上期号、栏目和条目编号——组件库现在收录 148 个基础与业务组件，半年后同事回头找一个细节，有编号能直接定位。
放进给客户或合作方的提案、交付文档、培训材料里也可以。前提是写明来源是 UED 版本说明的哪一期、哪个栏目，并且不要把我们的条目改写一遍后署上你方名义。如果要成体系地整段转载，或者打算做成对外课程、付费资料，先发一封邮件说明用途，我们通常当天就能给出答复。
变更记录以 CSV 与 Markdown 两种格式导出，一次最多 500 条。条目更多时按栏目或类型分批导出，分几次就能拿全。
如果导出时提示条目超过上限，先按栏目拆一次，通常两三次就够；拆分后的文件请注明它属于同一期的第几部分，免得后续对不上号。
每期版本说明都对应一个固定分享链接，指向的内容不会因为下一期上线而跳走。引用时把下面两行写全，追溯起来最省事。
来源：UED 版本说明 · 第 12 期 · 组件库 · 优化
链接：版本专区 /tools/ 第 12 期条目期号写到「第 12 期」就够了，不必抄整段标题。如果某个栏目在不同期里反复调整过，把两次期号并列写出来，读者自己就能看出先后顺序。固定链接放在内部知识库、交付文档或者邮件签名里长期使用都可以。
链接打不开时，先照使用指南里的步骤排查浏览器版本。排查后仍然不行，把链接和当时的页面截图发到 kefu@creative-ued.com.cn，我们查一下是不是条目换了位置，或者那一期做过修订。
规范要跟着实际实现走，所以条目会改，也偶尔会退场。这两种情况都会在原位置留下痕迹，不会让引用过它的人扑空。
保留原来的条目编号，在条目末尾标注修订的期号与调整点。按旧表述做的方案仍然能在历史记录里找到依据，跟你当时的判断对得上。
条目标为「下线」，写明替代条目或下线原因，仍旧留在它所属的那一期里。下一期会再补一条说明，方便沿时间线回看这条线是怎么走到今天的。
表述有误、示例与说明对不上，或者某个组件的状态说明缺了一块，把期号、栏目、条目编号和页面截图发到 kefu@creative-ued.com.cn 就行。工作日 10:00-18:00 内回复；确认是错的，我们会在当期更正，并在下一期把勘误列出来。
版本说明写的是我们推荐的界面做法与实现方式，按每期发布时的状态提供。行业之间的差异比想象中大：技术栈、用户规模、监管要求各不相同，把它落进项目前，请在自己的环境里跑一遍。
组件在你需要支持的浏览器里表现如何，最好亲自验一次。我们验证过的范围是 Chrome 90+、Edge 90+、Firefox 88+ 与 Safari 14+，更早的版本可能缺少部分特性。金融、政务等有明确监管要求的场景，以你方合规团队的意见为准。
直接套用条目产生的业务后果由使用方承担。我们能做的是把每条变更的来龙去脉写清楚——哪一期、哪个栏目、什么类型、为什么改，出问题时陪你一起回溯到具体条目。