适合对象：想理解运行时采集链路内部协作方式的测试工程师、研发工程师、平台工程师。
一、为什么要把采集链路拆开讲
很多人第一次看精准测试平台，会把“采集”理解成一个单点动作，好像探针一挂上去，数据就自然出来了。
实际上不是这样。
真正稳定的运行时采集，至少要同时解决三件事：
- 在什么位置拦截方法执行；
- 怎样把一次请求中的调用过程串起来；
- 怎样把本次请求实际命中的代码路径变成覆盖率结果。
这三件事分别对应三个层面：
- 方法采集；
- 调用上下文；
- 覆盖率探针。
只有这三层协同起来，平台才能回答这些问题：
- 哪个入口方法触发了一次完整调用；
- 这次调用经过了哪些业务节点；
- 最终命中了哪些类、哪些方法、哪些代码片段。
二、采集链路的核心角色
从职责划分看，这条链路里通常有四类关键角色：
- 采集器：负责拦截目标类和目标方法；
- 上下文管理器：负责维护当前请求的跟踪状态；
- 覆盖率收集器：负责在请求级别聚合本次命中的探针结果；
- 节点构建器：负责把采集结果整理成结构化节点，交给后续存储或展示层。
图 1：采集链路总体协作图
三、方法采集器负责什么
方法采集器是整条链路里最靠前的一层。
它的职责不是保存数据，而是决定：
- 哪些类需要被增强；
- 哪些方法需要被插桩；
- 方法开始时执行什么逻辑；
- 方法结束或异常时执行什么逻辑。
一个常见设计是：
- 先通过包名、类名、方法名规则过滤目标类；
- 对符合条件的方法插入
begin逻辑； - 在正常返回路径插入
end逻辑； - 在异常分支插入
error逻辑。
这种模式的价值在于，采集器不需要理解业务语义，只负责稳定地把“方法执行事件”暴露给后续链路。
图 2：方法采集器工作方式
四、调用上下文为什么是这条链路的中枢
如果只有方法拦截，没有上下文，系统最多只能知道“某个方法被执行过”，却无法知道这些方法是否属于同一次请求。
调用上下文要解决的，就是把离散的执行点组织成一条可追踪的链路。
它通常承担这些职责：
- 为一次请求生成唯一标识；
- 在当前线程中保存活动会话；
- 为链路中的每个节点分配递增节点编号；
- 维护会话生命周期；
- 在必要时处理心跳、登录、配置和上报服务初始化。
从工程上看，这一层往往是最重的一层，因为它既要管理采集状态，又要承担和外部服务之间的连接职责。
图 3：调用上下文在链路中的位置
五、一次方法开始时，链路里发生了什么
当采集器拦截到目标方法入口时，典型流程是这样的：
- 检查当前线程是否已有活动会话；
- 如果没有，就创建一个新的请求级会话；
- 生成当前节点编号；
- 创建方法节点对象；
- 如果开启了覆盖率采集，就启动本次请求的覆盖率收集器。
这样做的意义是：
- 首个入口方法负责打开一整条链路；
- 后续嵌套方法只需要继续挂在这条链路下；
- 覆盖率收集器只关心“本次请求触达了哪些探针”，不必感知更高层业务。
图 4：方法开始阶段的处理
六、覆盖率收集器解决了什么问题
覆盖率收集器的核心思想不是“每执行一个方法就立刻生成一份覆盖率报告”，而是“以请求为单位，在结束时做一次快照聚合”。
这是一种更稳妥的方式，因为它避免了两个问题：
- 每个方法都即时统计，会带来很高的运行时开销；
- 嵌套调用很多时，很难判断哪些探针属于同一次业务请求。
因此，一个常见设计是：
- 请求开始时，创建线程绑定的覆盖率收集器；
- 请求执行过程中，全局探针持续被触发；
- 请求结束时，收集器统一从探针注册表中读取快照；
- 只保留本次真正被命中的类和探针结果。
图 5：请求级覆盖率收集思路
七、为什么覆盖率要和方法节点一起收口
如果调用链和覆盖率各自独立保存，后面做分析时会很麻烦。
更合理的方式是：
- 方法节点负责描述“发生了什么调用”；
- 覆盖率快照负责描述“命中了什么代码”；
- 在方法结束时，把两者绑定起来。
这样一来，后续无论是做快照回放、覆盖率详情，还是做差异分析，都能沿着统一的节点结构继续向下走。
在当前实现思路里，方法结束时会做几件关键事：
- 记录结束时间和耗时；
- 判断本次节点是否成功或失败；
- 结束覆盖率收集；
- 把探针快照转成代码节点结构；
- 把完整节点保存到会话中。
图 6：方法结束时的数据收口
八、异常分支为什么也要单独处理
真实业务里，失败路径和成功路径同样重要。
如果异常路径不被采集，平台只能看到“正常场景覆盖了什么”，却无法回答：
- 异常分支是否触发了关键逻辑；
- 某个失败请求到底在哪个节点报错；
- 错误发生前已经命中了哪些代码。
所以采集链路通常会在异常分支里补一层处理：
- 记录异常信息；
- 标记当前节点为失败；
- 保证链路仍然能够完整收口；
- 尽量不要因为采集逻辑本身再次放大异常影响。
九、这套协同机制为什么适合精准测试
精准测试关心的不是单纯的数字，而是“场景、链路、代码”之间的对应关系。
这一套协同机制恰好把三件事情连起来了：
- 方法采集器负责抓到业务入口和业务过程；
- 调用上下文负责把一次请求串成完整链路；
- 覆盖率收集器负责把本次请求命中的代码提取出来。
于是平台就能从“这个请求执行过”进一步升级为：
- 这个请求经过了哪些节点；
- 这些节点分别命中了哪些代码；
- 哪些场景真正覆盖了这次变更的核心逻辑。
十、本篇小结
这一层链路可以概括成一句话：先用采集器抓住方法执行，再用调用上下文把节点串起来，最后用覆盖率收集器在请求结束时统一收口。
如果只看职责分工：
- 采集器负责“拦住方法”；
- 上下文负责“串起链路”；
- 覆盖率收集器负责“还原本次请求命中的代码”。
下一篇会继续往后走，进入数据出站阶段：采集结果是如何被封装、传输并交给服务端的。
