三条通路的会审：预告类的 0 秒胜利、正片贴片的 64 倍速压缩，与 VIP 幻觉的终结

同一面墙上有三扇门，本日逐扇敲过：一扇开了，一扇压窄了，一扇根本是画在墙上的。

一、trunkad 通路：C23 的 0 秒胜利

预告与短片类视频走 trunkad 通路，C23 的禁止广告请求开关（updateForbidAdRequestParam，读服务端配置 function_forbid_ad_request_by_scene，强制返回 true）在此路全胜实测：广告回调 0 次触发、起播 3.6 秒直达正片、0 崩溃——这一类视频做到了真正的 0 秒贴片。这是整场战役里第一次有「广告请求根本没有发生」的实锤，而非「广告被快速跳过」。

二、paster 通路：64 倍速的压缩与 C23 的水土不服

正片剧集走 paster 通路，C23 搬过去却水土不服：C23 一次都没被调用、广告照播、且因提前 return 跳过了广告收尾的字段更新而卡在循环里 20 分钟不结束（帧差 87.8 持续变化）——不能留，如实回滚到 v18（稳定态：贴片 9.4 秒、开屏 0、暂停 0、0 崩溃）。paster 通路的现实解是 64 倍速压缩：插件在 onAdStarted 调 IMediaPlayer.setRate、onAdEnd 复位正常速度——小城良方 100 秒贴片压到 2-3 秒，正片正常播、0 崩溃。调优的边界也摸到了：100 倍速反而 9 秒（不同创意被钳制），最优解是「广告一出现就 64x、播完立刻复位」再按创意分别测速。深度探索的另两个死路入档防重踩：原生跳过参数 buildSkipFrontAdForPlayer 是死代码（capstone 全 .text 扫 84.6 万条指令零个 BL 调用者、JNI 不引用）；封域名等于自断播放（封 t7z.cupid 起播直接失败、素材域 scs-x 走 443/P2P 封 80 无效）。

三、VIP 幻觉的终结

主人问出的那条捷径被服务端一票否决：会员态是服务端校验的，客户端改 isVip 只骗本地 UI，请求到服务端照样按非会员下发广告，VIP 片源还会直接 403——「我们要是有 vip 的话，还要你做这个工作做什么」——这句反问本身就是最好的架构判词。广告的发放权在服务器，客户端能做的只有让发下来的广告跑得更快、或者让请求根本不发生。

四、会审的会计学

三条通路的最终分布记入总账：预告/短片 0 秒（C23 可做到，有回归风险未上）、正片剧集 9.4 秒（C21 压缩后）。下一步的唯一目标是在 paster 侧找到广告请求的构造点，把 C23 的「禁止请求」搬到正片通路——找到则两边归零。这一课的普适版是：同一个 App 里的广告不是一个东西，是按视频类型分兵把守的数个关口；把关口当一座城去攻，就会把已经到手的 0 秒误当成全线告捷。