网关层响应体动态合并应采用“手动解析+异步聚合+结构化组装”，而非ESI协议，因Spring Cloud Gateway等不支持ESI解析，需通过并行调用、状态校验、白名单字段映射与错误隔离实现数据流编排。
网关层做响应体动态合并，不是用 ESI（Edge Side Includes）标准协议——那玩意儿在 Spring Cloud Gateway 或主流 Java 网关里压根没原生支持，也缺乏生产级维护。真正在用的、可落地的方案，是「手动解析 + 异步聚合 + 结构化组装」，核心在于控制好执行时序、错误隔离和字段映射边界。
为什么不能直接用 ESI 标签做网关响应拼接
ESI 是 CDN 边缘节点（如 Akamai、Cloudflare）或 Nginx 的模块功能，依赖服务端模板解析引擎（如 Varnish ESI processor），而 Spring Cloud Gateway / WebFlux 是纯响应式 HTTP 代理，不解析 HTML/SSI/ESI 模板。你往 response.body 里写 <include src="/user"></include>，网关只会原样透传，下游浏览器或 CDN 不接管时，它就是一段无意义字符串。
常见错误现象：WebClient 调用后把含 ESI 标签的 JSON 当作合法响应返回，前端解析失败；或误以为加个 Nginx esi on 就能自动渲染，结果因网关未剥离/转义标签导致 XSS 风险。
Spring Cloud Gateway 中真正可行的动态合并流程
必须绕过“模板替换”思维，转向“数据流编排”：网关接收请求 → 并行调用多个服务 → 分别校验状态码与 JSON 结构 → 映射为统一字段 → 合并进顶层 Map<string object></string> 或 DTO → 序列化返回。
- 每个子请求必须单独设
timeout（如WebClient的client.timeout(Duration.ofMillis(800))），避免一个慢接口拖垮整体 - 不用
Mono.zip直接合并原始ResponseEntity，而要先用flatMap提取body并捕获异常，否则某个 5xx 响应会让整个zip流中断 - 字段映射必须白名单驱动，比如配置
{"user": "data", "order": "order_info"}，而不是靠if (json.has("data"))动态猜结构 - 空响应、
401、503等非 2xx 状态需统一转成占位对象（如{"user": null, "error": "unauthorized"}），不能直接抛异常丢弃整条链路
PHP 网关中用 curl_multi_exec 实现等效合并的关键细节
PHP 场景下没有响应式流，但 curl_multi_exec 是最可控的并发基座。它的“动态合并”能力取决于你怎么处理完成事件，而不是是否支持 ESI。
- 必须循环调用
curl_multi_exec($mh, $running)直到返回CURLM_OK，只调一次大概率拿不到全部响应 - 每个
$ch完成后，必须立刻用curl_multi_info_read($mh)拿到完成句柄，再调curl_getinfo($ch, CURLINFO_HTTP_CODE)和curl_multi_getcontent($ch)—— 顺序错就可能读到 0 状态码或空 body - 对每个响应做
json_last_error() === JSON_ERROR_NONE校验，失败则跳过该字段，不要die()或throw - 大响应体（>3MB）需提前用
curl_setopt($ch, CURLOPT_BUFFERSIZE, 65536)控制内存占用，否则 PHP 进程可能 OOM
容易被忽略的合并边界问题
动态合并不是技术实现问题，而是契约管理问题。最常翻车的地方不在代码，而在配置和协作：
微服务返回的字段名冲突（比如两个服务都叫 id，但类型一个是 String 一个是 Long），网关不做类型归一化，前端 JSON.parse 会静默失败；Content-Type 不一致（有的返回 application/json;charset=UTF-8，有的是 text/plain），网关若直接拼 raw body，会导致最终响应无法被正确识别；还有更隐蔽的：某个服务升级后新增了 trace_id 字段，网关白名单没更新，该字段就被丢弃，排查时才发现日志链路断了。
