应引入UI组件库，当反复重写DatePicker等交互组件时；Ant Design更适中后台，因其Form/Table/a11y支持更完善；SSR支持仅在Nuxt/Next等场景必要；自研仅当设计约束不可配、专人维护、5+高频组件跨业务复用时才合理。
项目已有 CSS 框架，还要不要引入 UI 组件库？
要看你是否在反复重写 DatePicker、Table、Modal 这类带交互逻辑的组件。纯 CSS 框架（如 Bootstrap CSS、Tailwind CSS）只提供样式规则和基础布局类，不包含 JavaScript 行为、键盘可访问性（a11y）、受控状态管理或服务端渲染适配——这些必须自己补全。
常见踩坑点：
- 用
tailwindcss+ 手写Dropdown，结果Esc关闭、焦点管理、屏幕阅读器标签全漏掉 - 基于
Bootstrap 5 CSS自己封装Form组件，但表单验证错误提示位置、异步提交 loading 状态、错误恢复逻辑分散在各页面
如果团队每周都在修这类“看似简单、实则深坑”的交互细节，那引入一个成熟的 UI 组件库不是加重负担，而是止损。
Ant Design 和 Element Plus 哪个更适合中后台系统？
选 Ant Design（React）或 Ant Design Vue（Vue），除非你明确需要桌面级富文本编辑器或复杂拓扑图——那是 Element Plus 少数仍保持优势的场景。
立即学习“前端免费学习笔记（深入）”；
原因很实际：
-
Ant Design的Form组件原生支持嵌套字段、动态增删、校验反馈联动，而Element Plus的el-form在深层嵌套时需手动维护prop路径和重置逻辑 -
Ant Design的Table支持虚拟滚动 + 树形数据 + 受控展开 + 多选跨页记忆，Element Plus的el-table开启virtual-scroll后会丢失expand-row-keys响应性 -
Ant Design所有组件默认启用aria-*属性且通过 WAI-ARIA 1.1 测试，Element Plus部分组件（如el-cascader）在键盘导航时存在焦点跳失
注意：如果你用 Vue 3 + script setup，Ant Design Vue 4 对组合式 API 的支持比 Element Plus 更彻底，比如 v-model:open、@update:visible 这类绑定更统一。
要不要选支持 SSR 的组件库？
取决于你是否用 Nuxt、Next.js 或自建 Node.js 渲染层。如果只是纯客户端 SPA（如 create-react-app 或 vue-cli 默认构建），SSR 支持毫无意义，反而可能因水合 mismatch 导致控制台报错 Hydration failed。
真实影响点：
- 组件内使用
window、document或依赖 DOM 尺寸的逻辑（如getBoundingClientRect()）在 SSR 环境下直接抛错，必须包裹if (typeof window !== 'undefined') -
antd官方不保证 SSR 安全，但ant-design-vue提供了defineClientComponent辅助函数；chakra-ui和radix-ui则从设计上规避服务端执行 DOM 操作 - 若你用
Vite+SSR，shadcn/ui（基于radix-ui）是目前最轻量且无 runtime 依赖的选择，所有组件都是纯函数组件，无副作用
自研组件库什么时候才合理？
只有当满足全部三个条件时才该启动：
- 现有主流库（
Ant Design、Mantine、Chakra UI）无法通过主题配置、插槽或子组件替换实现你的设计系统约束（例如：强制所有按钮圆角必须是6px且不可覆盖，而它们只接受theme.radius全局变量） - 团队中至少有一名工程师能持续投入 20% 工时维护组件的 a11y 测试、浏览器兼容性矩阵、TypeScript 类型收敛和变更日志
- 已沉淀出超过 5 个高频复用的定制组件（如带审批流状态的
OrderCard、支持多租户 Schema 的DynamicForm），且这些组件在 3 个以上业务线中被独立 import 使用
多数团队高估了“统一设计语言”的收益，低估了组件库的维护成本。一个没加 role="dialog" 和 aria-modal="true" 的自研 Modal，在无障碍测试中会被直接判定为阻断级缺陷——这比改三行主题变量麻烦得多。
