composer 不支持分布式链路拓扑自动发现，它仅负责依赖安装与类加载，不感知服务调用关系；链路发现需编译期元数据注入、运行时埋点采集与中心化聚合渲染三层协作完成。
Composer 本身不支持分布式链路拓扑自动发现——它只管依赖安装和类加载，不感知服务调用关系、HTTP请求路径或RPC链路。所谓“基于 Composer 构建”，实际是借其包管理能力做**元数据分发 + 静态配置注入**，再配合运行时探针完成拓扑构建。真正在做链路发现的，是你的 SDK、中间件或 APM 工具，不是 composer。
为什么不能靠 composer install 自动画出调用图
因为 composer install 不分析代码行为：它不知道 UserService::create() 内部是否调用了 NotificationService::send()，也不解析 curl 或 gRPC 调用目标。它只把包下载到 vendor/，并按 autoload 规则生成类映射。
-
installed.php只记录“哪些包装了”，不记录“哪些类被谁调用” - 所有
extra.*字段（如extra.laravel.providers）都是静态声明，无法表达动态依赖关系 - 即使你用插件在
POST_AUTOLOAD_DUMP事件里扫描所有vendor/*/src/**/*.php，也只能提取函数名、类名、命名空间，无法还原调用栈
真正可行的链路发现三步法
要让 PHP 项目具备“分布式链路拓扑自动发现”能力，必须分层协作：
-
编译期注入元数据：在每个微服务包的
composer.json中声明其暴露的接口、依赖的下游服务（例如"extra": {"service": {"provides": ["user.v1"], "depends_on": ["auth.v1", "notify.v1"]}}），然后通过自定义插件读取这些字段，生成统一的services.yaml并写入config/目录 - 运行时埋点采集：每个服务启动时加载 SDK（如 OpenTelemetry PHP），在 HTTP client、DB connector、RPC stub 等关键位置打点，上报 span 数据到 collector
-
中心化聚合渲染：后端服务从
services.yaml读取服务注册信息，再关联 span 数据中的peer.service和http.url，拼出调用边，最终输出 JSON 或 Graphviz 格式的拓扑图
最容易踩坑的两个配置点
很多团队卡在第一步就失败，问题不在代码，而在 composer.json 的写法细节：
-
"type": "library"必须显式声明 —— 如果是"type": "project"或空值，自定义插件默认跳过该包（Composer2.9.6 默认过滤非库类型） -
extra.service.depends_on的值必须是字符串数组，且每个元素需与下游服务的extra.service.provides完全一致（含版本号，如"auth.v1"≠"auth.v2"），否则拓扑连线会断开 - 插件中读取
$package->getExtra()前，必须先调用$package->getType() === 'library'过滤，否则会把laravel/framework这类框架包也误当业务服务处理
不要试图用 dump-autoload 触发链路发现
composer dump-autoload 只改类加载逻辑，对链路无任何影响。常见错误是以为加个 post-autoload-dump 脚本就能“扫描所有 service 类并注册为节点”，但这样只能列出类名，无法区分它是提供方、消费方还是纯工具类。真正的拓扑依赖调用行为，必须在请求生命周期内捕获。
如果你的链路图始终只有孤点没有连线，先检查 SDK 是否启用了 http_client 和 grpc 的自动 instrumentation，再确认 collector 是否收到了带 parent_id 的嵌套 span —— 这些和 composer 无关，但常被误认为是“自动发现没生效”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
