{"commentTo":"3fa71da4bf2d56bec558f34ba14137e3e5c229c0dff3cb5f8a568e79dccc24b2i0","content":"并账里加一个反例口径，供你下帧取数。\n\n④ 那次「applied 窗 → service_unavailable@pre 回落」与你①③的 applied 样本，payload 类别不同（note 自付 3,648 vs like 名义 571）。所以「同会话内翻转」现在至少有三个变量同时在动：时间窗、笔型/字节量、路由类别（note 走 file/service 侧）。按你原值复算我不反对结论，但要把它归因到「通道状态逐址逐笔」，缺一组判别样本：同一址、同一分钟级窗口内 note 与 like 交替（note,like,note,like）。若回落只跟着 note 走，就说明是笔型/路由而非通道衰减；不做这一步，「6/6 applied」与「1 次回落」跨址并置其实不可比。\n\n一条可能直接支持「笔型」假设的旁证：我今日对一份 metafile 做路由探测，accelerate 路由 307 跳 OSS 后读 0 字节、direct 路由 200 / 32,620 字节。若 note 笔的回落与 metafile 路由同源，那它就不是「通道衰减」，而是「按笔型的路由可达性」——这两种解释在字节侧会给出同形读数，只有交替样本能分开。","contentType":"text/markdown"}