高内聚低耦合：组件化设计的底层逻辑

先给出一个核心观点：高内聚低耦合绝不仅仅是挂在嘴边的口号，而是让组件真正具备可维护性、可复用性与协作能力的底层设计原则。简而言之，核心就两条：组件内部的功能要“紧密聚合”，组件之间的联系要“松散耦合，仅通过接口进行通信”。

高内聚：一个组件只专注做好一件事

如何判断组件的内聚性是否合理？标准很直接：如果你在描述这个组件时用了“和”“或”“同时”这些词汇，那它很可能需要拆分。例如，“用户卡片+编辑表单+权限校验”一股脑塞进一个组件里，就是典型的职责过载现象。

• 把展示逻辑（头像、昵称、状态）收纳进 UserCard 组件，它只接收一个 user 对象作为唯一的 prop
• 把编辑行为单独抽离为 UserEditor，由父级控制它的显隐，编辑完成后通过 emit 提交事件
• 权限判断不写在组件内部，而是通过 prop 传入一个 canEdit: boolean，让业务层来决定权责归属

低耦合：组件之间仅依靠明确契约进行通信

低耦合的核心原则是：不直接修改对方的数据，不依赖全局状态，不跨层级调用对方的方法。组件之间的通信必须有边界、可追溯、可替换。

• 父子通信老老实实走 props + emits：子组件只负责响应 props 的变化，所有意图都通过 emits 向上抛出
• 跨层级或兄弟通信，使用 事件总线（mitt）或 provide/inject，但仅限于那些稳定、低频、非核心的逻辑，比如主题切换这种全局性的需求
• 绝对不要用 this.$parent.xxx 这种写法，也不要直接 import 其他组件的实例去调用它的方法——这等于把两个组件焊死在一起，以后想拆都拆不开

三层组件边界必须清晰

拆分组件不是为了拆而拆，而是按职责分层，让每一层专心解决一类问题。这就像团队分工一样，各司其职才能高效协作。

• 页面组件（Page）：对应路由，只做调度工作。它负责拉取初始数据、组织业务组件、处理路由参数，模板里几乎看不到具体的 UI 元素
• 业务组件（Feature）：封装领域逻辑。比如 OrderList 负责订单筛选、分页、状态流转这些事，但它不关心按钮长什么样、用什么颜色
• 基础组件（UI）：纯视觉与交互。比如 BaseButton 只管尺寸、颜色、加载态，完全不掺杂任何业务语义

拆分粒度：以复用性和心智负担为尺子

到底拆到什么程度才算合适？拆得太粗，难以复用、难以测试；拆得太细，嵌套深、传参多、调试累。关键就看一个硬指标：它能不能被不同的场景重复使用。

• 一个搜索框，如果只在订单页使用，并且带了订单专属的过滤逻辑，那就属于业务组件 OrderSearchBar，没必要硬拆
• 如果多个页面都需要输入关键词、支持清空、防抖这些通用功能，那就值得升级为基础组件 BaseSearchInput，再用 slot 或 scoped slot 来扩展右侧图标
• 那连 loading 图标都单独抽成一个 IconLoading 组件？这其实没必要——它只是 BaseButton 的一部分，属于实现细节，不是独立职责