从前端注入到网关日志：聊聊全链路 Trace ID 贯穿的取舍与避坑

最近在重构链路追踪，聊聊前后端打通 Trace ID 的一些取舍。

很多人第一反应是在前端 Axios 拦截器里随手生成一个 UUID 塞进 Header，比如 X-Trace-Id，后端和网关一路往下透传，最后打入日志和 APM。逻辑很直观，但在实际落地时，往往会遇到两个比较典型的权衡点：

1. 链路完整性 vs 网络开销 如果由前端生成并注入自定义 Header，跨域场景下大部分请求都会触发一次 OPTIONS 预检请求，对高频或弱网环境的接口性能损耗很明显。但如果只让网关生成，后端链路是闭合了，前端的用户点击、重试行为、以及首屏报错却没办法和接口无缝串联。

2. 自定 Header vs 标准规范 是用野路子的 X-Trace-Id，还是老老实实走 W3C 的 traceparent（Trace Context）。走标准协议对接入 OpenTelemetry 极度友好，但前端自己维护 traceparent 格式的复杂度会上升，后端网关防伪造和校验的逻辑也得多写几行。

我们目前的折中方案是：常规业务读请求由网关兜底生成，关键写操作或需要客户端监控埋点的场景才由前端注入，同时在网关层做格式校验和防刷截断。

大家目前是倾向于「前端全量注入」还是「网关统一收口生成」？针对 OPTIONS 预检和前端日志（比如 Sentry）串联，你们是怎么做权衡的？