鼠标调用等前端交互事件不属于分布式链路追踪范围，因其发生在单端且无跨服务调用；应归入前端监控，通过 traceid 透传实现端到端关联。
鼠标调用或系统触发的埋点块不属于分布式链路追踪的适用范围。
链路追踪（Tracing）面向的是**服务间请求调用**，核心对象是跨进程、跨网络的 RPC、HTTP、MQ 等通信行为。它依赖 Span 记录服务处理单元的起止时间、上下文传播（traceId/spanId）、错误标记等，本质是“请求生命周期”的可观测。
而鼠标点击、按钮触发、页面滚动、定时器回调等，属于**前端用户交互或客户端内部事件**，发生在单端（浏览器或 App 进程内），不构成服务调用链路。这类行为应归入前端监控范畴，比如通过前端 SDK 上报 PV/UV、点击热图、JS 错误、API 请求耗时等，再与后端 Trace ID 关联（如通过 `X-B3-TraceId` 透传），实现“端到端”而非“端内链路”追踪。
为什么注解+反射无法精准捕获鼠标调用
原因很直接：
- 运行环境不匹配：Java 注解和反射作用于 JVM 内部方法调用，而鼠标事件由浏览器渲染引擎（V8/Blink）或操作系统事件循环触发，根本不在 Java 字节码执行路径上；
- 无调用栈可注入：`@Trace` 类注解只能织入 Spring Controller 方法、FeignClient 接口、Dubbo Service 实现等有明确入口的方法，但 onclick 回调是 JS 函数，Java 层完全不可见；
- 无 Span 语义：一次 click 不代表一个服务跨度（Span），它可能触发零个、一个或多个后端请求——真正需要追踪的是后续发起的 HTTP 请求，不是 click 动作本身。
如果真想关联前端交互与后端链路，该怎么做
关键是把前端行为作为「起点」，生成并透传 traceId，而不是试图在 Java 层“捕获 click”：
- 前端在用户首次交互（如页面加载完成或第一次点击）时生成唯一 traceId，并存入内存或 localStorage；
- 所有后续发出的 AJAX/Fetch 请求，都在 headers 中带上
X-B3-TraceId和X-B3-SpanId； - 后端探针（如自研 SDK）识别这些 header，复用或延续该 traceId 创建首个 Span，使整条链路从“用户点击那一刻”开始可追溯；
- 可在日志中记录交互类型（如
event:click, target:#submitBtn），作为 Span 的 tag，供查询时筛选。
系统级触发（如定时任务、消息监听）可以埋点，但方式不同
这类属于 JVM 内可控入口，适合用注解增强：
- 对 @Scheduled 方法、@RabbitListener、@KafkaListener 等声明式入口，编写自定义 AOP 切面或 Spring Advice，在方法执行前后创建 Span；
- 注解如
@TraceJob("order-cleanup")可提取业务标识，作为 Span 名称和 tag； - 反射仅用于读取注解元数据，实际 Span 生命周期管理仍需靠 ThreadLocal + MDC + 异步上报机制保障上下文不丢失。
把精力放在服务调用链路上，才是链路追踪插件该解决的问题。前端交互监控请交给专门的 RUM（Real User Monitoring）工具，两者通过 traceId 对齐即可。
