Hyperf 中需在构造函数首行用 debug_backtrace(DEBUG_BACKTRACE_PROVIDE_OBJECT, 20) 获取调用方，过滤 HyperfDi* 和 HyperfContainer* 帧后取首个非容器帧的 class 与 function 字段，不可在普通方法中调用，因注入仅发生在实例化阶段。
Hyperf 中如何用 debug_backtrace 拿到依赖注入时的调用方类名和方法
Hyperf 默认不暴露容器解析链路中的“谁在请求这个类”，但实际开发中常需判断：是 UserService 构造函数里 new 的？还是 OrderController 的 action 里通过 $container->get() 主动获取的？debug_backtrace() 是目前最直接、最低侵入的手段，但要注意调用时机和过滤层级。
关键点在于：必须在类的构造函数或 __invoke 方法中执行回溯，且要跳过 Hyperf 容器内部的调用帧（如 Container::resolve()、Definition::resolve()）。
- 推荐在构造函数第一行调用，此时对象尚未完全初始化，但调用栈最干净
- 过滤掉
HyperfDi*和HyperfContainer*相关的帧，保留最近一个非容器代码的class+function - 不要用
DEBUG_BACKTRACE_IGNORE_ARGS，否则拿不到class字段（Hyperf 3.x+ 默认不返回 class 信息）
// 在被注入的类中
public function __construct()
{
$backtrace = debug_backtrace(DEBUG_BACKTRACE_PROVIDE_OBJECT, 20);
$caller = null;
foreach ($backtrace as $frame) {
if (!isset($frame['class']) || strpos($frame['class'], 'Hyperf\Di\') === 0 || strpos($frame['class'], 'Hyperf\Container\') === 0) {
continue;
}
$caller = $frame;
break;
}
var_dump($caller['class'] ?? 'unknown', $caller['function'] ?? 'unknown');
}
为什么不能在 __construct 外部（比如普通方法）获取调用者
因为依赖注入只发生在实例化阶段，一旦对象创建完成，后续任何方法调用都属于业务逻辑调用栈，和“谁注入了我”已无关系。此时 debug_backtrace 返回的是当前方法的上层调用者，不是容器解析者。
- 例如：在
SomeService::handle()里调用debug_backtrace，拿到的是调用handle()的控制器方法，而非当初SomeService被注入进该控制器时的上下文 - 若真需要运行时动态追溯注入源头，只能把调用信息提前存到属性里（比如构造时存
$this->injector = $caller），不能临时查 - Hyperf 的 AOP 切面也不适用于此场景——切面作用于方法执行，而注入行为本身不可被切
debug_backtrace 在协程环境下的稳定性风险
Hyperf 运行在 Swoole 协程中，debug_backtrace 本身是 PHP 内置函数，协程安全，但有两点易被忽略：
- 高并发下频繁调用会显著拖慢构造速度，尤其当
backtrace深度大（如框架中间件嵌套多）时，建议仅调试期开启，生产环境禁用 - 某些 Swoole 版本（如 4.8.12 之前）在极短生命周期对象中，
debug_backtrace可能返回空数组或截断帧，可加兜底：if (empty($backtrace)) { throw new RuntimeException('Backtrace empty, maybe in coroutine cleanup phase'); } - 别依赖
file或line字段做逻辑分支——这些值在 opcache 开启、代码混淆或 phar 包中可能失真
替代方案：用容器事件监听比手动回溯更可靠
如果目标是统一审计或记录“哪些类被谁注入”，debug_backtrace 是临时手段；长期应改用 Hyperf 提供的容器事件机制，更轻量、可控、无性能抖动。
- 监听
HyperfContractOnContainerEventInterface实现类，订阅HyperfDiEventAfterResolving - 事件对象自带
$event->getName()（被解析的类名）和$event->getObject()（实例），但不直接提供调用者——需配合Coroutine::getContext()+ 自定义上下文传递（如在 Controller 构造前写入Co::setContext(['injector' => static::class])） - 注意：事件监听无法区分“构造注入”和“setter 注入”，若需精确区分，仍得回到构造函数 + 回溯的组合方式
真正难的不是拿到调用者，而是确认那个“调用者”是否还持有有效上下文——比如协程已结束、对象被销毁、或调用栈已被 GC 清理。这时候回溯结果只是历史快照，不能当作运行时依据。
