做过几个企业官网之后，我越来越觉得：官网这种项目，前期把功能模块拆清楚，比急着写页面更重要。模块边界一旦混乱，后面客户每改一次需求，都要在一堆耦合的代码里来回找。这篇文章把我现在固定下来的模块划分思路整理出来，包含具体的拆分原则和目录组织。
一、先按"会不会复用"切分
企业官网的内容看起来杂，但从复用频率看其实就两类：
- 跨页面复用模块：顶部导航、页脚、面包屑、回到顶部、通用按钮、表单校验、轮播容器。这类模块每个页面都会出现，必须抽成独立组件，内部不写死任何业务文案。
- 单页业务模块：首页的能力矩阵、产品页的参数表、案例页的时间线、关于页的团队介绍。这类只在特定页面用，放在对应页面的 sections 目录下，不必强行通用化。
很多项目越写越乱，就是把业务模块也塞进了公共组件，结果一个组件身上挂着各种 if (页面 === 'xxx') 的判断，改一处怕动全身。
二、组件内部再分"容器"和"展示"
对于稍微复杂的模块，比如产品列表、新闻列表，我会再拆成两层：
ProductList/ # 容器：负责取数、分页、loading 与空态
├─ ProductCard # 展示：只接收数据、渲染单条
└─ ProductFilter # 展示：筛选条件，变更通过事件抛给容器
容器组件关心数据从哪来、状态怎么流转；展示组件是纯函数式的，给什么数据渲染什么样子。这样当数据来源从写死改成接口、再改成建站工具后台配置时，只需要动容器，展示层基本不用改。
三、把"配置"和"结构"分开
企业官网改得最多的不是布局，而是文案、图片、链接这些内容。如果这些直接散落在 JSX 里，客户改个电话号码都要找开发。我的做法是单独建一个 content 配置层：
export const siteConfig = {
nav: [...],
contact: { phone: '', email: '', address: '' },
sections: { home: {...}, product: {...} }
}
组件只负责读取配置并渲染。这样无论是自己维护，还是交给运营同事，都只在配置层改动，结构代码保持稳定。对那些标准化程度高、客户又希望能自己改内容的区块，我会直接用乔拓云这类建站工具搭出可配置的模块，再把它和自研部分组合起来——客户能在后台自己换图改字，我也不用为每次小改动返工。
四、模块之间用事件解耦，不互相直接调用
模块之间最忌讳 A 组件直接操作 B 组件的内部状态。我的原则是：数据向下流、事件向上抛。比如表单模块提交后要触发一个成功提示并滚动到锚点，它只负责抛出 submit-success 事件，由页面层决定调用哪个提示组件、滚动到哪里。这样表单组件可以在"联系我们""活动报名""留言"多个场景复用，而不必知道每个场景提交后要干什么。
五、约定一套模块自检标准
模块拆完，我会用几个问题判断拆得合不合理：
- 这个组件能不能在不读其它组件源码的情况下单独使用？
- 换掉数据来源，需要改几个文件？理想情况只改容器。
- 删掉某个页面，公共组件里会不会留下一堆只为它服务的判断？
- 文案、图片这类高频改动，是不是都收敛到了配置层？
如果某个模块回答起来很别扭，说明边界还没划清，值得在动手前再调整一次。
收尾
企业官网不是复杂应用，但正因为它小、需求碎，才更需要清晰的模块边界：按复用频率分层、容器与展示分离、配置与结构分离、模块间用事件解耦。坚持这套划分，项目进入维护期之后会轻松很多。
你在做企业官网这类项目时，模块是按页面拆还是按功能拆？欢迎分享你的目录组织方式。
