request-promise调用pipe()处理带请求体的POST请求失效问题

两个核心问题导致带请求体的POST转发失效：

1. request-promise默认对传入body参数的请求启用缓冲模式，会等待完整响应封装为Promise结果返回，不会返回可直接pipe的流实例，也不会立即触发请求发送。无body的GET请求默认走流模式，所以之前的逻辑能正常运行。
2. 传入body但未指定body序列化规则（JSON/表单/二进制）时，request-promise无法判断如何处理请求体数据，会直接挂起不发请求。

另外你当前直接取req.body的逻辑隐含依赖：必须提前挂载body解析中间件把请求体解析为内存对象，这种场景下如果没有同步更新Content-Length请求头，下游服务也会出现收不全请求体的问题。

方案1：纯流透传（性能最优，推荐转发场景使用） #

完全跳过请求体解析环节，直接把上游请求的原始流导向下游服务，再把下游响应流导回客户端，避免两次序列化/反序列化的开销，也不会出现body格式不匹配的问题。

1. 替换pipe方法实现，直接透传双向流：

const request = require('request'); // 用原生request库的流能力，无需rp包装

public pipe(options: any, req: Request, res: Response): void {
  // 上游请求流 -> 下游请求 -> 上游响应流
  req.pipe(request(options)).pipe(res);
}

2. 修改POST请求的配置，不要手动传入req.body，让流自动携带原始请求数据：

// streamFromService方法内的POST分支调整为
this.httpClient.pipe(
  {
    method: 'POST',
    url: url,
    headers: forwardHeaders
    // 移除body: req.body配置
  },
  req,
  res
)

注意：使用该方案时，需要把当前转发路由的注册位置放在express.json()、body-parser等会消费请求流的中间件之前，否则请求体已经被中间件解析消费，流中不会残留原始数据。

方案2：兼容已解析req.body的场景 #

如果你的服务全局挂载了body解析中间件，不方便调整路由注册顺序，可以保留req.body读取逻辑，显式配置request-promise的流模式和body序列化规则：

1. 调整pipe方法，添加流模式和序列化配置：

const rp = require('request-promise');

public pipe(options: any, req: Request, res: Response): void {
  const finalOptions = {
    ...options,
    simple: false, // 不把非2xx状态码抛为错误
    resolveWithFullResponse: true, // 返回完整响应对象而非仅body
    // 自动识别对象类型body，按JSON格式序列化
    json: typeof options.body === 'object' && options.body !== null ? true : options.json
  };
  rp(finalOptions).pipe(res);
}

2. 检查forwardHeaders生成逻辑，确保保留原始请求的Content-Type、Content-Length头，不要被覆盖为默认值。

• 转发时需要过滤Host、Connection、Keep-Alive、Transfer-Encoding这类逐跳头，否则会导致下游请求路由或传输异常
• 不要同时手动传body参数又pipe req流，会造成请求体重复写入
• 如果请求体是文件上传等multipart格式，必须用纯流透传方案，提前解析会破坏文件二进制格式

内容的提问来源于stack exchange，提问作者limak111