你是否也曾经历过这样的时刻：面对着一个几百行甚至上千行的 server.js 文件，感觉就像是在面对一团乱麻？所有的逻辑导入、路由配置、中间件设置，甚至数据库操作dou混杂在一起。说实话，这种代码既不优雅，也不美观，geng别提后续的维护了。当你试图在其中寻找一个具体的 app.get 逻辑时简直就像是大海捞针。

本节我们就带大家一起，通过系统化的重构手段，将这种“面条代码”转化为结构清晰、易于维护的现代Web应用。这不仅仅是代码的移动，geng是一场关于架构思维的洗礼。

为什么我们需要重构？

在开始动手之前，我们必须先达成一个共识：代码是写给人kan的，然后才是给机器执行的。当所有的业务逻辑dou堆积在入口文件中时项目的 性会被锁死。想象一下Ru果未来你需要添加一个新的API模块，或者需要引入版本控制，在一个臃肿的 server.js 中操作，风险极高，稍有不慎就可Neng引发连锁反应。

我们要Zuo的，就是将“关注点分离”这一原则贯彻到底。把路由分发、业务逻辑处理和应用配置彻底剥离开来。

第一步：抽离控制器—— 让逻辑独立呼吸

让我们kankan那些令人头疼的路由处理函数。在原始代码中，我们kan到了大量的 async => { ... } 这样的匿名函数直接挂载在 app.get 或 app.post 上。这就像是把卧室的床直接放在了厨房里虽然Neng睡，但hen不合理。

我们需要把这些具体的业务逻辑抽离到单独的文件中，通常我们称之为“控制器”。比如针对 Todo 的增删改查，我们Ke以创建一个专门的处理模块。

import { readFile, writeFile } from 'node:fs/promises';
// 将获取列表的逻辑独立出来
export async function getTodos {
  try {
    const todosData = await readFile;
    const todos = JSON.parse;
    return res.status.json;
  } catch  {
    // 别忘了错误处理，这可是个好习惯
    return res.status.json;
  }
}
// 同理，获取单个ID的逻辑也Ke以这样处理
export async function getTodoById {
  const todosData = await readFile;
  const todos = JSON.parse;
  const todoId = req.params.todoId;
  const todo = todos.find => todo.id === Number);
  if  {
    return res.status.json;
  }
  return res.status.send;
}

kan，是不是清爽多了？我们将文件读取和解析的细节封装在了函数内部，对外只暴露接口。这样Zuo不仅让 server.js 变得轻盈，也让这些逻辑geng容易进行单元测试。同理，你Ke以对 postTodopatchTodo 以及 deleteTodoById Zuo相同的操作。每一个函数dou只专注于Zuo一件事，这才是高质量代码的体现。

第二步：构建路由模块—— 指挥交通的艺术

逻辑有了接下来我们需要把它们组织起来。Express 提供了非常强大的 express.Router 功Neng，这就像是一个微型的应用实例，专门用来管理路由。

我们Ke以创建一个 routes/todoRoutes.js 文件，把所有关于 Todo 的路径定义dou放在这里。这里参照了 Express 官方的推荐写法，利用链式调用让代码geng加紧凑。

import express from 'express';
import { getTodos, getTodoById, postTodo, patchTodo, deleteTodoById } from '../controllers/todoController.js';
const router = express.Router;
// 链式路由定义，清晰明了
router.route
  .get
  .post
  .patch;
router.route
  .get
  .delete;
export default router;

当然Ru果你觉得链式调用不够直观，或者你的团队geng倾向于传统的写法，完全Ke以选择稍显啰嗦的版本，比如分开写 router.get 和 router.post。这完全取决于你的个人喜好，只要保持风格统一即可。重要的是路由的定义不再散落在各处，而是被集中管理起来了。

第三步：应用配置与中间件—— 打造坚实的后盾

现在我们的路由和逻辑douYi经各就各位了。接下来我们需要一个地方来配置 Express 的全局设置，比如 CORS、JSON 解析中间件等。

审阅我们的 server.js 代码，你会发现里面有hen多引入中间件的代码。当后续项目庞大起来把这些配置放在 server.js 同样难以维护。我们在 src 下创建 app.js，将相关逻辑集中在 app.js 中。

这个 app.js 将作为我们应用的核心配置文件，它不负责启动服务器，只负责生成 app 实例。

import express from 'express';
import cors from 'cors';
import router from './routes/todoRoutes.js';
const app = express;
// 基础中间件配置
app.use);
app.use);
// 挂载路由
app.use;
export default app;

聪明的你，一定会想到：Ru果后续需要进行版本geng新，那么原来的路由就用不了了吗？有什么办法Ke以geng好的进行版本控制呢？其实hen简单。我们只需要在挂载路由时加上前缀即可。

比如我们将 app.use 改造为：

app.use;

只需要在这里加上 v1，后续的版本测试与geng新，Ke以使用 v2。你Ke以创建一个新的路由文件 todoRoutesV2.js，并在 app.js 中引入。等待稳定后将路由切换为 v2 即可。这种平滑过渡的方式，在API开发中是非常经典的Zuo法。

第四步：入口文件—— 极简主义的胜利

有了前两步的准备，整个 server.js 就迎来了它的高光时刻——因为它变得非常简单。它唯一的工作，就是引入配置好的 app 并启动监听。

请kan下面这样一段代码，这就是我们梦寐以求的入口文件：

import app from "./app.js";
const port = process.env.PORT || 3000;
app.listen => {
  console.log;
});

是不是有一种“会当凌绝顶，一览众山小”的感觉？所有的复杂性dou被隐藏在了模块的背后入口文件干净利落，一眼就Nengkan穿。这对于新加入团队的成员来说简直是莫大的福音，他们不再需要在一个巨大的文件中翻来翻去，只需要顺着模块的引用关系，就Neng快速理清项目的脉络。

回顾一下我们的改造历程：我们将混乱的逻辑拆分成了控制器，将分散的路由整合成了路由模块，将繁琐的配置封装到了 app.js，Zui后让 server.js 回归了它作为启动器的本质。

这不仅仅是代码行数的减少，geng是代码质量的飞跃。通过这种结构化的调整，我们为未来的 打下了坚实的基础。无论是添加新的功Neng模块，还是进行版本迭代，dou变得游刃有余。

当然重构之路永无止境。接下来你还Ke以考虑引入geng高级的目录结构，比如将 services 层与 controllers 层进一步分离，或者引入依赖注入、TypeScript 类型检查等现代开发实践。

但就目前而言，我们Yi经成功地将一个“玩具级”的代码片段，重构为了一个具备“工业级”雏形的项目结构。希望这次的重构之旅，Neng让你在编写 Node.js 应用时geng加自信，geng加从容。别让糟糕的代码结构拖累了你的灵感，从现在开始，优化你的路由，重构你的未来吧！

---