问APM 尾部采样后错误链路延迟十分钟，客户端采样该如何取舍？

场景：按量付费的应用性能监控。TKE 上 order-api 为 Java 17，用腾讯云增强版 OpenTelemetry Java 探针；bff 为 Go 社区 SDK，OTEL_TRACES_SAMPLER=parentbased_traceidratio，OTEL_TRACES_SAMPLER_ARG=0.01。服务端采样从 100% 改为 10%，已开「保存错误链路」，慢调用阈值 2000 ms。支付回调只在 order-api 配全采样，前缀 /pay/callback。

现象：

1. order-api 的错误率没有掉成一成。促销报错后前几分钟搜不到错误 Span，大约 10 分钟后才成批出现。
2. bff 的 APM 错误率大约只有访问日志的 1%，同一条 trace id 经常整段没有。下游超时后仍回 HTTP 200，body 里 code=50001，错误分析看不到。

已尝试：

1. 采样率改回 100% 后，order-api 新错误链路马上能搜到，存储量回到改前。阈值改成 500 ms 后，200 ms 返回的业务错误码仍没有。
2. bff 改为 always_on 并重启后，入口 Span 与访问日志对齐，上报费用上升。只改服务端采样、未重启 Java，order-api 新策略已生效。

问题：

1. 错误率图表当时是齐的，错误 Span 为何要等约 10 分钟？这 10 分钟排障该靠什么？全采样接口是否同样延迟？
2. 客户端 1% 头采样和服务端 10% 尾部采样叠加后，缺的入口 Span 是没上报还是没存？只改服务端采样率能否补回？尾部采样会不会降低上报费用？
3. HTTP 200 但 body 是业务错误码时，怎样按错误留下整条链路，又不把促销主接口配成全采样？这三项改完要不要重启？