otlpspanexporter 初始化失败会静默阻塞而非报错，因网络不通、grpc未链接或endpoint格式错误（如缺”http://”）导致后续startspan无响应；需确保链接grpc++、正确配置endpoint及宏定义。
为什么 OTLPSpanExporter 初始化失败就卡住？
OpenTelemetry C++ SDK 默认不启用任何导出器，OTLPSpanExporter 构造时若网络不通、gRPC 未链接或 endpoint 配置错，会静默失败或阻塞在初始化阶段——不是报错，而是后续 Tracer::StartSpan 完全没反应。
- 确保已链接
opentelemetry-proto和grpc++（不是grpc），CMake 中要显式find_package(gRPC REQUIRED) -
endpoint必须带协议和端口，比如"http://localhost:4317"（gRPC）或"http://localhost:4318"（HTTP/json），漏掉http://会导致解析失败但无提示 - 调试时加一行
auto exporter = std::static_pointer_cast<:exporter::otlp::otlphttpexporter>(...);</:exporter::otlp::otlphttpexporter>看是否为空指针，比等超时更早发现问题
gRPC vs HTTP/JSON 导出：选哪个？
OpenTelemetry C++ SDK 当前（v1.14）对 OTLP 的支持分两条路径：OtlpGrpcExporter（默认）和 OtlpHttpExporter（需额外定义 ENABLE_OTLP_HTTP_EXPORTER）。它们不是配置开关，是两套独立实现。
- 用 gRPC：必须启用
ENABLE_GRPC宏，链接grpc++，endpoint 写成"http://localhost:4317"（注意：gRPC endpoint 仍用http://前缀，SDK 内部识别端口自动走 gRPC） - 用 HTTP/JSON：编译时加
-DENABLE_OTLP_HTTP_EXPORTER=ON，且不能同时开 gRPC；endpoint 改为"http://localhost:4318/v1/traces"，否则 404 - 性能上 gRPC 更稳，但开发机没装 grpc 库时，HTTP/JSON 更易验证通路——先跑通再切 gRPC
TracerProvider 生命周期搞错，追踪就丢了
C++ SDK 要求 TracerProvider 实例的生命周期必须长于所有 Tracer 和 span 操作。局部变量、提前释放、或被 shared_ptr 自动析构，都会导致后续 span 被静默丢弃。
- 全局或静态持有
std::shared_ptr<:trace::tracerprovider> provider</:trace::tracerprovider>，别放在函数栈里 - 调用
opentelemetry::trace::Provider::SetTracerProvider(provider)后，不能再让provider被析构——哪怕只是 shared_ptr 计数归零 - 如果用 RAII 封装，务必确认析构顺序：provider 必须最后释放，晚于所有 tracer、span、甚至 logger
本地验证 OTLP 导出是否真发出？
别只看程序不崩溃，得确认数据真的发出去了。最直接办法是用 otelcol 搭个接收端，配合 curl 或 tcpdump 抓包看有没有 payload。
立即学习“C++免费学习笔记（深入）”；
- 启动轻量 collector：
otelcol --config=otel-local.yaml，其中otlp:下开endpoint: 0.0.0.0:4317并配Logging:输出到控制台 - 代码里加一句
provider->ForceFlush(std::chrono::milliseconds(500));主动刷一次，避免依赖后台线程延迟 - 抓包命令：
tcpdump -i lo port 4317 -A -s 0 2>/dev/NULL | grep -E "(traceId|spanId|name)"，看到二进制 protobuf 解码后的字段才真正可信
最容易被忽略的是 ForceFlush 的调用时机——它不阻塞，但返回 future，不 wait 就可能 flush 还没开始进程就退出了。