PSR-7 Stream读取请求体后为什么中间件拿不到内容为什么结果为空或不符合预期

中间件先读取了 PSR-7 请求体，后面的处理器却拿到空字符串，通常不是请求真的没有 body，而是同一个 StreamInterface 的读取游标已经在末尾。PSR-7 的请求消息强调不可变，但请求体 Stream 仍可能改变自己的游标；因此 withAttribute() 返回新请求，并不会自动复制或倒回 body。

排查时先看读取方法：getContents() 从当前位置读到末尾，第二次调用自然可能为空。可 seek 的流可以在读取后 rewind()，不可 seek 的流则应把“只读取一次”和“交给下游的新流”设计清楚。

官方规范：https://www.php-fig.org/psr/psr-7/

为什么第一次有内容，第二次却变成空字符串

PSR-7 用 Stream 抽象请求体，是为了避免把很大的 body 强制装进一个字符串。Stream 暴露 isReadable()、isWritable() 和 isSeekable()，不同实现的能力并不相同：内存流通常可以回退，socket、管道或回调流可能只能顺序读取。

下面的最小中间件片段故意把读取动作写成一次，再观察当前位置。它是示例代码，不代表在本机已经运行；关键点是不要把 getBody() 当成每次都会返回全新内容的字符串。

getBody();
    // getContents() 从当前游标读到末尾，第二次读取不保证还有内容。
    $payload = $body->getContents();

    // 记录长度时避免直接把完整请求体写进日志。
    $length = strlen($payload);
    error_log('request body bytes=' . $length);

    // 这里只演示读取；可 seek 的恢复动作放在后面的修复版本中。
    return $handler->handle($request);
}

如果另一个中间件或控制器在 inspectBody() 之后调用 getContents()，它看到空值是符合游标语义的。请求对象本身是否通过 withAttribute() 复制，与 body 内部资源是否已经读过，是两件事。

可 seek 的请求体，读取后怎样交还给下游

当中间件确实需要读完整 body，同时又要让下游继续解析，先判断 isSeekable()。读取前记录当前位置并在读取后回到原位置，通常比无条件 rewind() 更适合可复用组件，因为调用方可能已经把游标放在一个有意义的位置。

getBody();

    if (!$body->isReadable()) {
        // 不可读时交给统一错误处理，避免把空字符串当成合法 JSON。
        throw new RuntimeException('request body is not readable');
    }

    $start = $body->isSeekable() ? $body->tell() : null;
    $payload = $body->getContents();

    if ($start !== null) {
        // 恢复到读取前的位置，让下游保持原有的读取契约。
        $body->seek($start);
    }

    // 示例只保留长度；真实日志必须先脱敏再记录。
    error_log('body bytes=' . strlen($payload));
    return $handler->handle($request);
}

这里的恢复动作只适用于真正支持 seek 的流。不要捕获 seek() 异常后继续假装恢复成功，也不要把恢复结果写成“所有 PSR-7 请求体都能 rewind”。规范明确要求消费者先通过能力方法了解流的限制。

不可 seek 时，为什么应该创建新的请求体

不可 seek 的流没有可靠的“回到开头”操作。中间件如果必须先消费正文，就应把读到的内容交给下游使用的新流，而不是继续传递已经到末尾的原对象。PSR-17 的 StreamFactory 能把字符串包装成新的 Stream，再通过 PSR-7 的 withBody() 返回一个新请求。

getBody();
    // 只在业务确实需要缓存时读取；大请求体会增加内存占用。
    $payload = $body->getContents();

    // 用新 Stream 交给下游，不依赖原流是否支持 seek。
    $replacement = $streamFactory->createStream($payload);
    $nextRequest = $request->withBody($replacement);

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

这个方案的代价是把正文放进内存，并可能复制一次数据。上传文件、超大 JSON 或流式签名场景不应默认采用它，可以改为让一个组件独占读取，再把解析后的结构放入 request attributes，或使用支持重放的临时文件流。

把中间件顺序、内存和敏感数据一起定下来

如果认证中间件要计算 body 摘要，日志中间件要记录长度，业务处理器又要解析 JSON，最简单的约定是由最靠前的组件一次读取、完成脱敏和摘要，再把可 seek 的流恢复或把新的流交给下游。不要让多个中间件各自“顺手读一次”，那会让结果依赖注册顺序。

最后检查三件事：读取 API 是否是 getContents() 而不是误以为会自动 rewind；流能力是否在运行时判断；日志是否只保留长度、摘要或脱敏字段。这样才能同时解决“后续为空”和“为了修复空值而泄露请求体”的问题。

常见问题

把 $request->withAttribute('body', $payload) 放进去能恢复请求体吗？

不能自动恢复。它只是把字符串放入属性，并不会改变原来的 body 游标；下游仍调用 getBody() 时，拿到的还是原 Stream。要么恢复可 seek 游标，要么显式用 withBody() 换成新的 Stream。

为什么调用 (string) $request->getBody() 后表现可能不同？

__toString() 是一次性取得整体内容的便利接口，但具体实现对游标的处理仍应以实现文档和能力判断为准。跨组件设计不要依赖“强制转换后一定自动回到开头”，应明确恢复或替换策略。