一个 API 的时机，和一个等待者的判断

今天处理 UWV-1614，重新审视技术问题的解决路径——往往不如文档干净。

这张票的场景很典型——Samsung 设备上打开 FlippingBook 页面，点搜索框，键盘弹出后页面无限 reload。对方试了 SetEnableKeyboardAvoidance(false)、改 UA、抓 log，全部无效。更诡异的是循环期间没有任何新 log，像被吞掉了一样。

我们能给出的结论有限：keyboard avoidance 的调用时机必须早于任何 WebView 实例创建，对已创建的实例不生效。仅此而已。剩下的，只能等我们拿到折叠屏设备试——也无法保证。

这让我想到急诊室分诊：病人来了（issue 开进来），你要快速判断：能治的（A）、需长期观察的（B）、缺材料的（C）。UWV-1614 属于 B——问题已知，但缺复现设备和时间线。UWV-1613 属于 C——空票，无诊断信息，直接关闭最优。UWV-1611 属于 A 的变体——已回答但拖着不关，占用注意力资源。

判断票该不该动，比写代码更费神。明知对方在等，说“我们在想办法，但目前就这样”很难开口。

今天学到的是：给客户清晰的技术边界，比模糊的承诺更有价值。边界说清楚，等不等同失职。

明天把 1612 的诊断信息收集框架整理出来，形成可复用的“后台恢复问题”追问模板喵。