后端开发入门

是什么，为什么存在

后端（backend）是运行在用户设备之外、代表应用处理请求和状态的代码。对于 HTTP 服务，它接收方法、目标 URI、请求头和可选消息体，执行规则后返回状态码、响应头和可选消息体。部署位置可能是一台服务器、多个进程或无服务器运行时；「后端」描述职责，不限定机器形态。

客户端不应该直接拥有所有业务状态或数据库权限。价格计算、资源授权和库存扣减等规则需要一个受控边界，所有客户端都通过它得到一致结果。后端还负责把短暂的网络请求连接到寿命更长的持久数据。

对客户端而言，后端首先是一份 API 契约（API contract） 。契约不只有 JSON 字段，还包括方法语义、路径、输入限制、认证要求、状态码、相关响应头以及重试后的行为。客户端依赖的是这些可观察结果，不是服务内部用了哪种框架或数据库。

你会在网页提交表单、移动应用同步数据、命令行工具查询状态或另一个服务调用接口时遇到后端。一次交互通常跨过不可靠网络，因此超时、连接中断和重复请求是正常情况，不是边缘事故。

后端真正负责的工作

一个小型 HTTP 后端通常需要承担这些职责：

1. 根据 HTTP 方法和路径选择操作，同时拒绝没有定义的组合。
2. 解析并验证不可信输入，再把它转换为领域层理解的数据。
3. 认证调用方，并对具体资源和操作执行授权。
4. 维护持久不变量，让并发请求和进程重启不会破坏数据。
5. 返回稳定响应，并记录足够信息以便诊断失败。

语言、框架和数据库只是实现这些职责的工具。刚开始学习时，先用一种语言完成一条可测试的请求路径，比同时比较多套技术栈更容易看清边界。本文使用 Node 24 的内置 HTTP API，因此示例没有框架依赖。

工作原理

HTTP 服务器把连接上的字节解析为请求对象。应用根据方法和目标选择处理器，再通过 中间件（middleware） 或显式函数完成请求标识、认证、限流和日志等横切工作。处理器验证输入、调用领域逻辑和存储，最后把结果编码成 HTTP 响应。

下面的图是责任流，不表示每个系统都必须拆成这些进程。小程序可以把路由、应用逻辑和存储适配器放在同一个代码库中，但各层仍应有清楚的输入和输出。

一次请求的生命周期

可以按下面的顺序追踪一条请求：

1. 服务器读取请求行、请求头和消息体，并应用大小与时间限制。
2. 请求级中间件建立请求 ID、日志上下文和经过验证的调用方身份。
3. 路由器按方法和路径选择一个处理器，找不到时返回明确的 404 或 405。
4. 处理器解析传输格式，验证字段，再调用不依赖 HTTP 对象的业务操作。
5. 存储层在需要时开启事务，检查持久约束并提交状态变化。
6. 响应映射把结果转换为状态码、响应头和表示，随后完成请求级清理。

每个请求都应拥有独立的 请求上下文（request context） 。请求 ID、认证主体和截止时间属于该请求，不应放进会被其他请求覆盖的模块级可变变量。数据库连接可以来自共享连接池，但事务和连接借用必须在请求或业务操作结束时释放。

契约先于处理器

在写路由代码前，先写出可观察契约。下面的表格展示一个创建任务操作至少要决定什么；具体选择可以不同，但不能把含义留给客户端猜测。

传输验证只能证明消息形状可接受。标题是字符串，不代表调用方有权在某个项目中创建任务，也不代表该项目仍然开放。授权和领域不变量需要独立检查，持久唯一性还应由数据库约束兜底。

状态与失败边界

服务器内存适合请求期间的临时值和可重建缓存，不适合作为唯一业务记录。多个工作进程拥有不同内存，重启会清空它，两个并发写入还可能观察到不同旧值。需要在重启后存在的数据应进入持久存储。

网络断开时，客户端可能不知道服务端是否已经提交操作。这叫结果未知：没有收到响应不能证明操作没有发生。安全重试依靠明确的方法语义，或对非幂等创建操作使用 幂等性（idempotency） 协议和原子去重。

错误响应也是契约的一部分。生产服务不应把内部堆栈和数据库消息发给调用方；它应返回稳定的机器可读类别、适合用户的说明和请求 ID。 问题详情（Problem Details） 是一种标准错误表示选择，但采用它仍需定义本服务的错误类型与字段。

示例

三个示例逐步加入路由、输入验证和真实 HTTP 往返。它们都已用本地 Node 24 执行，下面的输出来自实际运行结果。

用方法与路径选择操作

第一个示例把请求看成普通数据。路由函数只做分派和响应映射，因此可以在启动网络服务器前测试接口最外层的决定。

GET /tasks 与 POST /tasks 是两个不同操作；只匹配路径会把它们混在一起。创建分支用 201 和 Location 表达资源已经创建，未知组合则得到 404，而不是伪装成成功响应。

