古法编程秘籍（二）：什么是代码模块化？别背概念，把房间收拾明白就够了

Hi!这里是 JustHappy 这是专为编程初学者准备的专栏，哈哈，AI 时代更需要我们返璞归真！我们继续秘籍修炼之旅吧，这期我们来聊模块化

Hi！上一篇我们聊了面向对象。

对象这玩意说白了就一件事：把相关的东西打包在一起（属性 + 行为），别让它们散落一地。

那模块化也差不多，只不过它管的是"代码收纳"。

对象解决的是：一类东西怎么组织。

模块化解决的是：一堆代码怎么组织。

先把场景摆出来：为什么你会需要模块化？

我敢打赌，大部分人刚开始写项目的时候，都做过一件很"爽"的事：所有东西写在一个文件里。

登录写这里，用户信息写这里，商品列表写这里，支付也写这里，工具函数顺手也扔这里......主打一个：能跑就行。

代码少的时候确实没问题。

代码一多，马上就开始难受了：找东西找不到，改东西改不动，不敢删，硬改还容易炸。

所以模块化到底是啥？

别把它想得很玄。

它就是：分类收纳。

房间里衣服进衣柜，书进书架，充电器进抽屉；代码里也是一样，谁的东西谁自己管，别混着放。

模块是什么？你可以把它当成"一个抽屉"

模块就是一块相对独立的代码，负责一件明确的事。

比如你做一个小项目，通常会自然长成这种结构（不是强制，只是很常见）：

项目里有一块专门放"用户相关"的区域，有一块专门放"订单相关"的区域，还有一块专门处理"请求/公共工具"的区域。

你不需要一上来就把目录拆得花里胡哨，先把"同一类事情"放一起就行。

举个最小的例子：用户模块就干用户的事，它对外只提供"你能用的能力"。

js 复制代码

// services/user.js
export async function login(username, password) {
  // 这里假装请求接口：真实项目里就是 fetch/axios
  return { token: 'mock-token', username }
}

然后页面/入口文件只管"用"，不关心你里面怎么实现：

js 复制代码

// main.js
import { login } from './services/user.js'

login('zhangsan', '123456').then((res) => {
  console.log('login ok:', res)
})

你看，这时候模块化的味道就出来了：我只知道你能 login，你内部怎么折腾我不管。

模块化 ≠ 文件越多越高级

很多人一听模块化，就开始疯狂建文件：a.js、b.js、c.js......

结果每个文件都写一点点：用户逻辑一段、订单逻辑一段、工具函数也夹带私货一段。

这不叫模块化。

这叫：把垃圾从一个大袋子，分装到几个小袋子里------看起来分开了，其实更难找。

真正的模块化，核心只有四个字：职责清楚。

你可以粗暴一点理解成：

用户相关的，尽量都在 user 这一坨
订单相关的，尽量都在 order 这一坨
全局通用的（请求、日期、格式化），放公共模块

只要你做到了"别混放"，就已经赢了很多人。

模块之间怎么配合？关键是"只开一个口"

模块不是孤岛，它们一定会互相调用。

但互相调用也得讲规矩：内部怎么做你自己管，对外怎么用你说清楚。

比如请求模块，这是最典型的"我来背锅，你们别管细节"的模块。

你希望全项目请求都走它，因为你迟早要做这些事：统一加 token、统一错误处理、统一返回结构、统一埋点......

js 复制代码

// request/request.js
export async function request(url, options = {}) {
  const headers = {
    'Content-Type': 'application/json',
    ...(options.headers || {})
  }

  // 真实项目里你会在这里：加 token、统一错误处理、统一返回结构等
  const res = await fetch(url, { ...options, headers })
  if (!res.ok) throw new Error(`HTTP ${res.status}`)
  return res.json()
}

然后你再给它做一个"门面"（很多项目喜欢用 index 来当总出口）：

js 复制代码

// request/index.js
export { request } from './request.js'

业务模块用的时候就很干净：

js 复制代码

// services/user.js
import { request } from '../request/index.js'

export function getUserInfo() {
  return request('/api/user', { method: 'GET' })
}

你注意看：业务模块只负责"这是谁的接口、怎么调用"，至于"请求的脏活累活"，全部塞进 request 模块里。

这就是好的模块化：把复杂留给自己，把简单留给别人。

顺带一提：老项目里你可能看到的是 CommonJS

如果你在 Node 的一些老项目里，会看到另一套写法（CommonJS）。逻辑其实一样，只是语法不一样：

js 复制代码

// utils/math.cjs
function add(a, b) {
  return a + b
}

module.exports = { add }

用的时候是 require：

js 复制代码

// main.cjs
const { add } = require('./utils/math.cjs')
console.log(add(1, 2))

别被语法骗了：本质还是"我把能力放到一个地方，然后别人通过入口来用"。

最后总结一句：模块化到底解决了啥？

真实项目的日常是：功能不停加、需求不停改、bug 不停修、多人一起维护。

你要是没有模块化，代码迟早会乱成一团毛线：你改登录，支付挂了；你删个函数，首页白屏；你加个功能，不知道往哪写。

模块化最实际的价值就三句话：

让代码有位置，让功能有边界，让修改有范围。

说得更直白点：模块化不是为了写代码时爽，是为了以后改代码时不崩溃。