全栈面试：后端与 API

RESTful API 是什么？

RESTful API 使用资源和 HTTP 方法表达操作。

常见方法：

• GET 查询资源
• POST 创建资源
• PUT 整体更新资源
• PATCH 局部更新资源
• DELETE 删除资源

示例：

GET /api/users
GET /api/users/1
POST /api/users
PATCH /api/users/1
DELETE /api/users/1

核心不是 URL 好看，而是接口语义一致、可预测、易维护。

GET 和 POST 有什么区别？

常见区别：

• GET 通常用于查询，参数多放在 URL。
• POST 通常用于创建或提交，参数多放在请求体。
• GET 更容易被缓存。
• GET 不应该产生副作用。
• POST 可以携带更复杂的数据。

面试时注意：安全性不能简单说“POST 更安全”。如果没有 HTTPS，POST 请求体也可能被窃听。

接口如何设计错误返回？

错误返回应该稳定、可读、可处理。

示例：

{
  "code": "USER_NOT_FOUND",
  "message": "User not found",
  "requestId": "abc-123"
}

常见字段：

• code 机器可读错误码
• message 用户或开发者可读信息
• details 具体字段错误
• requestId 排查日志用

不要只返回一个字符串，也不要所有错误都返回 200。

鉴权和授权有什么区别？

鉴权是确认“你是谁”，例如登录、token 校验。

授权是确认“你能做什么”，例如角色权限、资源权限、按钮权限。

常见方案：

• Session + Cookie
• JWT
• OAuth 2.0
• RBAC 角色权限
• ABAC 属性权限

面试回答可以补充：前端权限只负责体验，真正权限必须在后端校验。

JWT 有什么优缺点？

优点：

• 无状态，服务端不一定需要存 session
• 适合分布式服务
• 可以携带少量用户信息

缺点：

• 一旦签发，在过期前不容易主动失效
• token 泄露风险高
• payload 不应该存敏感信息
• token 太大会增加请求成本

常见实践：短期 access token + 长期 refresh token，并配合 HTTPS、安全存储和黑名单机制。

如何做分页？

常见分页方式：

• page + pageSize
• offset + limit
• cursor 游标分页

普通后台列表可以用 page 分页。

大数据量、无限滚动、实时数据更适合 cursor 分页。

GET /api/posts?cursor=xxx&limit=20

cursor 分页比 offset 更稳定，性能也更容易优化。

如何避免接口重复提交？

常见方案：

• 前端按钮 loading 时禁用
• 后端使用幂等 key
• 唯一索引
• 请求去重
• 分布式锁

关键是后端要兜底。前端禁用按钮只能改善体验，不能保证业务安全。

什么是幂等？

幂等是同一个操作执行一次和执行多次，最终结果一致。

例如：

• 查询通常是幂等的
• 删除同一个资源可以设计成幂等
• 创建订单通常不是天然幂等

支付、下单、创建资源这类接口，要特别考虑幂等。

后端如何处理并发？

常见手段：

• 数据库事务
• 乐观锁
• 悲观锁
• 唯一约束
• 队列削峰
• 缓存和限流
• 分布式锁

回答时要结合场景。库存扣减、支付回调、抢购都需要更严格的并发控制。

API 面试追问

如何设计登录接口？

登录接口通常包括账号密码校验、验证码或风控校验、密码哈希比对、生成 token/session、返回用户基础信息和权限信息。密码不能明文存储，必须使用安全哈希算法加盐。

更完整的设计会包含刷新 token、退出登录、登录失败次数限制、异地登录提醒和审计日志。面试时可以强调：登录不是只返回 token，还要考虑安全、过期、刷新、权限和风控。

如何设计文件上传接口？

小文件可以直接表单上传，大文件通常采用分片上传。典型流程是：初始化上传任务，前端分片并计算 hash，后端接收分片，记录上传进度，全部完成后合并文件并校验完整性。

还要考虑文件类型限制、大小限制、病毒扫描、鉴权、存储位置、断点续传和 CDN 访问。图片类文件可以补充压缩、缩略图和 EXIF 清理。

如何做接口版本管理？

常见方式是在 URL、Header 或网关层做版本区分，例如 /api/v1/users。版本管理的核心不是形式，而是保证旧客户端不被破坏。

成熟做法是：新增字段保持兼容，删除或改语义要走废弃周期，接口文档标记版本，监控旧版本调用量，再逐步下线。

如何处理接口超时？

接口超时要先区分是前端等待超时、网关超时、服务处理慢、数据库慢还是第三方依赖慢。客户端要设置合理超时时间，并提供重试、取消、降级或友好提示。

服务端要有超时控制、熔断、限流和异步化方案。对于非实时任务，可以返回任务 ID，让前端轮询或通过消息通知结果。

如何做限流？

限流可以按 IP、用户、接口、租户、API key 或业务维度做。常见算法有固定窗口、滑动窗口、漏桶和令牌桶。

工程上要配合网关、Redis 或服务内限流实现。登录、短信、搜索、上传、AI 调用等高成本接口都应该重点限流，并给出清晰的错误码和重试提示。

如何做接口日志？

接口日志至少记录 requestId、用户或租户、接口路径、方法、状态码、耗时、错误信息和关键业务 ID。敏感字段如密码、token、身份证号要脱敏。

日志要能和前端错误、网关日志、数据库慢查询关联起来。面试时可以说：日志不是越多越好，而是要能支持排障和审计。

如何排查线上接口变慢？

先看监控确认是整体变慢还是某个接口变慢，再按链路排查：网关耗时、服务耗时、数据库慢查询、缓存命中率、锁等待、连接池、第三方依赖和机器资源。

如果有 trace，可以直接看耗时集中在哪一段。处理上通常先止血，例如扩容、降级、缓存、限流，再做根因修复。

如何保证接口安全？

接口安全要从认证、授权、输入校验、传输加密、限流、防重放、日志审计和敏感数据保护入手。认证解决“你是谁”，授权解决“你能做什么”。

实际项目里还要防 XSS、CSRF、SQL 注入、越权访问和文件上传风险。面试时不要只说 token，要把权限校验和数据边界说清楚。