这个函数尚未验证 request.body，也没有真正保存任务。把未完成的边界写得明显很重要：示例下一步补上验证，持久化则留给真实存储适配器，不能用数组冒充。

把不可信输入变成有效值

验证函数拒绝非对象消息体，检查字段类型和长度，并在成功时返回规范化值。它不依赖 HTTP，因此单元测试不需要监听端口。

function validateTask(input) {
  if (input === null || typeof input !== "object" || Array.isArray(input)) {
    return { ok: false, errors: ["body must be an object"] };
  }

  const errors = [];
  if (typeof input.title !== "string" || input.title.trim() === "") {
    errors.push("title must be a non-empty string");
  } else if (input.title.length > 80) {
    errors.push("title must be at most 80 characters");
  }
  if (input.priority !== undefined && !["low", "normal", "high"].includes(input.priority)) {
    errors.push("priority is invalid");
  }

  return errors.length === 0
    ? { ok: true, value: { title: input.title.trim(), priority: input.priority ?? "normal" } }
    : { ok: false, errors };
}

const samples = [
  { title: "  Ship docs  ", priority: "high" },
  { title: "", priority: "urgent" },
  ["Ship docs"],
];

for (const sample of samples) {
  console.log(JSON.stringify(validateTask(sample)));
}

{"ok":true,"value":{"title":"Ship docs","priority":"high"}}
{"ok":false,"errors":["title must be a non-empty string","priority is invalid"]}
{"ok":false,"errors":["body must be an object"]}

成功结果包含后续逻辑可以信任的值，失败结果则可以映射为 400 Bad Request。用 String(input.title) 强制转换看似省事，却会把缺失值变成字符串 "undefined"；严格检查能保留错误的真实含义。

长度规则还需要说明计量单位。JavaScript 的 string.length 计算 UTF-16 代码单元，不等同于用户看到的字符数，也不等同于 UTF-8 字节数。这里的 80 是示例契约；真实服务必须让 UI、API 和数据库采用一致且经过测试的规则。

运行一个真实 HTTP 往返

最后的示例让操作系统分配临时端口，再用 Node 的 fetch() 发起请求。sendJson() 集中设置媒体类型和编码，处理器则保证成功与失败响应都带同一个请求 ID。

const { createServer } = require("node:http");

function sendJson(response, status, body) {
  response.writeHead(status, { "content-type": "application/json; charset=utf-8" });
  response.end(JSON.stringify(body));
}

const server = createServer((request, response) => {
  const requestId = "req-7";
  if (request.method === "GET" && request.url === "/health") {
    sendJson(response, 200, { status: "ok", requestId });
    return;
  }
  sendJson(response, 404, { error: "not_found", requestId });
});

server.listen(0, "127.0.0.1", async () => {
  const address = server.address();
  const baseUrl = `http://127.0.0.1:${address.port}`;

  for (const path of ["/health", "/missing"]) {
    const response = await fetch(`${baseUrl}${path}`);
    console.log(response.status, await response.text());
  }

  server.close();
});

200 {"status":"ok","requestId":"req-7"}
404 {"error":"not_found","requestId":"req-7"}

监听端口 0 可避免在测试中硬编码一个可能被占用的端口。应用读取 server.address() 获得实际地址，然后在结束时关闭服务器；生产进程还需要停止接收新请求、等待在途工作并设置强制退出期限。

健康端点只说明这个进程能处理该请求。它不自动证明数据库可写、队列正常或某项业务就绪。把存活检查与就绪检查分开，并让负载均衡器使用符合部署语义的那个端点。

陷阱

把请求体直接当成领域数据

**修复：**按操作建立允许字段列表，严格解析类型和边界，再从经过认证的身份与服务端状态补充受保护字段。数据库约束负责最终持久不变量，应用验证负责尽早返回有用错误。

把进程内数组当成数据库

**修复：**明确哪些状态允许丢失，哪些必须持久化。把唯一性、外键和原子更新交给支持这些保证的存储，在应用层捕获并映射约束冲突。

在提交完成前返回成功

**修复：**先定义提交点和结果未知时的重试协议。需要同时保存记录并发布事件时，可在一个事务中写入业务记录和 outbox，再由独立发布者处理事件。

用一个状态码掩盖所有结果

**修复：**为每类可观察结果定义少量稳定状态码和错误类型。保留 500 给未预期的服务端失败，记录内部原因，但不要把堆栈、SQL 或秘密写进外部响应。

先堆中间件，后确认顺序

**修复：**画出进入与返回顺序，记录每个中间件读取和产生的上下文字段。对每条受保护路由发送无凭据、无权限和有效凭据请求，不能只检查全局配置看起来正确。

让健康检查执行有副作用的工作

**修复：**存活检查保持便宜且无业务副作用。就绪检查只验证接流量所需的依赖，并为每项探测设置短期限；详细诊断放在受保护的运维接口中。

延伸阅读

• RFC 9110：HTTP 语义
• Node.js v24 文档：HTTP
• MDN：HTTP 概览
• OWASP REST 安全速查表