PSR-7 Stream读取请求体后为什么中间件拿不到内容怎样在批处理代码中减少额外分配

我在排查 PHP 中间件链时遇到过一种很容易误判的现象：第一个中间件用 $request->getBody()->getContents() 读到了 JSON，紧接着的鉴权或日志中间件却拿到空字符串。请求并没有凭空消失，真正变化的是同一个 PSR-7 Stream 的当前位置。

处理原则很简单：先看流是否可读、可定位和可回绕；可回绕时保存当前位置并在读取后恢复，不可回绕时不要强行 rewind()，而是让一个组件拥有读取权，或把有限大小的内容交给下游。批处理则应优先分块读取，减少整段正文的重复字符串分配。

PSR-7 的请求体是共享的 Stream 对象，不是每次调用都会重新生成的字符串；一次读取会推进游标，后续组件自然会从新位置继续读。

为什么第二个中间件读到的是空内容

PSR-7 只规定了消息和流的接口，具体实现可能包裹内存流、临时文件、socket 或其他顺序数据源。getBody() 返回的是同一个 StreamInterface 实例。调用 read() 或 getContents() 后，游标会向前移动；当它已经位于末尾，第二次读取就会返回空内容。

这也是为什么“把请求对象复制一份”通常没有用：消息对象可以保持不可变风格，但 Stream 本身的游标和内容状态并不保证不可变。问题的触发信号通常是日志中第一段正文正常、下游校验字段为空，或者只有开启某个日志中间件后接口才开始报请求体缺失。

先确认 Stream 的位置和能力

值班时我会先记录四个事实，而不是立即在所有地方加 rewind()：是否可读、是否可回绕、当前位置是多少、总大小是否可知。这样能把“读空”区分成游标已到末尾、流不可回绕、流本来就没有大小等不同情况。

getBody();

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

// getSize() 可能返回 null，不能把未知大小当成 0。
$size = $body->getSize();
$position = $body->tell();

error_log(json_encode([
    'readable' => $body->isReadable(),
    'seekable' => $body->isSeekable(),
    'position' => $position,
    'size' => $size,
], JSON_UNESCAPED_UNICODE));

如果第一次进入中间件时 tell() 已经接近 getSize()，优先查调用顺序；如果 isSeekable() 为假，就把它视为只能顺序消费的数据源。PSR-7 规范也提醒消费者：Stream 可能是可变的，游标位置属于流状态。

可回绕流的中间件处理方式

对于内存流或临时文件这类可回绕流，中间件可以保存当前位置，读取自己需要的内容，然后恢复到原位置。恢复的是进入中间件前的位置，而不是想当然地恢复到 0；这样一个已经被上游部分消费的请求不会被重复处理。

getBody();
$start = $body->tell();

try {
    // getContents() 从当前位置读到末尾，示例只适合有明确大小上限的正文。
    $preview = $body->getContents();
    $logger->info('request body preview', ['length' => strlen($preview)]);
} finally {
    // 只有可回绕时才恢复，避免对 socket、pipe 等顺序流抛出异常。
    if ($body->isSeekable()) {
        $body->seek($start);
    }
}

生产代码还要给日志预览设置上限，不能因为“恢复游标”就默认可以无上限读取。对于签名校验，最好让签名组件成为唯一正文消费者；日志只记录长度、摘要或经过截断的片段，避免一次请求体同时产生多份大字符串。

不可回绕流怎样交接正文

socket、pipe 和部分回调流可能只支持顺序访问。此时强行调用 rewind() 或 seek(0) 不是修复，而是把问题变成运行时异常。更稳妥的做法是明确“谁拥有读取权”：第一个组件边读边计算需要的元数据，再把结果放入 request attributes；下游读取同一个流剩余部分。

getBody();
$hash = hash_init('sha256');
$total = 0;

while (!$body->eof()) {
    // 固定块大小限制单次分配，避免把未知长度正文整体读入内存。
    $chunk = $body->read(8192);
    if ($chunk === '') {
        break;
    }
    hash_update($hash, $chunk);
    $total += strlen($chunk);
}

$request = $request->withAttribute('body_sha256', hash_final($hash));
$request = $request->withAttribute('body_bytes_seen', $total);
// 下游只能读取尚未消费的部分；需要完整正文时应在更早的位置建立受控缓冲。

如果业务确实要求多个组件都看到完整正文，就在请求入口建立一次有大小上限的缓冲，再把新的 Stream 附加到消息上。这个决策要和上传大小、超时、磁盘空间一起设计，而不是在每个中间件里各自调用一次 getContents()。

批处理怎样减少额外分配

批量导入、审计或签名场景最容易出现“读一份、复制一份、再拼接一份”的峰值内存。我的经验是把块大小和缓冲所有权写进运行手册：块只在当前循环内存在，结果对象只保留必要字段，超过阈值就转入临时流或直接拒绝。

getBody();
$total = 0;

while (!$body->eof()) {
    // 块大小固定，便于估算单个请求的额外分配上限。
    $chunk = $body->read(32768);
    if ($chunk === '') {
        break;
    }
    fwrite($buffer, $chunk);
    $total += strlen($chunk);
    if ($total > 8 * 1024 * 1024) {
        fclose($buffer); // 超过业务上限时及时释放临时资源。
        throw new LengthException('请求体超过批处理上限');
    }
}

rewind($buffer); // 当前缓冲是我们自己创建的，可安全回到开头交给下游。
$request = $request->withBody(new Stream($buffer));

这里的 Stream 代表项目使用的 PSR-7 Stream 实现，具体类名应替换为依赖包提供的实现。关键点不是某个固定类名，而是只建立一次受控副本，并在超限、异常和成功路径都关闭资源。

回滚、告警与复盘怎么留证

发布时可以先把“恢复游标的中间件”放在开关后，保留原先单一消费者路径；出现请求体大小上涨、签名失败率异常或临时目录占用持续增长时，关闭开关即可回退。不要把回滚定义成再次读取同一个不可回绕流。

告警至少观察四项：请求体读取失败率、超过上限的请求数、每个请求的峰值内存、临时缓冲的写入量。复盘记录则写清进入中间件时的位置、isSeekable() 结果、实际消费者、缓冲上限和下游是否收到完整正文。这样下次看到“中间件拿不到内容”，可以先判断是游标、能力还是容量问题。

相关问题

为什么复制 Request 不能让正文重新出现？因为复制的消息仍可能引用同一个 Stream，游标状态没有自动复位。

什么时候可以直接 rewind？只有确认流可回绕，并且你确实拥有恢复位置的责任时才这样做；顺序流要改用一次消费或受控缓冲。

批处理应该优先调大块大小吗？先固定内存上限和超限策略，再根据真实指标调整块大小，不能用更大的块掩盖重复复制。