为什么需要多目录？从混乱到有序的必经之路

说实话，我刚开始写代码那会儿，根本不在乎目录结构。一个项目，所有文件往 src 里一扔，完事。直到有一次，一个中型项目让我彻底崩溃——找配置文件花了半小时，测试代码和生产代码混在一起，文档散落在各个角落。嗯，那次之后，我老老实实开始研究多目录设计。

你可能会问：不就是个文件夹吗，至于这么讲究？我告诉你，至于。一个清晰的项目结构，就像一间整洁的厨房。你想炒菜，锅在哪、调料在哪、配菜在哪，一目了然。反之，你懂的。

单体项目 vs 模块化项目

先聊聊单体项目。说白了，就是所有代码堆在一个大仓库里。小项目还行，一旦规模上来，问题就来了：

耦合严重——改一行代码，可能牵动整个项目
构建缓慢——每次编译都要处理全部代码
团队协作困难——多人同时改同一个模块，冲突不断

我记得有个项目，团队从3人扩张到15人，单体结构直接成了瓶颈。每次合并代码，光解决冲突就要半天。后来我们拆成了模块化项目，每个模块独立目录、独立构建、独立测试。效果立竿见影。

模块化项目的好处很明显：

职责清晰——每个目录只做一件事
独立演进——模块之间通过接口通信，互不干扰
复用性强——公共模块可以轻松被其他项目引用

核心观点：多目录不是花架子，它是应对复杂度的第一道防线。项目越大，目录结构越重要。

经典目录结构剖析

一个成熟的项目，通常包含以下几个核心目录。我一个个说，你感受一下。

src —— 源码的核心

这是你的主战场。所有业务代码、逻辑实现都放在这里。我个人习惯按功能模块再细分，比如 src/user、src/order、src/payment。这样找代码快，新人上手也快。

src/
├── user/
│   ├── UserController.js
│   ├── UserService.js
│   └── UserModel.js
├── order/
│   ├── OrderController.js
│   ├── OrderService.js
│   └── OrderModel.js
└── payment/
    ├── PaymentController.js
    ├── PaymentService.js
    └── PaymentModel.js

小技巧：src 里不要放配置文件、不要放测试代码、不要放文档。保持纯净，只放生产代码。

lib —— 公共库与工具

有些代码，多个模块都会用到。比如日志工具、日期格式化、加密函数。这些放哪？放 lib。它就像你的工具箱，随时取用。

我曾经犯过一个错误：把工具函数散落在各个模块里，结果同一个功能写了三遍。后来统一放到 lib，清爽多了。

lib/
├── logger.js
├── dateUtils.js
├── cryptoHelper.js
└── httpClient.js

tests —— 测试的根据地

测试代码和生产代码分开，这是基本素养。为什么？因为测试代码不需要部署到生产环境。你想想看，如果把测试代码混在 src 里，打包时还得费劲排除，多麻烦。

我建议 tests 目录的结构和 src 保持一致。这样找测试文件就像照镜子，省心。

tests/
├── unit/
│   ├── user.test.js
│   └── order.test.js
├── integration/
│   └── api.test.js
└── e2e/
    └── fullFlow.test.js

docs —— 文档的归宿

文档这东西，没人爱写，但没人能缺。我见过最惨的情况：项目交接时，文档找不到，代码又没注释，新人直接崩溃。

docs 目录可以放：

API 文档
架构设计文档
部署手册
变更日志

注意：文档要跟代码一起维护。代码改了，文档也得更新。我曾经因为文档没更新，导致新同事按旧文档部署，出了线上事故。血的教训。

scripts —— 自动化脚本

构建、部署、数据迁移、代码检查……这些重复性工作，写成脚本放到 scripts 目录。我习惯用 shell 脚本或 Python 脚本，简单直接。

scripts/
├── build.sh
├── deploy.sh
├── migrate.sh
└── lint.sh

config —— 配置的中心

数据库连接、API 密钥、环境变量……这些配置信息，统一放到 config 目录。不同环境（开发、测试、生产）可以有不同的配置文件。

config/
├── development.json
├── testing.json
├── production.json
└── default.json

建议：敏感信息（如密码、密钥）不要硬编码在配置文件里。用环境变量或密钥管理服务。安全第一。

一张图看懂整体结构

下面这张图，展示了经典多目录结构的全貌。你可以把它当作模板，直接套用。

总结一下

多目录结构，说白了就是「分而治之」。把大问题拆成小问题，每个小问题放在对应的目录里。这样做的好处：

好找——想找什么，直奔对应目录
好改——改一个模块，不影响其他模块
好测——测试代码和生产代码分离，清晰明了
好部署——只打包需要的代码，减少体积

我见过太多项目，一开始图省事，所有文件堆在一起。等到项目膨胀到一定程度，重构成本高得吓人。所以，从一开始就规划好目录结构，这是最划算的投资。

一句话记住：目录结构不是写给别人看的，是写给自己未来的。你现在的规划，决定了你三个月后的心情。

📚 课程目录

为什么需要多目录？从混乱到有序的必经之路

单体项目 vs 模块化项目

经典目录结构剖析

src —— 源码的核心

lib —— 公共库与工具

tests —— 测试的根据地

docs —— 文档的归宿

scripts —— 自动化脚本

config —— 配置的中心

一张图看懂整体结构

总结一下