vue3项目初始化后应立即按业务域重构目录结构，推荐采用src/features/组织各模块（如auth、dashboard），每个模块内聚页面、组件、api和类型，并将真正通用的代码提至shared/层，基础设施放入core/。
Vue 3 项目初始化后，别急着写业务逻辑。先花15分钟重构目录结构——这比后期花三天重构要高效得多。核心原则就一条：让文件位置直接表达它的职责和变化频率。
删掉默认结构里“看似合理实则模糊”的目录
初始化生成的 `src/components` 和 `src/views` 是起点，不是终点。它们容易快速变成“组件垃圾场”和“页面大杂烩”。建议第一步就移除这种纯技术类型划分，转而按业务域组织。 - 删除空的 `components/`（保留但清空内容，后续按需重建） - 不再新建 `pages/` 或 `screens/` 这类同义词目录，统一用 `views/` 表示路由级页面 - 暂时不用 `utils/`、`helpers/`、`common/` 等泛化目录，避免过早抽象重点不是“删文件夹”，而是停止用模糊分类掩盖业务逻辑。比如一个登录功能，不该分散在 `components/LoginForm.vue` + `api/login.ts` + `views/Login.vue` 三个孤立位置，而应聚合成一个可识别的单元。
按业务模块建一级目录，每个模块自包含
推荐从 `src/features/` 开始组织，每个子目录代表一个独立业务能力，例如：-
src/features/auth/ -
src/features/dashboard/ -
src/features/product/ src/features/order/
每个模块内部保持最小完备结构：
-
index.vue—— 路由入口页面（对应router中的component: () => import('@/features/auth/index.vue')） -
components/—— 仅本模块使用的组件（如LoginForm.vue,AuthCard.vue） -
api/—— 封装本模块所有请求（如useLogin.ts,useLogout.ts） -
types.ts—— 本模块专属类型定义 -
hooks/（可选）—— 组合式函数，只服务当前模块逻辑
这样改一个订单状态，你只需打开 `features/order/`，所有相关代码一目了然，不会误动用户或商品模块的逻辑。
把真正通用的东西抽到顶层共享层
哪些东西值得提出来？判断标准很朴素：**是否被3个以上业务模块直接引用，且不随任一模块变更而改变**。符合的才放进 `shared/`：-
shared/components/：Button、Modal、Icon、EmptyState 等无业务语义的基础组件 -
shared/assets/：全局图标字体、主题色变量 SCSS、基础动画 CSS 类 -
shared/composables/：useLoading、useToast、useCopyText等跨业务工具型 Hook -
shared/types/：ApiResponse<t></t>、Pagination等通用接口类型
注意：不要放 `useUserStore` 或 `useProductList` 这类带业务名的 Hook——它们属于 `features/` 层，不是共享层。
基础设施目录要稳定、边界清晰
这些目录生命周期长、改动少，必须语义明确、不容混淆：core/：项目运行必需的底层能力
-core/plugins/：注册全局插件（如权限指令、国际化）
-core/directives/：v-permission、v-loading等自定义指令
-core/utils/：纯函数、无副作用（formatDate、debounce），禁止含 API 调用或状态操作assets/：只放需要构建处理的资源（压缩图、SCSS、字体文件）public/：只放不参与构建的静态资源（favicon.ico、robots.txt、CDN JS）
常见错误是把 axios 实例放在 `assets/` 或 `utils/` 里——它属于 `core/` 或 `shared/`，因为它是整个请求链路的起点，不是“静态资源”也不是“随便用的工具”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
