我喜欢把 UI 基础组件复制到项目中，因为组件库因此成为应用的一部分，团队可以阅读和修改。
这是 shadcn/ui 方式最有价值的地方。组件不藏在黑盒包里，团队能让它们适应产品自己的语言。
这对重复出现的对话框、表单、表格、空状态、提示和菜单尤其重要。视觉应一致，但文案和行为仍需对应具体动作。删除与提交对话框可以共用基础组件，却不该共用含糊的说明。
对话框基础组件：共享
操作文案：具体
权限检查：由工作流负责
结果处理：由工作流负责组件系统应简化共同结构，而不是隐藏产品决策。例如确认框可统一布局、焦点行为、按钮和无障碍标签，工作流仍决定确认什么、用户是否有权限、确认后发生什么。
ConfirmDialog 可以共享；暗中理解所有领域操作的组件，则越来越难以复用和信任。
取舍在于所有权。复制进来的组件就是你的代码：无障碍改进、设计调整和更新都由团队负责，比接受成品库默认值需要更多工作。
对产品应用而言，这通常值得。空状态要解释下一步，提示要准确说明发生了什么，表单错误要符合流程。这些并非通用组件库能替产品决定。
图标也类似：一致图标集有助于识别，却不能替代清晰说明。危险操作需要准确文字，含义不明显的工具栏按钮需要无障碍标签或提示。
应用有重复交互、团队希望控制细节、需要按产品审核无障碍和文案，且一致性比视觉新奇更重要时，我会选这种方式。
很小的原型可能不值得建立完整组件系统，也不应把每个共享组件做成庞大抽象。有时复制一个基础组件，提供清楚的 props 就够了。
价值不在于界面像某个库，而在于常见交互一致且可编辑：普通路径可预测，每个工作流仍能准确表达自己的含义。