PSR-7 Stream读取请求体后为什么中间件拿不到内容怎样完成一个可复用的最小示例

PSR-7 中间件先读取请求体，后面的中间件却拿到空字符串，通常不是请求内容丢失，而是多个组件共享了同一个 StreamInterface，前一个读取动作已经把游标推进到了末尾。可回退的流在读取前后配合 isSeekable() 与 rewind()；不可回退的流则只解析一次，把结果放到 request attribute 交给下游。

官方地址：https://www.php-fig.org/psr/psr-7/

下面的示例只针对有限大小的 JSON 请求体。上传文件、大请求体和 socket 流不应直接套用“全部读进字符串”的方式。

为什么中间件读过后下游只拿到空字符串

请求对象的 withHeader()、withAttribute() 等方法会返回新对象，但 getBody() 返回的是一个带当前位置的流。第一次调用 getContents() 会从当前位置读到末尾；如果此时不回退，第二个消费者看到的就是 EOF。

PSR-7 规范要求流暴露可读、可写和可 seek 能力。注意，__toString() 会尝试从开头读取整个流，短 JSON 可以这样用，但它仍可能一次性占用大量内存，不适合拿来处理任意上传内容。

可复用的最小中间件写法

对于 php://temp、普通文件等可回退流，可以把“读取并复位”封装成一个小函数。生产代码还应限制正文长度，避免日志或解析逻辑把超大请求全部放进内存。

getBody();

    // 先确认流能读、能回退；不可 seek 的流不能承诺下游再次读取。
    if (!$stream->isReadable() || !$stream->isSeekable()) {
        throw new RuntimeException('请求体流不可读或不可回退');
    }

    $stream->rewind();
    if ($stream->getSize() !== null && $stream->getSize() > $maxBytes) {
        throw new LengthException('请求体超过允许大小');
    }

    $raw = $stream->getContents();
    // 让后续中间件从完整请求体开始读，而不是从 EOF 开始读。
    $stream->rewind();
    return $raw;
}

function bodyLoggingMiddleware(
    ServerRequestInterface $request,
    RequestHandlerInterface $handler
): ResponseInterface {
    try {
        $raw = readBodyAndRewind($request);
        // 这里只记录摘要；真实项目不要把密码、令牌等敏感字段写入日志。
        error_log('request-body-bytes=' . strlen($raw));
    } catch (Throwable $e) {
        // 读取失败交给项目的异常映射，不要静默吞掉流状态错误。
        throw $e;
    }

    return $handler->handle($request);
}

这里的关键不是把请求对象重新赋值，而是让同一个 body 流回到起点。下游若仍然使用 $request->getBody()->getContents()，就能重新读到完整正文。若要解析 JSON，建议在长度检查后执行 json_decode($raw, true, 512, JSON_THROW_ON_ERROR)，再把解析结果作为属性传给后续业务。

可 seek 与不可 seek 的边界怎么处理

isSeekable() 返回 false 时，常见原因是底层对象来自 socket、pipe 或回调式流。此时“读完再 rewind”在语义上就不成立。中间件应该承担一次解析责任，然后通过不可变消息方法交付结果：

getBody();
    if (!$stream->isReadable()) {
        throw new RuntimeException('请求体不可读');
    }

    // 非 seekable 流只能消费一次；解析结果才是下游共享的契约。
    $payload = json_decode($stream->getContents(), true, 512, JSON_THROW_ON_ERROR);
    $nextRequest = $request->withAttribute('json_payload', $payload);

    return $handler->handle($nextRequest);
}

不要用“把游标移到末尾”来判断正文是否为空，也不要假设 getSize() 永远有值；网络流可能无法提供长度。对不可 seek 的请求，应该在接口约定中明确“下游使用属性”，而不是让每层都偷偷尝试重读。

用三个检查点验证中间件

最小回归用例至少覆盖三种情况：第一，正文为 {"id":7} 时，日志中间件读取后，业务 handler 仍能读到同样内容；第二，空正文不能被误判为“游标问题”，JSON 解析应返回明确错误；第三，超过上限的正文在进入 JSON 解析前就被拒绝。

如果测试替身使用的是可 seek 的内存流，却在生产接入不可 seek 的真实流，测试会掩盖问题。因此除了内容断言，还要断言 isSeekable() 分支和下游拿到的 attribute。这样才能把“流被消费一次”与“业务字段为空”分开定位。

常见问题

把请求对象复制一份能恢复 body 吗？

不能保证。复制消息对象不等于复制底层流，两个请求可能仍然引用同一个游标。需要新 body 时，应明确创建新的流实例。

直接使用 (string) $request->getBody() 可以吗？

短正文可以，但规范要求它尝试从开头读到结尾，可能产生较大内存开销。它也不能替代对不可 seek 流的契约设计。

为什么用了 rewind() 仍然读不到？

先检查 isSeekable()、isReadable() 和异常日志；如果底层流不可 seek，应该改成一次解析后传 attribute，而不是继续重复回退。