update at 2026-03-04 13:25:26

pxterm/mobile-scroll-optimization.md

@@ -35,4 +35,31 @@
 凭借这种高度克制且动态的干扰策略，我们实现了“鱼与熊掌兼得”：
 1. **完美原生选区**：长按仍能顺畅唤起 iOS 文本放大镜与蓝色选框。
 2. **不断流的跟手滚动**：只要没有进入选区模式，手指在密集的字符网格上狂滑也不会触发浏览器原生手势劫持，配合 60fps 的 JS 帧动画达到了极致丝滑。
-3. **软键盘完整兼容**：没有使用全局焦点的强行剥夺，不阻碍日常的点击输入与键盘显隐。
+3. **软键盘完整兼容**：没有使用全局焦点的强行剥夺，不阻碍日常的点击输入与键盘显隐。
+## 5. 最后的幽灵 Bug：触控目标为 SPAN 时滑动冻结 (The Phantom Bug: "SPAN" Target Blocking)
+尽管我们实现了精密的动态拦截，但在实际使用中偶尔仍会触发严重的“屏幕冻结”。
+通过全局侦听所有触摸和指针事件，我们抓到了极其关键的日志：
+**当手指正常滑动时**：目标(Target) 是每一行的 `DIV`，`touchmove` 和 `pointermove` 都能成对、连续触发，我们的 JS 动量接管运转完美。
+**当发生冻结时**：目标(Target) 变成了渲染终端彩色字符的内联元素 `SPAN`，紧接着**所有的 `touchmove` 事件就会离奇消失**，只剩下 `pointermove` 在孤零零地触发。
+
+### 为什么碰到 `SPAN` 就不动了？
+这源于开启了 `-webkit-user-select: text` 后，iOS Safari / WebKit 独有的**文本触摸启发式逻辑 (Text Interaction Heuristic)**：
+当手指触摸在一个内联文本节点（如 `SPAN`）并且试图开始移动时，iOS 极大概率会将其判定为“光标拖拽”或“准备框选”。为了不打断系统的文本交互，iOS 会在非常底层的级别**没收（Swallow）后续所有的 `touchmove` 事件**。由于 `touchmove` 消失了，我们在 Vue 中原本用于拦截默认行为和计算 `dy` 滑动的代码根本没有执行的机会。于是表现为彻底断流结冰。
+
+### 解决方案：视觉层穿透 (CSS Pointer-Events)
+我们不能取消文本选择，否则长按复制功能就没了。但其实用户长按选中某行字，并不需要精确点击到那个细小的 `SPAN`，只要点击到包围它的块级元素 `DIV` 即可（iOS 支持依靠容器进行坐标选取）。
+
+因此，最有效的解法是对所有终端内容层的 `SPAN` 施加“触控隐身”：
+```css
+/* 规避 iOS 触摸事件吞噬问题：
+   当目标是 span 等特定内联元素时，iOS 容易在滑动中没收 touchmove。
+   将其鼠标事件穿透到 div (行) 上可以绕过引发吞没的 WebKit 内核特定文本触摸启发式逻辑
+   同时并不影响基于坐标的文本选择。 */
+.terminal-container.native-touch-selection .xterm-screen span {
+  pointer-events: none;
+}
+```
+**影响评估：**
+- **滑动修复**：用户手指摸到的永远只有块级的 `DIV`（行），iOS 将其视为普通面板，从而持续派发我们亟需的 `touchmove`。彻底解决偶发冻结问题。
+- **选区保持**：包围层 `.xterm-rows > div` 仍具有 `user-select: text`，系统原生长按动作（包括双端拖拽把手）依靠父级空间坐标寻找文本，完全不受影响。
+- **xterm 功能**：xterm.js 其内部功能（如链接点击）通过捕捉整层的视口相对坐标映射到网格系来处理，也不受丢失底层 `SPAN` `target` 的影响。