后端对接

后端对接：把网站的「手」和「脑」连起来

一个网站开始真正产生价值，往往不是页面做得多漂亮，而是表单能收到数据、登录能验证身份、支付回调能入账——这些都要靠后端对接来完成。对用 AI 生成的网站来说尤其如此：AI 可以快速产出一套完整的前端，但业务逻辑、数据库读写、第三方服务调用这些「幕后工作」，仍然要靠后端接口落地。

后端对接可以概括成一句话：接收请求、校验数据、处理业务、返回结果。听起来简单，但生产环境里相当一部分事故恰恰发生在这层，根因通常不是代码写不出来，而是边界情况没人处理。

一个典型的对接场景

假设你准备上线一个活动报名网站，需要实现三件事：报名表单提交、后台查看报名列表、报名成功后自动发送确认邮件。前端用 HTML 加 JavaScript 已经写好，后端要解决的就是下表这三类问题：

不确定后端用什么语言，可以先看 Laravel 后端指南、Node.js Express 指南 和 Flask API 示例，再结合 数据库选型 定技术栈。前后端接口规范可以参考 REST API 设计指南。

用 AI 生成后端代码的提示词模板

用 AI 生成后端时，提示词里的细节越多，产出越接近可用。下面这个模板可以直接套用：

请帮我生成网站后端的[功能]代码。
- 后端语言：[PHP/Node.js/Python/Go]
- 框架：[原生/Laravel/Express/Flask]
- 数据库：[MySQL/PostgreSQL/MongoDB]
- 功能：[详细描述]

输出：完整代码、数据库设计、API接口文档、错误处理、安全注意事项。

需要提醒的是，AI 生成的代码必须人工审查，重点看三处：输入校验是否完整、SQL 是否全部参数化、错误信息是否会泄露内部路径。

一个能用的 PHP 联系表单

以最基础的「联系表单」为例，一段能直接上线的 PHP 代码至少要做四件事：只接受 POST、校验邮箱格式、限制字段长度、返回 JSON 而不是 HTML。

<?php
header("Content-Type: application/json");
if ($_SERVER["REQUEST_METHOD"] !== "POST") {
    http_response_code(405);
    echo json_encode(["error" => "仅支持 POST"]);
    exit;
}
$name = trim($_POST["name"] ?? "");
$email = trim($_POST["email"] ?? "");
$message = trim($_POST["message"] ?? "");
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    http_response_code(400);
    echo json_encode(["error" => "无效邮箱"]);
    exit;
}
if (mb_strlen($message) > 2000) {
    http_response_code(400);
    echo json_encode(["error" => "留言过长"]);
    exit;
}
mail("[email protected]", "来自 $name 的留言", $message, "From: $email");
echo json_encode(["success" => true]);
?>

想做到不刷新页面就提交，配合 AJAX 的完整实现参考 联系表单 AJAX 提交。

Nginx 反向代理：把 API 暴露给前端

后端常和前端跑在不同端口，比如 Node.js 监听 3000、Nginx 监听 80。用反向代理可以把 /api/ 的请求转发给后端进程：

location /api/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

这样对外只暴露 80/443 端口，后端进程不直接接触公网，还能在这一层统一做限流、缓存和访问日志。完整站点配置参考 Nginx 站点配置，上线前先选一台合适的 服务器。

API 设计：版本、超时与统一响应

接口一旦上线，就不要再改动已有字段的含义，破坏性变更放到新版本：

/api/v1/orders
/api/v2/orders

响应建议统一结构，方便前端和调试工具解析：

{
  "success": true,
  "data": { "order_id": "ORD-20260712-001" }
}

出错时返回一致格式，并带上 request_id。用户反馈问题时只需报一个编号，你就能在日志里定位到具体请求：

{
  "success": false,
  "error": {
    "code": "RATE_LIMIT",
    "message": "请求过于频繁，请 30 秒后重试。",
    "request_id": "req_abc123"
  }
}

另外，预计超过 2 秒才能完成的请求，建议先返回一个任务 ID 让前端轮询，而不是让用户一直挂在等待页。

错误处理与重试策略

把可重试错误和不可重试错误分开处理：

重试采用指数退避，防止雪崩：

第 1 次重试：等待 1 秒
第 2 次重试：等待 2 秒
第 3 次重试：等待 4 秒
最多重试：3 次

安全基线：三个必查项

每个后端接口上线前都要过三关：

1. 认证（Authentication）：确认请求者身份，可参考 JWT 认证实现。
2. 授权（Authorization）：确认该用户是否有权限执行操作。
3. 限流（Rate limiting）：确认请求频率正常，防止脚本刷接口。

漏掉任何一项，接口都可能被滥用。更全面的防护见 网站安全最佳实践。

一个真实案例：报名页被脚本刷爆

一家做线下活动报名的小公司，上线当天收到上千条「报名」记录，其中大部分是同一 IP 用脚本提交的空数据，数据库被灌满，管理后台直接卡死。

复盘发现三个问题：表单没有验证码、后端没有校验字段格式、接口没有限流。修复也很直接：后端加每 IP 每分钟 10 次的限流，前端加验证码，字段校验补齐，之后再没出现类似问题。

常见问题

Q：AI 生成的后端代码能直接用吗？
A：可以作为初稿，但必须人工审查输入校验、SQL 参数化和错误处理，建议先在测试环境跑一遍边界用例。

Q：前后端一定要分离吗？
A：不一定。简单站点用 PHP 或服务端渲染即可；需要多端复用、前后端并行开发时再拆。

Q：接口报 500 怎么排查？
A：先看错误日志里的 request_id，确认是参数、权限还是上游服务问题，再决定修代码还是重试。

参考：PHP 手册（https://www.php.net/manual/zh/ ）、Nginx 官方文档（https://nginx.org/en/docs/ ）、OWASP API 安全 Top 10（https://owasp.org/API-Security/ ）