内容纲要
概要描述
修改了全局／工作区参数后，新调度已使用新值，但历史记录重跑仍读取旧值；或同一任务流中不同任务得到不同结果。此类现象不一定是参数缓存问题，应先确认原执行模式、参数作用域和运行期赋值。
详细说明
1. 建立一张参数对照表
在执行详情中选取同一业务批次的原记录、运维后记录和一条新调度记录，记录：执行ID、原执行模式、调度时间、版本、参数名／作用域、执行前值、执行后值。脱敏后比较，不将密码或Token写入问题单。
参数页显示的是本次执行取到的值，不一定等于当前配置页默认值。任务未执行、执行失败、流未到终态时，部分输出参数可能不展示，不能把空白直接认定为参数丢失。
2. 按原执行模式核对来源
| 原记录的执行模式 | 运维参数核对重点 |
|---|---|
| 手动运行 | 历史执行时的输入参数列表；再检查任务内参数传递 |
| 手动运行当前及下游 | 历史输入列表与跨流传参；任务流／任务参数可能覆盖传入值 |
| 系统调度 | 最新版本的参数值以及上游传参，不按“历史手动输入”判断 |
对于系统调度，手册给出的优先级为：全局参数 < 工作区参数 < 跨任务流传参 < 任务流参数 < 任务内传参 < 任务参数。先按本次执行模式判断来源，再看同名覆盖，不能只修改最低优先级的全局值就预期所有任务变化。
手册“参数能力”与“运维操作的参数处理”两处对新增参数的说明详细程度不同；历史记录中新增参数如何呈现，需按现场补丁与实际执行详情核对，不凭空补一个默认值。
3. 排除运行期再次赋值
检查Shell／SQL任务是否修改同名参数、下游是否启用引用上游参数，以及Shell脚本自身是否定义同名变量。只对比配置页，可能漏掉执行过程中的覆盖。若嵌套任务流修改的是任务／任务流局部参数，不要假设它一定返回外层；全局／工作区参数的传递范围与局部参数不同。
4. 用无副作用的小样本验证
在获准的测试任务中选一个非敏感参数，分别对历史手动记录、新系统调度和存在传参的下游检查执行前／后值。以对照表确认差异来自哪个层级，再改对应配置；不要在生产写入任务上反复重跑作实验。
其他信息
若参数本身是业务日期，还要区分调度时间与实际运行时间。