(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 都不用。
- **你在用 `