核心用法
design-system-patterns 是一套面向企业级前端开发的设计系统架构指南，专注于解决大规模UI工程中的设计一致性与技术可维护性问题。该Skill提供了五大核心模式：三层令牌架构（原始值→语义映射→组件应用）、React主题切换实现、多品牌主题系统、Style Dictionary自动化管道，以及无障碍访问令牌。
使用场景覆盖设计令牌定义、暗黑模式切换、SSR水合闪烁修复、跨平台设计令牌同步（Web/iOS/Android）以及设计系统治理流程建立。开发者可直接复制代码示例到项目中，或将其作为团队设计规范的技术参考。
显著优点
架构完整性与生产就绪：提供的三层令牌架构（Primitive → Semantic → Component）是业界验证的最佳实践，与Salesforce Lightning、Atlassian Design System等成熟方案一致。React主题方案完整处理了系统偏好检测、localStorage持久化、hydration失配等边缘场景，包含内联脚本修复FOUC的具体实现。
多平台覆盖能力：Style Dictionary配置示例直接生成CSS变量、iOS Swift类、Android XML三种平台代码，解决了跨端设计系统长期存在的同步难题。多品牌主题方案通过data-attribute层级覆盖，无需改动组件代码即可实现白标产品定制。
工程化思维贯穿：包含令牌命名规范、版本控制策略（语义化版本）、变更管理流程（Propose-Review-Test-Deprecate-Remove）、CI/CD自动化建议，以及WCAG对比度自动化检测等治理手段。
潜在局限
实现依赖外部工具链：Style Dictionary、Figma Token Studio等工具需要额外学习和配置成本；文档未包含具体的设计工具集成步骤，团队需自行探索Figma到代码的同步细节。
React生态绑定较深：主题切换代码基于React Context和Hooks实现，Vue/Svelte/Angular项目需要额外移植工作。SSR修复方案针对Next.js设计，其他Meta-framework（Nuxt、SvelteKit）需调整实现。
未覆盖设计决策流程：技术架构详实，但缺乏"何时创建新token""如何处理设计师与工程师的令牌分歧"等组织协同指南，大型团队仍需补充设计运营（DesignOps）层面的流程设计。
适合群体
- 中大型企业前端团队：已有或计划建立设计系统，需要技术架构参考而非从零探索
- 跨平台产品团队：同时维护Web与Native应用，寻求设计令牌多平台同步方案
- 白标/SaaS产品开发者：需要为不同客户定制品牌主题，保持代码库统一
- 设计系统维护者：面临令牌膨胀、命名混乱、主题覆盖不全等技术债务，需要治理策略
不适合个人开发者快速搭建小型项目（学习成本高于收益），以及无设计资源的团队（缺少设计侧配合时令牌体系难以落地）。
使用风险
性能方面：CSS自定义属性在大量DOM节点场景下存在渲染性能开销，极大规模应用需测试令牌层级对样式计算的影响；theme切换内联脚本会阻塞首次渲染，需评估对Core Web Vitals的影响。
技术债务风险：令牌层级一旦建立，后期重构成本极高（类似数据库schema迁移），团队需在项目早期充分讨论架构决策；多品牌主题的data-attribute方案会增加CSS选择器复杂度，需配合构建工具优化。
维护连续性：作为T3来源（个人开发者）的社区项目，无商业支持承诺，长期维护依赖社区贡献。建议团队fork后自主维护关键文档，或将其作为一次性架构参考而非持续依赖的依赖项。