设想一个多人维护的后台程序里有一个叫 BaseTable 的公共组件。

最初的复用对象，其实只有表格外壳

回头看 BaseTable 的第一版。职责很清楚：

这个组件复用的是稳定结构：表格、加载状态和分页器。

再看业务痛点，功能膨胀导致代码混乱

• 开发者困惑："为什么表格组件变得越来越难维护？"
• 产品经理困惑："新需求怎么总是要改动底层组件？"
• 测试困惑："为什么修改一个小功能会影响多个页面？"
• 运维困惑："每次上线都要重启所有服务吗？"
• 使用者困惑："为什么一样的操作在不同页面结果不一致？"
• 管理层困惑："为什么团队效率在下降而bug却在增加？ "
• "
• 不敢随便动！"
• Maintainer 心声："我只想让它简单展示数据！"😵‍💫😵‍💫😵‍💫

配置项越多，调用方越难知道哪些能够组合

业务痛点这方面。配置地狱与边界模糊化

• "为什么我的表格突然无法批量导出了？" — 操作日志页面开发者
原因:  某个配置项被其他页面误改动了...

▪️ "selectable=true但没有提供rowKey会导致什么问题?怎么说呢，" 谁有权限?" ▪️ "单元格合并时选择列应该如何处理?" ▪️ "横向滚动预留宽度是多少?" ▪️ "空数据时分页器应该隐藏吗?" ▪️ "这根本不是公共组件该做的事情!"

改造时先把业务能力搬回页面

从实际案例分析来看，

✅ 原始代码:

<BaseTable
show-export
export-text='导出订单'
permission-code='order:export'
@export='exportOrders'/>

❌ 改造后:

<OrderToolbar
v-if='canExport'
@export='exportOrders'/>

<BaseTable :columns='columns' :data='rows' :loading='loading'/>

⚠️ 注意事项:

▪️ 公共组件只负责基础渲染和布局

▪️ 调用方负责具体业务逻辑和行为

▪️ 分离关注点。减少意外副作用

▪️ 提高可测试性和可维护性

▪️ 减少全局状态污染风险

▪️ 提高团队协作效率

▪️ 防止技术债积累过快

▪️ 提高程序稳定性和可靠性

+++++ html-toc.md.md