服务端已经写出 Trailer: X-Checksum，请求也拿到了 200，接下来该从哪里取校验值？Node 的 fetch() 能读到 Trailer 这个声明，却读不到真正的尾部字段。换成 node:http，等响应结束后，值就在 res.trailers 里。相同服务、相同响应，两套客户端接口给出的信息并不一样。
正文之后还有一段头
HTTP trailers 是放在消息正文之后的字段。它们不在初始响应头里；服务端先发送正文，结束时才发送尾部字段。分块传输常见于这种场景，字段可以携带需要等到正文生成完才知道的信息，比如摘要值。它们不是第二次响应，也不会另起一个状态码。
响应初始头需要用 Trailer 声明后续可能出现的字段名。光写声明不等于已经发了值：Trailer: X-Checksum 说明后面可能有 X-Checksum，真正的值要在消息末尾交付。客户端若只检查初始头，会看到承诺的字段名，却还没有字段值。
Node 两套客户端读到的不同
本机脚本用 Node v26.8.1 起了一个只绑定 127.0.0.1 的服务。服务写出 payload 后，以 addTrailers() 附上 X-Checksum: sha256-demo。同一地址分别由 node:http 和内置 fetch() 请求，比较声明头与尾部字段的可见性；端口由系统临时分配，没有外部网络参与。
原始日志保存在 tools/verify-fullstack-response-trailers.log，可用 ~/.hermes/node/bin/node tools/verify-fullstack-response-trailers.mjs 重跑。脚本对两种客户端的关键字段都做了断言，完整输出如下：
runtime: v26.8.1
server: 127.0.0.1 (ephemeral port)
node http: status=200, body=payload
node http headers: trailer=X-Checksum
node http trailers: {"x-checksum":"sha256-demo"}
fetch: status=200, body=payload
fetch headers: trailer=X-Checksum, x-checksum=null
fetch trailers property: undefined
assertion: PASS (Node http exposes the completed trailer; fetch does not)
两种客户端都拿到同样的 200 和 payload。node:http 在响应结束事件后给出 res.trailers，字段名被规范为小写；fetch() 的 Headers 仍包含 Trailer 声明，但没有 x-checksum，响应对象也没有 trailers 属性。不能因为声明头存在，就假定业务字段也能通过 response.headers.get() 取得。
这组输出只说明 Node v26.8.1 里这两种 API 的行为。它不是浏览器兼容性测试，也没有经过代理、CDN 或 HTTP/2；不同客户端是否保留尾部字段需要各自验证。若接口的完整性依赖客户端读取摘要，不应只凭服务端发送成功来认定校验已经发生。
校验逻辑要落在能读到它的客户端
若客户端必须读取 trailer，可选用明确提供尾部字段访问能力的 HTTP 客户端，并等正文完整结束后再校验。校验失败时，正文即使已经下载完，也不能当作可信结果交给后续逻辑。把校验挪到首部阶段则不成立，因为摘要值可能直到所有字节生成后才可计算。
另一种做法是将摘要放进普通响应头，但前提是服务端在发送响应头前已经知道摘要。动态流通常不满足这个条件；为了预先计算而缓存整份正文，会增加内存占用，也会推迟首字节到达；原本逐段处理的流也得改成整块处理。对已经由客户端支持的摘要方案，也应先确认它覆盖的是预期字节表示，而不是把自定义 trailer 当成通用替代。
还有个边界容易混淆：Trailer 是声明，X-Checksum 才是本次响应的字段值。声明可以帮助解析器准备接收，却不能让不暴露 trailers 的 API 突然多出读取能力。我会把客户端能力作为接口选型条件写明，不会让调用方盲目切换到低层 API，只为拿一个当前代码并未使用的字段。
服务端与客户端都由自己控制、且客户端确实需要事后生成的元数据时，trailers 才值得考虑。若浏览器端只使用标准 fetch()，这次实测的 Node 行为不能替浏览器背书；应选择可通过初始响应头或正文协议传递的方案，并在目标运行时验证。
