第2章 HTTP请求拦截原理：请求/响应生命周期、代理与拦截器机制、中间件实现思路

在 API 接入测试中，Mock 网络请求的核心在于理解 HTTP 请求从发起到响应返回的完整路径，以及如何在路径中插入拦截点。本章从请求/响应生命周期出发，逐步拆解代理与拦截器的工作机制，并给出中间件模式的实现思路，为后续章节搭建 Mock 拦截层奠定理论基础。

2.1 请求/响应生命周期

一次完整的 HTTP 请求/交互包含以下 7 个阶段，每个阶段都可能成为 Mock 或拦截的介入点：

2.2 代理与拦截器机制

代理（Proxy）和拦截器（Interceptor）是实现请求拦截的两种主流模式，它们在架构层级和工作方式上有明显区别：

2.2.1 请求拦截点与响应拦截点

在拦截器实现中，通常暴露两个关键钩子：

• 请求拦截点（Request Hook） — 在 DNS 解析和连接建立之后、数据写入 Socket 之前触发。此时可修改请求方法、URL、Header、Body。
• 响应拦截点（Response Hook） — 在客户端读取到原始响应之后、回调业务代码之前触发。此时可修改状态码、响应头、响应体。

2.3 中间件实现思路

中间件（Middleware）是一种比拦截器更灵活的请求处理链模式，广泛用于 Web 框架（Koa、Express、Flask）和 Mock 代理层。其核心思想是 洋葱模型（Onion Model）：请求依次穿过每个中间件，到达核心处理器后再按原路返回。

2.3.1 洋葱模型执行流程

1. 请求进入中间件 1 的「前处理」阶段。
2. 中间件 1 调用 next() 将请求传递给中间件 2。
3. 中间件 2 执行前处理，再调用 next() 传递给中间件 3。
4. 中间件 3 执行前处理，调用 next() 到达目标处理器（或 Mock 桩）。
5. 响应从中间件 3 的「后处理」开始逐层返回，最终回到中间件 1 的后处理。

2.3.2 精简中间件链实现

以下 Python 实现展示了如何用 register 和 run 构造一个可嵌套的中间件链，每个中间件可拦截请求、返回 Mock 响应或透传：

class MockMiddlewareChain:
    """可嵌套的中间件链，支持请求拦截与 Mock 响应注入"""

    def __init__(self):
        self._layers = []

    def register(self, middleware_fn):
        """注册中间件，按注册顺序组成链"""
        self._layers.append(middleware_fn)
        return self

    def run(self, request):
        """执行中间件链，采用洋葱模型"""

        def wrapper(index, req):
            if index >= len(self._layers):
                # 到达最内层，默认返回透传响应（实际应发起 HTTP 请求）
                return {"status": 502, "body": "no handler"}
            middleware = self._layers[index]
            return middleware(req, lambda r: wrapper(index + 1, r))

        return wrapper(0, request)

# ------------------------------------------------------------
# 使用示例：注册两个拦截中间件和一个 Mock 桩
# ------------------------------------------------------------
chain = MockMiddlewareChain()

@chain.register
def log_middleware(request, next_):
    print(f"[请求拦截] {request.get('method', 'GET')} {request['url']}")
    response = next_(request)
    print(f"[响应拦截] 状态码: {response['status']}")
    return response

@chain.register
def auth_middleware(request, next_):
    # 模拟注入认证头
    headers = request.get("headers", {})
    headers["Authorization"] = "Bearer mock--123"
    request["headers"] = headers
    return next_(request)

@chain.register
def mock_user_api(request, next_):
    # 针对 /api/user 直接返回 Mock 数据，不穿透
    if request["url"].endswith("/api/user"):
        return {"status": 200, "body": {"name": "MockUser", "role": "tester"}}
    return next_(request)

# 测试请求
test_request = {"method": "GET", "url": "https://api.example.com/api/user", "headers": {}}
result = chain.run(test_request)
print("最终响应:", result)

2.4 调试与稳定性建议

• 日志埋点： 在每个拦截器/中间件的入口和出口打印请求摘要（方法、URL、耗时），便于定位 Mock 未生效或响应异常的问题。
• 超时控制： 中间件链中若存在真实网络调用，务必设置 timeout 参数，防止链阻塞导致测试挂起。
• 优雅降级： 当 Mock 服务不可用时，中间件应捕获异常并返回预设的 fallback 响应，而不是抛出 500 错误影响测试流程。

2.5 常见错误与排查

2.6 性能与稳定性优化要点

• 异步化中间件： 使用 asyncio 或 trio 将 IO 密集型中间件（如日志写入、认证查询）改为异步执行，避免阻塞链中后续中间件。
• 响应缓存： 对于频繁访问且响应稳定的 Mock 接口，在中间件层维护 LRU 缓存，命中后直接返回，将延迟从毫秒级降至微秒级。
• 熔断机制： 当真实服务的 Mock 桩连续超时次数超过阈值时，中间件应自动熔断，直接返回预设降级响应，防止雪崩效应。
• 链路追踪 ID： 在每个请求进入中间件链时注入全局唯一的 trace-id，贯穿所有拦截器日志，便于在分布式测试环境中串联调用链。