Vue.js组件化架构需按功能模块组织代码，每个模块内聚视图、业务组件、API和服务状态，分层明确职责，组件高内聚低耦合，路径引用遵循就近相对与公共绝对原则。
Vue.js 组件化架构的项目结构规划，本质是用清晰的职责边界支撑可维护性与协作效率。它不是堆砌目录，而是围绕“谁负责什么、怎么复用、如何隔离”来组织代码。
按功能模块组织视图与业务逻辑
页面级功能（如用户管理、订单中心、监控看板）应各自形成闭环模块。每个模块内聚视图组件（views/xxx/）、专属业务组件（components/xxx/）、API 封装（services/xxx.js）和状态逻辑（stores/xxx-module.js）。比如 src/views/orders/ 下放 OrderList.vue 和 OrderDetail.vue，同级 src/components/orders/ 放 OrderStatusBadge.vue 和 OrderActionToolbar.vue，避免跨模块引用混乱。
- 路由配置中直接指向模块内视图，如
{ path: '/orders', component: () => import('@/views/orders/OrderList.vue') } - 模块间通信通过事件总线或状态管理，不直接 import 对方组件
- 模块入口统一暴露
index.js，对外只提供 API 方法和主组件，隐藏内部实现细节
分层划分：明确视图、逻辑与数据职责
在模块内部或全局层面，按关注点分离原则分层。视图层（views 和 components）只处理渲染与用户交互；逻辑层（composables 或 hooks）封装可复用的业务流程，如“加载订单列表+分页+错误重试”；数据层（services 和 stores）专注请求、缓存与状态同步。三层之间单向依赖：视图 → 逻辑 → 数据，不反向穿透。
- 组合式 API 中，
useOrderList()封装获取、刷新、加载更多等逻辑，供多个组件调用 -
services/order-api.js只做 axios 请求封装，不包含 UI 相关判断 -
stores/order-store.js使用 Pinia 定义 state、actions 和 getters，不操作 DOM
组件设计遵循高内聚、低耦合原则
组件是否可复用，取决于它是否具备明确契约和最小依赖。原子组件（按钮、输入框）无业务语义；分子组件（搜索栏、筛选面板）封装一组交互；页面组件（DashboardView）负责布局与协调，不处理具体业务规则。所有组件通过 props / emits / slots 明确定义接口，避免使用 this.$parent 或 ref 强耦合。
立即学习“前端免费学习笔记（深入）”；
- 表单类组件接收
modelValue和触发update:modelValue，兼容 v-model - 列表组件通过
slot允许自定义项模板，而非硬编码渲染逻辑 - 带状态的组件（如带加载态的按钮）把 loading 状态作为 prop 暴露，由父组件控制
路径引用坚持“就近相对 + 公共绝对”策略
模块内部文件相互引用用相对路径（./utils.js），确保模块可整体迁移；跨模块复用的通用资源（如 components/Button.vue、utils/request.js）统一从根目录以别名引入（import Button from '@/components/Button.vue'）。这样既保障模块独立性，又避免路径错乱导致的构建失败。
- 在
vue.config.js或vite.config.js中配置@别名指向src/ - 移动一个功能模块文件夹时，内部所有相对路径自动生效，无需逐个修改
- 全局工具函数、基础样式、API 实例等，全部归入
src/下对应目录，不散落各处
