如何处理公共组件
在 Vue 或 React 开发中，当多个页面需要复用同一个组件时，组件的存放目录应该遵循以下原则：
推荐方案：提取到公共文件夹
-
独立于具体页面
- 如果组件是通用型的（会被 3 个及以上页面使用，或具有明确的独立功能）
- 路径建议：
src/components/ - 例如：
Button.vue、DataTable.vue这类全局通用组件
-
页面级共享
- 如果组件目前只在 2 个特定页面间共享，但可能具有业务特殊性
- 路径建议：
src/views/components/或src/views/xxx/components/ - 例如：
OrderList组件被OrderHistory和OrderManagement两个页面使用
不推荐方案：直接引用其他页面的组件
❌ 避免直接从另一个页面导入（如 import X from '../PageA/components/X'），因为：
- 会产生隐式耦合，修改 PageA 时可能意外影响 PageB
- 降低组件可维护性，后续难以追踪使用关系
- 违反单一职责原则，组件职责边界不清晰
如何划分组件
| 特征 | 通用组件 | 跨模块组件 | 页面级组件 |
|---|---|---|---|
| props | 尽量简单（基础数据类型） | 可能包含业务数据对象 | 强耦合业务数据 |
| 依赖 | 不依赖Redux/Vuex | 可能依赖部分Store模块 | 依赖完整业务Store |
| 样式 | 独立样式（CSS-in-JS或scoped） | 可能继承父样式 | 紧密耦合父样式 |
决策流程图
graph TD
A[发现重复组件] --> B{"是否含有业务功能?"}
B -->|是| C["放入 src/components/"]
B -->|否| D{"是否跨多个功能模块?"}
D -->|是| E["放入 src/views/components"]
D -->|否| F["放入相关功能域的 src/views/xxx/components/ 目录"]
维护建议
- 渐进式演进：从简单结构开始，随复杂度增长逐步拆分
- 当第二次复用时，立即提升到公共目录
- 严格边界：禁止跨模块直接引用私有组件（如
views/order不能直接导入views/payment的内部组件） - 公共组件引用采用绝对路径
@/src/components或者@/src/views/xxx/components，避免相对路径../../components。方便组件提升后，批量修改。 - 定期进行代码审查，发现隐藏的重复组件
最终原则：让文件位置反映功能归属，让开发者能通过目录结构快速理解业务架构。
复杂项目（模块划分）
src/
components/ # 公共组件
utils/ # 公共函数
views/ # 业务模块
product/ # 商品模块
components/ # 模块专属组件（如ProductCard）
hooks/ # 模块逻辑（如useProductList）
types/ # 类型定义
pages/ # 商品模块页面
stores/ # 商品全局状态
index.ts # 统一出口
order/ # 订单模块
components/ # 模块专属组件（如OrderList）
hooks/ # 模块逻辑（如useOrderList）
types/ # 类型定义
pages/ # 订单页面
stores/ # 订单全局状态
index.ts # 统一出口
shared/ # 跨模块共享业务组件
components/ # 业务组件
utils/ # 工具函数
复杂项目中，模块之间会存在比较多的交互，频繁的提升业务组件，造成模块中功能逻辑太过于分散。
可以在对应模块下增加 index.ts 统一出口，将模块组件提供给其他模块使用。
