最难复现的拖拽问题，往往不是拖不动，而是拖到一半设备展开了：手指还压在原来的位置，卡片却突然跳到另一栏，松手后又落进了铰链区域。

一、一个只在拖拽中展开设备才出现的错位

这次 Demo 叫 FoldDrop Bench，任务 ID 是 drag_20261001_14。页面左侧是素材列表，右侧是编排画布，用户把编号为 A-17 的卡片拖到右侧。设备折叠时，窗口坐标、组件局部坐标和显示坐标看起来几乎一致，最初版本因此一直工作正常。

问题出现在拖拽尚未结束时展开设备。窗口宽度由单栏变成 852 vp，中间出现 36 vp 的铰链避让区，两侧可用区域各 408 vp。旧代码仍拿拖拽开始时的局部坐标计算落点，于是预览从 (286, 512) 突然跳到 (624, 512)；更糟的是，姿态回调和松手回调同时到达时，画布收到两次提交。

我没有把它当成普通的响应式布局问题。布局切换只关心组件重新排在哪里，拖拽续接还必须回答三个额外问题：手指在物理屏幕上的位置有没有变化；新的窗口原点和缩放是多少；当前落点是否落进不可交互的铰链范围。三件事混在一个 onDrop 里，很快就会变成一串补丁。

修复后，我们连续完成 37 次拖拽，其中 6 次在手指按住期间改变折叠姿态。36 次正常提交，1 次因落点进入铰链区被明确拒绝，重复提交为 0，坐标重基最大误差 0.8 vp，最终状态 DROP_COMMITTED。状态链统一为 IDLE → DRAGGING → REBASING → COMMITTED。

二、拖拽会话保存显示坐标，不保存旧布局答案

旧实现把卡片左上角的局部 x、y 放进状态。窗口一重排，这组值仍然合法，却已经不再代表手指位置。我们改为记录显示坐标、窗口快照和布局代次，局部坐标只在当前帧临时计算。

下面这段代码解决“姿态切换后旧局部坐标失效”。拖拽开始与移动阶段都写入显示坐标；窗口变化时进入 REBASING，根据新窗口原点重新计算局部位置。

export type DragPhase = 'IDLE' | 'DRAGGING' | 'REBASING' | 'COMMITTED'

export interface WindowSnapshot {
  originX: number
  originY: number
  scale: number
  layoutEpoch: number
}

export class DragSession {
  readonly sessionId = 'drag_20261001_14'
  phase: DragPhase = 'IDLE'
  displayX = 0
  displayY = 0
  snapshot?: WindowSnapshot

  start(displayX: number, displayY: number, window: WindowSnapshot): void {
    this.phase = 'DRAGGING'
    this.displayX = displayX
    this.displayY = displayY
    this.snapshot = window
  }

  rebase(next: WindowSnapshot): { x: number, y: number } {
    this.phase = 'REBASING'
    this.snapshot = next
    return {
      x: (this.displayX - next.originX) / next.scale,
      y: (this.displayY - next.originY) / next.scale
    }
  }
}

这里的关键不是公式有多复杂，而是明确坐标的所有权。displayX、displayY 表示手指在显示空间的位置；组件局部坐标只是某一布局代次下的投影。窗口从单栏变双栏后，页面更新 origin 与 scale，再生成新的预览位置，旧的 x、y 不参与运算。

DragSession 由页面级状态容器持有，不能挂在会因断点切换而销毁的左右栏组件里。否则窗口变化刚好触发组件重建，会话对象先丢失，后续 onDrop 只能创建一个没有起点的新会话。页面退出时会话进入 IDLE 并解绑窗口监听；重复进入页面前必须检查旧监听是否已释放。

实际项目还要区分窗口变化来源。旋转、自由窗口缩放、折叠展开都可能改变矩形，但只有 layoutEpoch 变化才需要重新计算页面布局。频繁的尺寸抖动会合并到下一帧处理，避免每个回调都触发预览重绘。

三、铰链不是空白，而是一个不可提交区域

第一版双栏布局通过 margin 留出 36 vp，看起来已经避开铰链，可拖拽命中仍按整个窗口矩形计算。用户松手时卡片会被归入距离最近的一栏，视觉上像是系统替他选了位置。

