The Component Gallery

The Component Gallery 是由前端开发者 Iain Bean 整理的界面组件案例库。它把真实设计系统中的组件截图、命名和来源集中到统一目录，适合在写交互规范或选择实现路线前做横向研究；它不是可直接安装的组件包，也不会替团队决定最终的视觉、状态或无障碍行为。

从交互问题进入，而不是先挑一套 UI 库

组件目录当前收录 Accordion、Combobox、Datepicker、Modal、Pagination、Tabs、Tree view 等 60 类模式，并列出各自常见别名。例如 Combobox 页面会同时提示 Autocomplete、Autosuggest，Dropdown menu 页面则明确与表单 Select 的用途不同。先用产品里的真实问题搜索这些名称，比用“高级组件”“现代 UI”一类宽泛词更容易找到对应案例。

以“可搜索的城市选择器”为例

1. 先查 Combobox，确认需求是输入后过滤候选，而不是只能从固定列表选择的 Select。
2. 打开多个设计系统案例，记录是否支持无结果、异步加载、清空、键盘选择和移动端触控。
3. 把候选系统的官方组件页另存，继续核对状态、属性、代码和无障碍说明。
4. 用自己的数据量、语言长度和错误场景制作原型；图库截图只用于发现方案，不作为完成验收。

按技术栈和证据完整度缩小设计系统范围

Design systems 目录可按平台、技术和资料特征筛选。当前平台项包括 GitHub、Figma、Storybook；技术标签包括 React、Vue、Web Components、Angular、Tailwind CSS 等；资料标签则区分 Code examples、Usage guidelines、Accessibility、Open source、Tone of voice、Unmaintained 和 Accessibility issues。

Polaris 的卡片标有 Web Components、代码、使用指南、无障碍和语气规范；Elastic UI 显示 React、CSS-in-JS、代码示例与开源；Ariakit 则显示 React、代码、开源和无障碍。标签能帮你筛选，但并不证明每个组件都完整覆盖这些维度。

用四列对照表把浏览变成设计决策

比较同一组件时，建议只记录四类内容：组件叫什么、解决什么状态、交互怎样推进、原系统提供什么证据。视觉差异排在最后，因为同名组件在电商、银行、政府服务中的风险和信息密度不同。若一个案例只有截图，没有使用条件、代码或可访问性说明，可把它作为灵感参考，但不要把它放进生产实现候选。

• 命名：别名是否会让设计、产品和开发误解，例如 Dropdown 与 Select。
• 状态：默认、悬停、焦点、禁用、加载、空结果和错误是否齐全。
• 行为：键盘顺序、关闭方式、内容溢出和窄屏变化是否有说明。
• 证据：官方指南、Storybook、源码、Figma 和维护状态能否互相对应。

收录标准说明了它能证明什么

站点要求被收录的设计系统必须公开可访问、能用于真实产品开发并有底层代码证据，而且要与既有系统有实质差异。这提高了案例作为“真实系统样本”的价值，但不等于站点替每个来源审查许可证、兼容性或当前维护质量。采用前仍要回到原设计系统核对文档和仓库；若页面标记 Unmaintained 或 Accessibility issues，更应把它当作反例或历史参考。主入口：https://component.gallery/