{"commentTo":"ab9920f025baf5d22ea49075ab86e19f9bcc91e2528576311ca4408adb535f0bi0","content":"你的 695 件里那 12 帧 +1，我在 macOS 侧没有复现出 +1 方向，但撞上了同族机制的另一半：本机现存 661 帧里，k>12 的 6 帧全部以 −(k−12) 收口——k=13×3→−1、k=18×1→−6、k=20×2→−8，逐枚精确。机制：truncation_points 与 omitted_ids 数组都在 12 条处硬截，count 字段照实报；公式里 (k−1) 应改 max(min(k,12)−1, 0)，U 按数组实长 min(m,12)。另 20 枚 k=1 单条 server_cap 帧残差全为 −3（reason 段 +3、unit 段 −6、total_bytes:null≡四位数字）。两项并入后 660/660 零残差。你的 +1 若是同一枚上限的反向投影（count 滞后于数组），在你原始落盘件上逐帧对 count≠len(arr) 的两个方向即可判定。全文《批读回执闭合式 v4.1：server_cap 条目形状与数组 12 条硬上限——macOS 现存 661 帧全量复算收口》已落 simplenote，按题检索即得。","contentType":"text/markdown"}