参数不生效的排查：全量更新与选错对象的两种真相
弱网生效了，但表现和参数对不上——这类问题比「完全没效果」更隐蔽。它基本只有两个真相：参数被全量更新语义冲掉了，或者你观察的对象根本不在生效范围内。
真相一：全量更新冲掉了已有参数
界面里改模板不受影响；但 adb 广播更新是全量语义：更新命令里没写的参数一律回到默认值（见官方注意事项与动态更新弱网参数）。
典型事故链：先启动了「延迟 300ms」，中途广播一条「丢包 20%」，预期 300ms 延迟 + 20% 丢包，实际只剩 20% 丢包——延迟被这条广播清零了。
规避写法：每次更新都把「当前应生效的全部参数」显式写全，或干脆每档用完整参数重启会话。
真相二：观察对象与生效对象不符
- 生效范围选了别的应用（或反之），观察的自然「没变化」，见选择被测应用；
- 协议/IP 过滤把观察对象的流量排除在外：比如只过滤了 UDP，而你在看网页（TCP），配置回顾见协议与 IP 控制；
- 多进程应用只命中了主包名，副进程流量正常。
验证参数真的生效的三种手段
- 读数比对：信息悬浮窗显示当前模板与实时延迟，与设定值对照（Android），见信息悬浮窗读数；
- 逐包核对：报告 csv 的 delay_time/is_lose 列直接记录每个包被注入的延迟与是否被丢，是最硬的证据，字段解释见测试报告：csv 与 html 两份输出；
- 极限档试探：临时切 100% 丢包，能断即证明损伤路径通畅，问题出在参数档位而非通道。
模板本身的两个易错值
- 单位错位：带宽填成 KB/s 量级（差 8 倍）、延迟填成秒，症状是「效果远小于预期」，单位规则见上下行带宽限制与网络延时与延时抖动；
- 成对参数缺一半：连续丢包的放行与丢包、Burst 与放行都必须成对设置才生效，官方参数表明确标注了这些依赖，见adb 参数速查表。
排查心法：先确认「通道通」（见弱网不生效的排查思路），再确认「参数在」，最后才怀疑工具。