场景：某项目后端 API 混用 RESTful 和 RPC 风格：

// 不一致的设计 — 前端工程师崩溃
POST /api/getUserInfo        // 用了动词
POST /api/user/create        // RESTful 但路径不对
GET  /api/user_list          // 下划线风格
GET  /api/order-detail/123   // 连字符风格
POST /api/orders/delete/456  // 用 POST 删除？

问题：前端每次都要查文档才能确定用哪个方法、哪个路径、返回什么格式。

修复：统一 RESTful 规范 + 自动生成 API 文档（Swagger/OpenAPI）。

// 统一后的设计
GET    /api/v1/users           // 列表
POST   /api/v1/users           // 创建
GET    /api/v1/users/:id       // 详情
PUT    /api/v1/users/:id       // 全量更新
DELETE /api/v1/users/:id       // 删除
GET    /api/v1/users/:id/orders // 子资源

问题：JWT 无状态，签发后无法主动撤销。如果 Token 泄露，攻击者在过期前可一直使用。

解决方案（多层防御）：

1. 短有效期：Access Token 15 分钟，即使泄露窗口也小
2. Refresh Token Rotation：刷新时轮换，检测重放攻击
3. Token 黑名单：登出/改密码时将 Token 的 jti 加入 Redis 黑名单
4. IP 绑定：签发时记录 IP，使用时校验（可选）
5. HTTPS：传输层加密，防止中间人窃取

// 黑名单检查中间件 (伪代码)
async function jwtGuard(req, res, next) {
  const token = extractToken(req);
  const payload = jwt.verify(token, SECRET);
  const isBlacklisted = await redis.get(`blacklist:${payload.jti}`);
  if (isBlacklisted) return res.status(401).json({ error: 'Token revoked' });
  req.user = payload;
  next();
}

场景：某开放 API 被爬虫/攻击者高频率调用，导致后端数据库连接池耗尽，正常用户无法使用。

应急处理：

1. 紧急止损：WAF 层面按 IP 黑名单封禁攻击源
2. 启用限流：按 IP 限 100 次/分钟，按用户限 1000 次/分钟
3. 分析日志：定位异常调用模式（User-Agent、路径、时间分布）
4. 长期方案：API Gateway 统一限流 + 验证码 + API Key 白名单

// Nginx 限流配置
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/m;
limit_req zone=api burst=50 nodelay;

// IP 黑名单
deny 203.0.113.0/24;
deny 198.51.100.0/24;

场景：某团队将系统拆成 20+ 微服务，一个用户请求涉及 6 个服务调用。出 Bug 时完全无法定位是哪个服务的问题。

根因：没有分布式追踪、没有统一日志、没有服务间调用可视化。

解决方案：

1. 引入分布式追踪：每个请求生成 Trace ID，在各服务间传递
2. 统一日志：ELK (Elasticsearch + Logstash + Kibana) 集中收集
3. 服务网格：Istio/Linkerd 自动注入追踪信息
4. 复盘：20 个服务是否合理？考虑合并一些过于碎片化的服务

// 在请求头中传递 Trace ID
app.use((req, res, next) => {
  const traceId = req.headers['x-trace-id'] || uuid();
  req.traceId = traceId;
  res.setHeader('X-Trace-Id', traceId);
  // 所有日志带上 traceId
  logger.defaultMeta = { traceId };
  next();
});

场景：电商系统的第三方支付网关宕机，所有支付请求超时，线程池耗尽导致整个系统雪崩。

解决方案：熔断 + 降级

// Resilience4j 熔断配置
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .failureRateThreshold(50)           // 失败率 50% 触发熔断
    .waitDurationInOpenState(Duration.ofSeconds(30))  // 熔断 30 秒
    .slidingWindowSize(10)              // 滑动窗口 10 次请求
    .permittedNumberOfCallsInHalfOpenState(3)  // 半开时放 3 个试探
    .build();

// 降级逻辑
@CircuitBreaker(name = "payment", fallbackMethod = "payFallback")
public PaymentResult pay(Order order) {
    return paymentClient.charge(order);
}

public PaymentResult payFallback(Order order, Exception e) {
    // 降级方案 1：记录到数据库，稍后重试
    pendingPaymentRepository.save(order);
    // 降级方案 2：通知用户
    notificationService.notify(order.getUserId(),
        "支付系统繁忙，我们稍后自动重试");
    return PaymentResult.queued(order.getId());
}