高可维护性Vue组件库的关键在于按职责而非视觉拆分组件，明确三层结构（Base/Biz/Page），依据“跨业务复用能力”定位层级，警惕多状态修改、props过载等拆分信号，并动态调整边界。
设计一个高可维护性的 Vue 组件库，关键不在“拆得多”，而在“拆得准”——组件边界是否清晰，直接决定后期能不能轻松改、放心复用、快速定位问题。
按职责而非视觉划分边界
很多人一上来就按页面区块切：左栏、右栏、顶部导航……结果是组件看着多，实则逻辑缠绕、状态共享混乱。真正该依据的是“它要做什么”，而不是“它长什么样”。比如一个带搜索+筛选+分页的商品列表区域，不能整个打包成 ProductListSection；而应拆成：
- SearchBar：只处理关键词输入与回车/清空事件，不关心数据怎么查
- FilterPanel：只管理筛选项勾选状态，输出筛选条件对象
- Pagination：只响应页码跳转，不参与请求发起或数据渲染
- ProductGrid：只负责把传入的数组渲染成卡片，不触发任何 API
每个组件只对输入（props）和输出（events / slots）负责，内部无副作用、不操作外部状态。
三层组件结构必须明确
一个健康组件库天然有层级，越往上越业务，越往下越通用。混淆层级就会导致“基础组件里写接口调用”或“页面组件里塞样式逻辑”：
立即学习“前端免费学习笔记（深入）”；
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
-
基础组件（Base）：按钮、输入框、图标、加载骨架等。无业务语义，仅提供 UI 原语和最小交互。命名如
BaseButton、BaseInput -
业务组件（Biz）：封装某类业务流程，如
OrderStatusBadge、AddressSelector。依赖基础组件，但不暴露底层细节；可跨项目复用，但需适配业务规则 - 页面组件（Page）：仅存在于具体路由下，组合业务组件与基础组件，协调数据流与生命周期。不对外导出，也不放入组件库包中
判断一个组件该放哪一层，就问一句：把它挪到另一个业务系统里，去掉样式和文案后，还能直接用吗？能——放 Biz；不能但抽象后能——重构为 Base；完全不能——它本就不该是组件，而是页面逻辑。
拆分信号：当代码开始“跨域说话”
组件边界模糊时，往往伴随一些危险信号，出现任一情况，就是该拆的明确提示：
- 一个组件同时修改多个 store 的 state，或直接调用多个 API
- props 超过 5 个，且类型混杂（既有配置、又有回调、还有原始数据）
- 模板里出现
v-if嵌套三层以上，或逻辑判断分散在多个地方 - 单文件代码行数稳定超过 300 行（不含注释和空行）
- 测试用例写起来困难：要 mock 大量上下文才能测清一个行为
这不是教条，而是经验反馈——这些现象背后，往往是单一职责已被突破，耦合已悄然发生。
边界不是静态的，要随演进而调整
组件边界不是画完就定死的。随着业务发展，原来独立的 UserCard 可能因新增“编辑头像”“设为管理员”等功能，变得越来越重。这时就要审视：
- 新功能是否属于所有用户卡片共性？是 → 扩展 props/events 接口
- 是否只在特定场景出现？是 → 提取为
UserCardActionSlot或新组件UserCardAdminActions - 是否改变了核心语义？比如从“展示卡片”变成“可编辑身份卡片”——那就该重命名为
EditableUserCard，并保留旧名作兼容别名
边界是活的，维护性恰恰体现在敢于重构、乐于拆解，而不是把“已存在”当作不可触碰的理由。
