Feature-based 架构：为什么你的 components 文件夹变成了一团乱麻
来源：dev.to — 2026-08-22
📋 概述
作者从自身项目经历出发，讲前端项目按"类型"组织（Type-based，所有 components/hooks/api 各自一个文件夹）随着功能增加而变得混乱、难以定位的问题，进而引入 Feature-based 架构：按业务实体或领域把项目切成相互解耦、自管理的模块，每个 feature 内部再包含自己的 components/hooks/api/types，公共部分放 shared。优点是组织清晰、可测试性提升、可扩展性好。作者也诚实讨论了 trade-off：比如某新实体最初只有一次简单 API 调用时，也许先放进现有 feature 更合适，等它长大再拆成独立 feature，需要成熟度判断。
🔑 核心要点
- 按类型组织（Type-based）的项目在功能变多后会纠缠、失序、难定位。
- Feature-based：按实体或领域拆分模块，每个 feature 自带 components/hooks/api/types。
- 优点：组织清晰、测试用例更好定位、新增功能只改对应 feature。
- trade-off：新实体初期调用很简单时，可先并入现有 feature，长大后再独立，需判断成熟度。
- 在 AI 大量参与开发的当下，清晰结构能防止 agent 悄悄重复逻辑。
💡 金句
没有清晰的结构，AI 很容易在你没察觉时重复逻辑，而你因为"看起来一切正常"就接受了它。
👍 0
👎 0
← 返回 dev.to 首页