流内聚属性支持零侵入TraceID注入：在连接初始化时一次性绑定TraceID至上下文，HTTP/2、gRPC、WebSocket、SSE等流场景均可复用，业务代码无需修改，日志自动携带trace_id字段。

在高并发流式场景（如 HTTP/2 Server Push、gRPC Streaming、SSE、WebSocket 或 MCP 双向流）中，“流内聚属性”指的是：同一逻辑请求生命周期内，所有帧/消息天然共享一个连接上下文和时序边界。这个特性可被安全利用，实现 TraceID 注入——无需修改业务逻辑、不污染函数签名、也不依赖 request() 或全局变量。

利用连接级上下文绑定 TraceID

流式通信建立后，底层连接（TCP 连接、HTTP/2 stream ID、gRPC call 对象）是稳定且独占的。可在连接初始化阶段注入 TraceID，并在整个流生命周期内复用：

• HTTP/2 或 gRPC：在 Handler 入口解析 X-Trace-ID 或 traceparent header，生成或透传 traceId，并绑定到 context.Context（Go）或 RequestAttributes（PHP/Laravel）中
• WebSocket：在 onOpen() 时从握手请求 header 提取 TraceID，存入 Session 或 ConnectionContext
• SSE：首次 EventSource 请求带 header，服务端将 traceId 绑定到该 ResponseWriter 的生命周期

关键点：绑定动作只做一次，后续所有帧处理都自动继承该上下文，无需每帧重复解析。

在流处理器中自动透传，不侵入业务代码

使用中间件或拦截器模式，在框架层统一完成 TraceID 的提取、传播与日志关联：

• Go net/http：写 StreamTracingMiddleware，包装 handler，把 traceId 注入 r.Context()，再透传给 http.Flusher 和 io.Writer
• Laravel：自定义 StreamingResponse 类，构造时接收 $traceId，内部用 Log::withContext() 初始化 logger，所有 echo/write() 调用自动携带该上下文
• Java Spring WebFlux：用 WebFilter 提取 header → 存入 ReactorContext → 通过 Mono.subscriberContext() 在 flatMap/doOnNext 中自动获取

这样，业务代码只需专注流数据处理（如 sink.next(data)），TraceID 已由框架隐式携带。

避免常见破坏性做法

• ❌ 不在每个 onMessage() 回调里手动 Log::channel()->withContext(...)->info() —— 重复、易漏、破坏流语义
• ❌ 不用 static $traceId 或 global 变量跨 goroutine/协程共享 —— 并发下必然错乱
• ❌ 不在流内动态拼接 header 或重写 response 对象 —— 违反流协议帧结构，可能中断连接

正确方式是：把 TraceID 当作流的元数据（metadata），而非业务载荷（payload）。例如：

• gRPC：用 metadata.MD 附加 trace-id: xxx，客户端和服务端均通过 grpc.Peer() 或 metadata.FromIncomingCtx() 获取
• MCP 协议：原生支持 x-mcp-trace-id 帧头，SDK 自动注入，无需业务感知

日志与链路平台对齐的关键细节

• 所有日志必须输出到同一 channel（如 stack 或 cloudwatch），且格式统一为 JSON，含 "trace_id": "xxx" 字段
• 若对接 Jaeger/OTLP，确保 trace_id 字段名与采集器期望一致（如 traceId vs trace_id vs X-B3-TraceId）
• 不要依赖 Monolog 的 extra 字段“猜测”上下文；应通过 tap 处理器强制写入 $record['trace_id'] = $context['trace_id'] ?? null

本质上，流内聚性提供了天然的“作用域边界”，比传统 HTTP 请求更清晰。只要在边界入口一次性注入，就能全程保真，真正实现零侵入。