(null);
const [, setLocked] = useScrollLock(scroller);
return (
{children}
);
}
```
同一个 hook，同一个元组。这也是为什么 `target` 是必填而不是默认 `document.body`：库无法知道哪个元素才是你的滚动根。
### 3. 拖拽期间锁定
触摸拖动滑块、可排序列表或自定义轮播时，页面会跟着滚，除非有东西拦住它——而 `touchmove` 守卫恰好就是对的工具：
```tsx
const [, setLocked] = useScrollLock(() => document.body);
setLocked(true)}
onPointerUp={() => setLocked(false)}
onPointerCancel={() => setLocked(false)}
/>
```
`onPointerCancel` 很关键：浏览器可能在手势中途抢走指针，没有它你就会把页面锁死。如果你是在自己实现拖拽而不只是接一个现成的，[`useDraggable`](https://reactuse.com/element/usedraggable/) 已经把指针那套账都记好了。
## 值得知道的坑
### 1. 锁定是一个样式，不是一段生命周期
锁是写在一个 hook 并不拥有的元素上的行内 `overflow: hidden`，总得有人把它放回去。从 `@reactuses/core` v6.5.3 起，持有锁的组件卸载时 hook 会自己做这件事：还原它替换掉的那个行内值，并摘掉 iOS 的 `touchmove` 守卫——所以"弹窗还开着就跳路由"不会再把页面冻住。v6.5.2 及更早版本不会还原，如果你锁在旧版本上就得留意：在 iOS 上残留的那个 `passive: false` 监听会把整个会话剩下的触摸滚动全部干掉，不只是样式的问题。
不过卸载只是一半。另一半——组件还挂着、只是弹窗关了——无论哪个版本都得你自己管，这也正是上面那个模式把 `setLocked` 绑到 `open` 上并带 cleanup、而不是在两个 handler 里分别开关的原因：
```tsx
useEffect(() => {
setLocked(open);
return () => setLocked(false);
}, [open, setLocked]);
```
把 setter 当成你借来的一个样式。每一次借都要还。
### 2. 一个元素只能有一个持有者
两个 hook 实例锁同一个元素是最微妙的失效方式，因为每个实例都记着**自己那份**原始 `overflow`：
```text
A.lock() → overflow: hidden （A 记住的是 "auto"）
B.lock() → overflow: hidden （B 记住的是 "hidden" 😬）
A.unlock() → overflow: auto （页面能滚了，尽管 B 还认为自己锁着）
B.unlock() → overflow: hidden （现在页面卡死了，而且什么都没打开）
```
这里没有什么能救你——这是「保存旧值、再放回去」这个思路本身固有的问题，所有手写方案和大多数库都一样。答案在架构层面：**每个元素只有一个锁的持有者。** 把 `useScrollLock(() => document.body)` 放在布局、Provider 或者 store 里，让各个弹窗去请求它加锁，而不是各自带一个。
### 3. `initialState: true` 会跳过 iOS 守卫
`useScrollLock(target, true)` 会从第一次提交起就加上 `overflow: hidden`——但 `touchmove` 监听只在 `lock()` 里挂，而 `lock()` 从没跑过。所以一个初始就锁定的页面在 iOS 上依然能橡皮筋滚。从 `false` 开始，然后翻过去：
```tsx
const [, setLocked] = useScrollLock(() => document.body);
useEffect(() => { setLocked(true); }, [setLocked]); // 挂载即锁定，守卫也带上了
```
### 4. 桌面端布局抖动
滚动条一藏，就腾出约 15px，整页横向抖一下。这不是 hook 该管的事，一行 CSS 就够：
```css
html { scrollbar-gutter: stable; }
```
### 5. SSR 下要传 getter，不要传 `document.body`
`useScrollLock(document.body)` 会在**渲染期间**求值 `document.body`，在服务端还没轮到 hook 小心行事就已经抛错了。`() => document.body`（或一个 ref）只在 effect 和 handler 里被读到，而那里 `getTargetElement` 早已在没有 `window` 时直接返回：
```tsx
const [, setLocked] = useScrollLock(() => document.body); // ✅ SSR 安全
const [, setLocked] = useScrollLock(document.body); // ❌ 服务端崩
```
库里所有接受元素 target 的 hook 都是同一条规则，这也是 Next.js / Remix 项目里最常见的 SSR 失误。
### 6. `hidden` 拦手势，不拦程序化滚动
一个 `overflow: hidden` 的盒子依然可以通过 `scrollTop`、`scrollTo`、`scrollIntoView` 滚动——更关键的是，浏览器会为了把新获得焦点的元素带进视口而滚动它。如果焦点跑到了弹窗背后的某个链接上，你「锁住」的页面会滚过去。滚动锁定和焦点陷阱是同一个功能的两半，两个都要做。
## 什么时候不该用 useScrollLock
- **你只想阻止内层滚动容器把滚动传递给页面** → CSS 的 `overscroll-behavior: contain`，一行 JS 都不用。
- **你在用 `