下面的 HingeGuard 解决“不可见区域被当成合法落点”。它先判断点是否进入铰链，再把左右栏的坐标映射到各自内容空间；命中铰链时返回明确拒绝原因。

export interface RectVp {
  left: number
  top: number
  right: number
  bottom: number
}

export type DropRoute =
  | { kind: 'LEFT', x: number, y: number }
  | { kind: 'RIGHT', x: number, y: number }
  | { kind: 'REJECT_HINGE' }

export class HingeGuard {
  constructor(private hinge: RectVp, private rightPaneLeft: number) {}

  route(x: number, y: number): DropRoute {
    const insideHinge = x >= this.hinge.left && x <= this.hinge.right &&
      y >= this.hinge.top && y <= this.hinge.bottom
    if (insideHinge) return { kind: 'REJECT_HINGE' }

    if (x < this.hinge.left) return { kind: 'LEFT', x, y }
    return { kind: 'RIGHT', x: x - this.rightPaneLeft, y }
  }
}

本次窗口宽 852 vp，铰链区为 x=408～444 vp，右栏从 444 vp 开始。落入这 36 vp 时，页面不会偷偷吸附，而是保持拖拽预览并提示“请移出折叠区域”。这一次拒绝也被计入结果，因此手机图里的 Rejected hinge = 1 不是错误，而是边界策略生效。

需要注意，铰链矩形不能写死。设备方向、窗口模式和系统提供的避让信息变化后，都要重新生成 HingeGuard。拖拽过程中只替换不可变的 guard 快照，不能在命中测试执行一半时修改其边界。正式产品如果提供吸附，可在安全区内做有限磁吸，但不可把铰链中心当成可交互目标。

四、姿态回调与松手回调必须只提交一次

坐标修正后，日志里仍偶尔出现两条 Card A-17 committed。原因是窗口变化完成时会尝试恢复拖拽，而 onDrop 又同时到达；两个异步分支都认为自己拥有最终提交权。

下面的提交器解决“同一拖拽会话被多次写入”。它同时检查 sessionId、布局代次和卡片 ID，并在真正修改画布前占用提交令牌。

export class DropCommitter {
  private committed = new Set<string>()
  private activeEpoch = 0

  updateEpoch(epoch: number): void {
    this.activeEpoch = epoch
  }

  commit(sessionId: string, itemId: string, epoch: number,
    route: DropRoute, write: (route: DropRoute) => void): boolean {
    if (route.kind === 'REJECT_HINGE') return false
    if (epoch !== this.activeEpoch) return false

    const token = [sessionId, itemId, epoch.toString()].join(':')
    if (this.committed.has(token)) return false
    this.committed.add(token)

    write(route)
    return true
  }

  clear(): void {
    this.committed.clear()
  }
}

提交成功后，状态从 REBASING 或 DRAGGING 进入 COMMITTED，预览层才被清理。状态先改、数据后写会造成 UI 已消失但画布失败；数据先写、令牌后占用又会留下重复窗口，因此这里先占令牌，再执行一次同步的画布变更。正式项目若写入数据库，需要把 token 作为幂等键一起落库，不能只在内存防重。

旧 layoutEpoch 的回调直接返回 false，不尝试猜测新坐标。它可能是上一帧拖拽事件，也可能是系统队列里晚到的窗口通知。拒绝旧代次比“尽量提交”更可靠，因为预览仍能跟随当前会话继续移动，用户只需重新松手。

五、一次姿态切换在日志里应当能完整对上

调试页保留了四段关键证据。第一段记录 item=A-17 与显示坐标；第二段记录 windowWidth=852vp、hinge=36vp；第三段记录 phase=DRAGGING→REBASING；最后一段记录 rebaseError=0.8vp 与 state=DROP_COMMITTED。只看最终卡片位置，无法区分坐标换算正确还是恰好吸附到了附近网格。

最初为了抓到偶现问题，我在每次 move 都打印一条坐标，结果一秒产生几十行日志，真正的姿态切换反而被淹没。后来日志改成事件摘要：拖拽开始记录一次，窗口快照变更记录一次，发生重基时记录旧代次和新代次，提交或拒绝再记录一次。移动过程只在误差超过 1 vp 时采样。这样一轮操作最多十几行，仍能还原关键路径。

