应通过语义化组件封装工具类，用业务名称如替代样式类名，按场景而非样式抽象组件，保留className等灵活扩展点，并辅以命名规范与文档降低认知成本。
工具类（Utility Classes）确实容易让 HTML 变得“语义模糊”，比如 mt-4 p-2 bg-blue-500 text-white rounded 这类写法，一眼看不出组件意图。解决核心不是弃用工具类，而是通过语义化组件封装，把“样式细节”收起来，把“业务含义”露出来。
用组件名表达业务意图，而非样式特征
避免直接暴露工具类组合，转而创建有业务含义的组件。例如：
- 不写：
- 改写为：
内容 提示信息 组件内部用工具类实现，但调用方只关心“这是张卡片”或“这是个信息面板”，而不是“它用了 flex、padding-4、灰色背景”。这样 HTML 可读性、可维护性都提升。
按场景提取原子/分子组件，而非按样式抽象
不要为了复用而抽象出
BtnPrimary、BtnSecondary这类纯样式组件（除非项目极小）。优先按使用场景封装，比如：立即学习“前端免费学习笔记（深入）”；
-
-
-
每个组件名回答“它做什么”，而不是“它长什么样”。样式细节藏在组件实现里，甚至可以结合 Tailwind 的
@apply或 CSS-in-JS 提炼可复用的工具类组合。保留工具类的局部可调试性，不彻底隔绝
封装不等于黑盒。可在组件内部留出
className或extraClassesprop，允许上层微调：...
这样既保持语义主干清晰，又不牺牲开发时快速调整样式的灵活性。关键是在“约定默认行为”和“支持必要覆盖”之间找平衡。
配套文档 + 组件命名规范，降低认知成本
团队协作中，再好的封装也需共识。建议：
- 组件命名统一用 PascalCase，动词+名词结构（如
ConfirmDialog、SearchFilter） - 每个组件配简短说明：“用于确认高危操作，点击确定后触发回调并关闭”
- 在 Storybook 或内部 Wiki 展示典型用法和变体，避免“猜用途”
命名即文档。一个叫
UserAvatarBadge的组件，比FlexRowCenteredSmallCircleBgBlue更让人安心。工具类本身不是问题，问题在于谁在读、为什么读。把样式交给机器（编译器、开发者工具），把语义留给团队——组件封装就是那座桥。
- 改写为：
