设想一个后台程序要给订单列表增加退款状态筛选。

需求本身不复杂，给页面多一个下拉框。接下来请求参数增加 refundStatus接口结果里能够展示退款状态，查询条件也可以保存到页面状态中，那任务就算完成了。

痛点：开发者打开项目后实际要修改的文件分散在不同顶层目录，导致频繁跳转耗时。

原始文件分布

举个例子。开发者打开项目后实际要修改的文件分散在这些位置：

src/
├─ api/order.ts
├─ views/order/OrderList.vue
├─ components/order/OrderFilter.vue
├─ hooks/useOrderTable.ts
├─ stores/order.ts
└─ types/order.ts

六个文件不算多，麻烦在于它们分布在六套顶层目录中。者先从页面跳到 /api再去 /hooks 找请求参数。接着到 /types 补类型，最终还要确认 /stores 中有没有保存筛选条件。

改动后的 Git 状态

改动完成后git diff --stat 看起来像这样：

src/api/order.ts | +++-
src/components/order/OrderFilter.vue | +++++++++
src/hooks/useOrderTable.ts | ++++
src/stores/order.ts | +++
src/types/order.ts | +++++
src/views/order/OrderList.vue | +++++-
files changed

小项目按技术类型分类的局限性

当我们开始初始化项目的时候，一般都会采用这样的目录结构：

src/
├─ api/
├─ assets/
├─ components/
├─ hooks/
├─ router/
├─ stores/
├─ types/
├─ utils/
└─ views/

痛点：
文件内容	放置目录
请求函数	api/
页面组件	views/
可复用组件	components/
组合函数	hooks/
状态管理	stores/
`types`

如果想修改路由就进入 router 目录；想找接口就进入 api 目录；公共组件集中放在 components 下面。但因为业务模块增多，每个顶层目录内部又会出现业务分类。例如 order、user、product 等，这样就出现了两层分类：技术类型 → 业务模块。一次功能需求往往横跨多个顶层目录，造成开发链路变得极其复杂。这不仅让人摸不清一次功能到底在哪一行，还导致重命名或删除业务模块时容易遗漏相关文件。 当团队规模扩大、维护人员增多时这种“跨域”会慢慢变成主要瓶颈。

• - 难以快速定位功能边界
• - 删除业务模块时可能留下无用代码
• - 同步更新方法成本高

  判断是否需要调整目录结构的方法

---