应引入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，在无障碍测试中会被直接判定为阻断级缺陷——这比改三行主题变量麻烦得多。