前端项目结构：按业务组织，而不是按文件类型堆放

项目刚开始时，把所有组件放在 components、所有接口放在 api 看起来很整齐。但随着业务增长，一次功能修改可能需要在多个大目录之间来回寻找文件。

让相关代码待在一起#

订单功能的页面、组件、请求和类型可以放在同一个业务目录中。公共目录只保留真正被多个业务使用的内容。

src/
  features/
    order/
      api.ts
      types.ts
      OrderList.tsx
      OrderEditor.tsx
  shared/
    components/
    utils/

这种结构让开发者进入 order 目录后就能看到功能的主要组成，也更容易判断修改范围。

公共模块要谨慎#

两个文件长得相似，不代表它们属于同一个抽象。只有当它们表达相同业务概念，并且会因为同一种原因变化时，才适合合并。

过早放入 shared 的模块容易变成所有业务都依赖的中心，最后任何修改都需要兼容大量场景。先允许少量重复，等稳定模式出现后再抽取，通常更安全。

约束依赖方向#

业务模块可以依赖公共模块，但公共模块不应该反过来依赖具体业务。不同业务之间也尽量通过清晰接口协作，避免直接访问对方的内部文件。

好的目录结构不是追求统一模板，而是让开发者能快速回答：代码在哪里、它属于谁、修改会影响什么。