别让代码变成“意大利面”：JS 模块化拆分的几条救命原则

接手过一个老项目，打开主逻辑文件一看，整整两千行代码塞在一起。修一个 bug 像开盲盒，动了一行，另一处突然报错。这种“巨型函数”带来的痛苦，几乎每个前端都体验过。模块化拆分不是为了赶时髦，而是为了以后还能看得懂自己写的代码。

很多新人觉得拆分就是随便建几个文件夹，把文件塞进去就算完事。其实真正的难点在于划分边界。如果边界模糊，模块之间就会藕断丝连，最后又变回一锅粥。

真正有效的拆分，核心在于高内聚。简单来说，就是把“亲兄弟”放在一个包里，把“远房亲戚”隔离开。比如处理用户数据的逻辑，别跟 UI 渲染混在一起；API 请求的封装，也别直接写死在业务组件里。当你在某个文件中发现一段逻辑既不属于数据层，也不属于视图层时，通常就是你该动手拆分的时候了。按功能聚合而非按类型分组，是现代前端更推荐的做法。比起传统的把 JS、CSS、图片全分开，不如把关于“订单”的所有东西（样式、逻辑、状态）都集中在 Order 模块下。这样当你需要修改订单流程时，不用在全项目里跳转搜索。

不过，拆分也不是越细越好。见过有人为了追求极致规范，把一个简单的工具函数拆成三个文件，结果引入依赖比执行代码还长。这种过度设计会严重拖累开发效率。粒度要适中，判断标准很简单：这个模块能否独立测试？如果拿掉上下文它就没法跑，说明它还不够独立；如果拆开后发现它啥也干不了，那它就是拆过头了。

还有一个隐形杀手叫循环依赖。A 模块引用 B，B 模块又回头引用 A。这在小型脚本里可能靠运气能跑通，到了大型项目中，构建工具往往会直接报错，或者出现莫名其妙的初始化问题。解决这个问题的根本办法是提取公共依赖，把两者共用的部分抽离出来变成一个独立的第三方模块，切断直接的互相调用链路。

最后得提个醒，不要为了拆分而拆分。如果一个脚本只在一个页面用一次，且逻辑非常简单，把它强行拆进复杂的架构体系里，反而是给维护者添乱。重构的前提是先让代码跑起来，再逐步优化结构。

代码是写给人看的，顺便给机器运行。好的模块化能让未来的你感谢现在的决定。试着从下一个小需求开始，有意识地规划边界，哪怕只是把一个大函数拆成两个职责单一的小函数，也是一种进步。随着时间推移，你会发现项目的可维护性有了肉眼可见的提升。