LoadRunner里所谓动态Token，核心不是把值改成参数这么简单，而是先找到它出现在哪一次响应里，再决定用边界、正则还是JSON方式去提取。VuGen官方文档把这条线说得很清楚，Design Studio里的【Correlation】页可以先扫描脚本里的动态值，再按定义应用关联；而真正落到代码里，常见提取函数主要就是基于边界的`web_reg_save_param_ex`、基于正则的`web_reg_save_param_regexp`和基于JSONPath的`web_reg_save_param_json`。

　　一、LoadRunner怎么处理动态Token

　　处理动态Token时，不要一上来就手写函数。更稳的顺序，是先扫描，再确认来源，再决定提取方式，这样后面返工会少很多。VuGen官方说明里，Design Studio的【Correlation】页本来就是按这个流程设计的。

　　1、先用【Design Studio】【Correlation】扫描动态值

　　官方文档说明，这个页签可以扫描、关联并查看脚本里的动态值，扫描来源还分成rule、record、replay和manual几类。先把候选Token扫出来，再决定怎么抓，会比手动全脚本翻值更快。

　　2、先确认Token出现在“前一个响应”还是“下一次请求体”里

　　`web_reg_save_param_ex`、`web_reg_save_param_regexp`和`web_reg_save_param_json`都是注册到“下一条action function”去抓值的，官方还特别说明，这类搜索不适用于异步下载或跨步骤返回的数据。所以你如果把提取语句放错位置，常见结果就是脚本能回放，但参数一直抓不到。

　　3、文本规则清楚时优先用边界提取

　　如果Token左右两边的文本很稳定，优先用`web_reg_save_param_ex`。官方说明里写得很直接，它就是抓左右边界之间的内容，而且保存的是边界内部、不含边界本身的值。对sessionId、csrfToken、隐藏域value这类典型Token，这种方式通常最直观。

　　4、结构不稳定时改用正则或JSON

　　如果左右边界会变，或者Token在JSON里、字段层级又很清楚，就不要硬写边界。官方说明中，正则提取用`web_reg_save_param_regexp`，支持捕获组；JSON提取用`web_reg_save_param_json`，按QueryString也就是JSONPath取节点。规则选对以后，脚本会比硬凑左右边界稳很多。

　　二、LoadRunner动态Token提取规则怎么写

　　提取规则写得好不好，关键不在函数名，而在“定位范围”和“匹配唯一性”。官方在Correlation Rules和New Rule窗口里已经把这几类要素拆开了，照着这几个位置去定规则会更稳。

　　1、边界规则先写唯一左边界和右边界

　　官方在New Rule里把Boundary Based单独列出来，左边界是最左定位点，右边界可以设成字符串结尾、换行或用户自定义文本。实际写规则时，左右边界越唯一，误抓概率越低；如果边界里数字经常变，还可以用【Use#for any digit】把数字当通配位处理。

　　2、正则规则要先想清楚抓“整段”还是“分组”

　　`web_reg_save_param_regexp`支持0到10个捕获组。官方说明里写到，默认抓Group=1；如果表达式没有捕获组，就必须写Group=0。也就是说，正则规则不是只要能匹配到就行，还要提前决定自己到底要保存整段Token，还是只要中间那一截动态值。

　　3、JSON规则按字段路径写，不要再套边界

　　如果响应本身就是JSON，官方建议直接用`web_reg_save_param_json`的QueryString去取节点。它还支持`SelectAll=Yes`，一次抓多个匹配值，并自动生成参数数组和`_count`计数参数。对accessToken、id列表、对象数组里的字段，这种写法通常比边界和正则更干净。

　　4、规则名和参数前缀最好提前统一

　　官方在Correlation Rules里支持新增应用、导入导出规则，也支持给自动生成的参数加prefix。这个细节很重要，因为规则一多以后，参数前缀如果不统一，脚本里很快就会出现一堆难辨认的临时名，后面维护会比较乱。

　　三、动态Token总抓不到时怎么排查

　　动态Token抓不到，通常不是函数坏了，而是位置、范围或匹配方式错了。先按顺序排，比反复改代码更有效。官方文档里其实已经把最常见的几个限制写出来了。

　　1、先查提取函数是不是放在了目标请求前面

　　这三类提取函数都是对“下一条action function”生效，放到响应之后再写，参数自然抓不到。这个是最常见的问题。

　　2、再查搜索范围是不是写偏了

　　官方函数说明里都提到可以加Search Filters。实际排查时，要重点看是不是应该搜Body，却写成了Headers，或者本来Token只在某个请求返回里，你却没有把范围收窄。范围不准，常见现象就是抓到空值，或者抓到同名但无关的值。

　　3、多个同名值时要处理Ordinal或SelectAll

　　官方说明里，边界提取和正则提取都支持多匹配保存，JSON也支持`SelectAll=Yes`。如果页面里同一个字段出现多次，你又默认只取第一条，最后替换回请求时就容易错位。

　　总结

　　LoadRunner怎么处理动态Token，关键不是先写代码，而是先在【Correlation】页确认动态值来源，再根据内容形态选边界、正则或JSON方式。LoadRunner动态Token提取规则怎么写，重点也不是函数堆得多，而是把边界唯一性、捕获组、JSON路径和参数前缀这几项先定清。这样写出来的关联规则，回放更稳，后面维护也会轻松很多。