自动化测试也不能只模拟两个固定页面宽度。我们把 WindowSnapshot 做成可注入数据，依次喂入折叠、展开、自由窗口轻微缩放和快速折返四组序列。快速折返最容易暴露旧回调：epoch 21 的展开结果可能晚于 epoch 22 的再次折叠。测试要求旧代次无法提交、预览仍锚定最新显示坐标，而且最终 token 集里只有一条 A-17 记录。

无障碍状态同样要跟随会话。卡片进入 REBASING 时，读屏提示“布局正在调整”，稳定后再播报目标栏与位置；若命中铰链，则播报不可放置原因。提示不能在每个拖拽移动事件里重复触发，也不能因为组件重建把焦点送回页面顶部。我们将播报状态放在页面容器，与 DragSession 一起跨过左右栏重建。

手机运行图时间为 14:32。页面显示 37 次尝试、6 次姿态切换、36 次提交、1 次铰链拒绝、0 次重复提交，以及最大重基误差 0.8 vp。当前卡片仍是 A-17，任务 ID 仍是 drag_20261001_14，图中的数值与 HiLog 使用同一份会话摘要。

六、真正难处理的是中间态，不是最终双栏

很多折叠屏适配文章会对比折叠与展开后的两张静态页面，但这次问题恰好发生在两张图之间。窗口指标已经变化，组件树可能还在重建，手指事件却不会等页面稳定后再继续。只按最终宽度选择单双栏，解决不了正在进行的交互。

我们把验收分成三层。静态层检查 408+36+408 的安全区域；交互层检查手指不抬起时预览连续；数据层检查 A-17 最终只写入一次。三层任意一层失败，都不能因为“最终看起来在右栏”而通过。

性能上，拖拽移动事件不直接触发完整布局测量。显示坐标写入轻量会话，预览刷新合并到下一帧；窗口快照只在指标实际改变时创建。37 次测试中没有出现持续堆积的回调，页面退出后 window 监听、拖拽预览和提交令牌按顺序释放。

资源释放顺序曾经也制造过一次假成功。页面消失时先清空 DragSession，紧接着到达的 onDrop 找不到会话，于是创建默认对象并把 A-17 写到左上角。现在退出流程先把页面标记为 disposing，事件入口看到标记立即返回；随后取消窗口监听、停止预览帧、撤销未提交会话，最后清空令牌。任何回调都不允许在释放阶段创建新会话。

对埋点来说，一次铰链拒绝不应该和普通失败混在一起。普通失败说明代码、数据或资源异常，REJECT_HINGE 则说明用户落点触发产品边界。两者趋势不同：前者需要修复，后者若持续升高，可能说明铰链提示不够明显或安全区设计不合理。本轮只有 1 次拒绝，测试人员能从事件链看出它发生在故意放到中缝的用例。

最后我们在 60 Hz 与高刷新率模式下都测了一遍。重基逻辑不依赖固定帧数，只依赖最新 WindowSnapshot；动画插值使用事件时间而不是计数器。因此设备切换刷新率时，预览速度可能略有差异，落点计算却不会漂移。当前 0.8 vp 是六次姿态切换里的最大值，验收门槛设为 1 vp，超过后会保留诊断快照而不是直接吞掉。

还有一个产品取舍：姿态切换持续时间过长时，是继续拖还是取消。FoldDrop Bench 在 500 ms 内完成重基就续接，超过阈值则回到原卡片并提示重新拖动。与其让一个失去上下文的操作勉强完成，不如明确撤销。这个阈值应结合设备动画和实际帧率测量，不能照搬 Demo。

最终我保留的判断很简单：折叠屏拖拽不是“在新宽度上再算一次位置”，而是让同一个交互会话跨过两套坐标系。显示坐标提供连续锚点，铰链 guard 定义不可提交边界，layoutEpoch 与幂等令牌负责挡住晚到和重复回调。只有这三件事同时成立，DROP_COMMITTED 才代表一次可信的落点，而不只是页面碰巧没有崩。

如果要把 Demo 扩展成正式编辑器，我会继续补键盘拖拽、撤销栈和跨窗口移交，但不会改变这条主线：每次交互都要有稳定身份、明确坐标空间和可验证的提交边界。页面形态可以变化，会话语义不能跟着漂移。