web项目目录结构

前阵子接手一个外包项目，目目对方把压缩包发过来，录结解压后我盯着屏幕愣了三秒——所有文件平铺在根目录，目目连个`css`文件夹都没建。录结那个下午我花了四十分钟把三百多个文件按类型归位，目目一边拖拽一边骂娘。录结这不是目目矫情，混乱的录结目录结构会让开发效率直接腰斩，后期维护更是目目噩梦。

一个正经的录结web项目，目录结构通常遵循“按功能分层，目目按模块分区”的录结原则。拿最典型的目目Vue或React项目举例，根目录下必然有`src`、录结`public`、目目`config`、`node_modules`这几个大块头。`src`是主战场，所有源码都在这。里面再拆成`components`（通用组件）、`views`或`pages`（页面级组件）、`router`（路由配置）、`store`或`state`（全局状态管理）、`utils`（工具函数）、`api`（接口请求封装）、`assets`（静态资源如图片、字体）。这套结构不是拍脑袋定的，它对应的是开发时的心理模型——改页面去views，调接口去api，抽公共组件去components，找工具函数去utils。每个目录职责单一，新同事接手时不用翻遍全项目才能定位一个bug。

但别以为目录越细越好。见过一个团队把`components`又拆出十几个子目录，按按钮、输入框、弹窗、表格、布局、反馈、导航……分类是清晰了，可一个简单的下拉选择器，你得点开四层文件夹才能看到代码。这种过度设计反而拖慢节奏。合理的颗粒度应该是：通用性强的、可能被多个页面复用的组件放`components`；只有某个页面用的局部组件，直接放在该页面自己的目录下，比如`views/order/detail/OrderDetailCard.vue`。这样既避免臃肿，又保持内聚。

再聊聊`public`和`assets`的区别。很多人搞混。`public`目录下的文件会原封不动地拷贝到打包后的根目录，适合放`favicon.ico`、`robots.txt`、外部引用的静态HTML这类不需要构建处理的资源。而`assets`里的文件会经过webpack处理，能被压缩、指纹化、按需加载。判断标准很简单：这个文件需不需要被代码引用？需要就放`assets`，不需要就放`public`。比如网站logo，如果在组件里`import`使用，放`assets`；如果直接写死在`index.html`的``标签里，放`public`。

有个细节容易忽略——`config`或`build`目录。很多人图省事把所有配置都堆在根目录的`package.json`和`vue.config.js`里，结果文件越来越长，最后变成一团乱麻。我习惯把开发环境、测试环境、生产环境的API地址、开关配置拆成独立文件，放到`config`下，比如`config/dev.env.js`、`config/prod.env.js`。这样上线时改配置不会动到业务代码，出问题也好排查。

还要提一嘴`node_modules`——这目录不是给你看的，但它的存在本身就是提醒：依赖管理要规范。别再手动往里面塞包了，所有依赖必须写进`package.json`，锁版本用`package-lock.json`或`yarn.lock`。上周同事的机器上跑不起来项目，最后发现是他本地`node_modules`里有个包被手动改过，而`package.json`里根本没记录。这种坑，纯属自找。

目录结构这东西，没有放之四海皆准的模板。小项目几行代码就能搞定，没必要硬套大厂的分层架构；大项目也别贪图省事全堆一起。核心原则就一条：让读代码的人能最快找到他需要的东西。你下次建项目时，先花十分钟想清楚这个项目会有哪些页面、哪些通用模块、哪些接口，再动手建目录。比写代码本身更重要的，是让代码有个好归宿。