Composer本身不采集Span数据，它仅是依赖管理工具；真正实现链路追踪的是通过composer require引入的SDK（如jukylin/jaeger-php或open-telemetry/opentelemetry-auto-http-async），其Span上报依赖显式初始化、正确上下文传播、准确endpoint配置及FPM下实例隔离，任一环节缺失均导致链路断裂。
Composer 镜像本身不采集 Span 数据，它只是 PHP 依赖管理工具；真正负责链路追踪的是你通过 composer require 引入的追踪 SDK（比如 jukylin/jaeger-php 或 open-telemetry/opentelemetry-auto-http-async），而这些 SDK 的行为取决于你如何配置、初始化和使用它们。
composer require 后为什么没看到 Span 上报？
常见现象是执行了 composer require jukylin/jaeger-php 或 composer require opentracing/opentracing，但 Jaeger UI 里始终为空。这不是 Composer 的问题，而是 SDK 没被激活或上报路径不通。
-
composer require只负责把代码下载到vendor/，不会自动注册全局 Tracer 或启动 reporter - 必须显式调用初始化逻辑，例如
$tracer = $config->initTracer(...)，且该对象需在请求生命周期中被实际使用 - Jaeger Agent 地址写错（如误用
127.0.0.1:6831而容器内实际是jaeger:6831）会导致 UDP 包静默丢弃，无错误提示 - PHP-FPM 环境下，Tracer 实例若未绑定到请求上下文（如放在 global scope 但未重用），可能被复用或泄漏，导致 Span 丢失
open-telemetry/opentelemetry-auto-http-async 的自动埋点生效条件
这个包专为 HTTPlug 兼容的异步 HTTP 客户端设计，不是“装上就自动追踪所有网络请求”。它只对明确使用了 HTTPlug 接口的客户端生效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须确保你用的是支持 HTTPlug 的客户端，例如
php-http/guzzle7-adapter或php-http/curl-client，而不是直接 new GuzzleHttp\Client() - 初始化时需调用
OpenTelemetry::registerGlobalTracer()，否则TracerProvider不会注入到 HTTPlug 的中间件链中 - Span 的 parent-child 关系依赖上下文传播：若上游未注入
traceparentheader，下游 Span 就会变成孤立根 Span，链路断裂 - 默认 reporter 是
OTLPExporter，需额外配置 endpoint（如http://otel-collector:4318/v1/traces），不兼容 Jaeger 的 Thrift/UDP 协议
PHP-FPM 场景下 Span 生命周期管理的关键点
FPM worker 进程复用会导致 Tracer 和 Span 实例跨请求污染，这是 Span 数据错乱或漏报的高发原因。
- 不要在
index.php顶层 new Tracer 并存为全局变量——它会在多个请求间共享状态 - 推荐在每次请求入口（如框架 middleware 或 bootstrap）中创建新
Tracer实例，或使用GlobalTracer::get()+ 自定义TracerProvider控制作用域 - Span 必须显式调用
$span->finish()，PHP 的析构函数不可靠，尤其在异常中断或 fastcgi_finish_request() 后 - 日志、DB 查询、Redis 调用等关键节点需手动 startSpan，仅靠自动埋点覆盖不了业务逻辑层
Span 数据链是否完整，不取决于 Composer 镜像源是否加速，而取决于你有没有让 SDK 在正确的时机、以正确的上下文、往正确的 endpoint 发出正确的数据。最常被忽略的是跨服务 header 透传和 FPM 下的实例隔离——这两点出问题，整个链路就断在第一跳。
