样式基础篇已经讲过方案选择，这一篇继续往设计系统和项目协作层面深拆。因为 React 项目真正难的，通常不是“这一页怎么写样式”，而是：
- 页面越来越多以后，视觉是否还能一致；
- 主题是否可扩展；
- 组件库和业务壳层如何协同；
- 样式方案是否真的服务了设计系统，而不是只服务了局部开发效率。
为什么样式问题到后期会变成系统问题？
因为项目一旦起量，最容易暴露的不是某个 class 写错，而是：
- 同类组件有多套视觉规则；
- 间距、字号、颜色层级不一致；
- 主题切换无抓手；
- 业务页面直接面对原始组件库 API；
- 页面看起来都能用，但不像同一个产品。
这说明样式问题本质上已经不只是 CSS 写法问题，而是设计系统和组件治理问题。
主题为什么不能只靠“改几个颜色变量”理解？
真正的主题体系通常会牵动：
- 主色和辅助色；
- 背景层级；
- 边框和阴影；
- 间距体系；
- 字号和权重；
- 组件状态色。
如果这些规则没有被沉到令牌层，而只是散在各个组件和页面里，后续任何品牌主题、租户主题或视觉升级都会非常痛苦。
组件库为什么一定要和业务壳层一起看？
因为组件库提供的往往是通用能力，而业务系统真正高频使用的通常是：
- 搜索表单壳层；
- 列表页骨架；
- 统一表格壳；
- 弹窗和抽屉交互规范；
- 表单字段模式；
- 错误、空态和 loading 模式。
如果项目长期直接裸用组件库，而不沉淀业务壳层，后面同类页面很容易写出多套风格和逻辑。
样式方案与设计系统为什么必须协同？
因为样式方案只是“怎么写”，设计系统解决的是“写什么规则”。你可以用 CSS Modules、Tailwind 或 CSS-in-JS，但如果没有统一令牌、组件变体和交互规则，页面依然会发散。
真正成熟的前端系统，通常会同时做到：
- 视觉令牌统一；
- 组件变体稳定；
- 页面骨架模式清楚；
- 样式方案和设计规则相互配合。
把这件事放回项目里，最重要的判断是什么？
更稳的顺序通常是：
1. 先确定设计规则和主题令牌；2. 再确定样式方案怎样承接这些规则；3. 组件库之上沉淀业务壳层；4. 页面尽量消费稳定组件而不是原始样式能力；5. 视觉一致性优先于局部“写起来很快”。
最常见的几个误区
1. 样式方案选了，就以为设计系统自动成立
实际真正难的是规则沉淀。
2. 组件库裸用到底
长期会让业务页面风格越来越散。
3. 主题只改颜色，不管层级和状态规则
扩展性会明显不足。
4. 页面直接承接大量原始样式细节
后续统一会很难。
总结
React 样式与设计系统真正要建立的，不是某套写法熟练度，而是“令牌、主题、组件库、业务壳层”怎样形成统一协作。只要你先把设计规则沉到稳定层，再让样式方案和组件库围绕这些规则工作，项目的视觉一致性和长期维护性都会明显更强。