滚动页面上滑到七八屏之后，用户想回到页面顶部，这是个高频但特别容易被敷衍的功能。我见过太多项目里这行代码是随手补的：有人写window.scrollTo(0,0)，有人直接在href里塞一个#，还有人把scrollTop一顿乱赋，结果按钮在某个容器里死活不生效，最后加班半小时查“为什么点了没反应”。其实点击按钮回到页面顶部这五种写法，每一种背后都对应着不同的滚动机制、不同的兼容边界和不同的失控方式，选错了不是“难看一点”，而是“在某些机型上完全不工作”。下面我把这五种写法拆开讲，包含每种写法适用的场景、参数怎么定、代码可直接抄，以及我在实际项目里踩过的坑。前端新人能照着做出一个稳的；写了一两年的人可以重点看第四节到第七节，那里才是真正拉开代码质量差距的地方。

1. 按钮虽小，坑位不少：先把问题边界划清楚

1.1 用户真正想要的是"回到一个可预期的位置"

很多人把需求理解成"把滚动条移到 0"，这个理解本身没错，但它漏掉了两个关键前提。第一个前提是滚动容器是谁。页面的滚动不一定发生在window上，很多后台管理系统、聊天界面、商品详情弹层，滚动都是由某个overflow-y: auto的 div 承担的。这时候你对window做任何操作都等于对着空气挥手。第二个前提是回到哪个位置才算"顶部"。如果页面顶部有一条固定在屏幕上的导航栏，你把内容卷到坐标 0，那被导航栏遮住的那 60 到 80 像素的内容用户还是看不见，视觉上并没有"回到最开始"。

我在一个内容型站点上就吃过这个亏：页面滚动到 0 之后，文章标题被吸顶导航压住了半个字高。用户反馈是"回到顶部之后标题缺了一半"，而代码本身没有任何 bug。这个问题的解法跟滚动动画一点关系都没有，纯粹是滚动偏移量的补偿问题，后面第 2.2 节会讲具体怎么处理。

所以一个合格的"回到页面顶部"，至少要同时满足：滚动的是正确的容器、落点是用户视觉上认可的顶部、动画过程不卡顿不抽搐、按钮本身在合适的时机出现和消失。这四件事里，前三件跟"五种写法怎么选"直接相关。

1.2 五种写法的取舍地图

先把全景铺开，后面再逐个展开。这五种写法按"控制力从弱到强"排列，基本是这样一个梯度：

提示：这五种不是互斥的。实际项目里最常见的组合是"用scrollTo的behavior: 'smooth'，配上特性检测回退到直接赋值"，也就是第四种降级到第二种。手写动画只在有明确动效要求时才上。

还有一件常被忽略的事：按钮什么时候显示。这部分跟滚动写法无关，但用户感知的"好不好用"八成来自它。文章第 7 节单独讲，用IntersectionObserver做比监听scroll事件干净得多。

2. 写法一：锚点跳转，最老但最抗摔

2.1 最小可用版本与它的三个副作用

锚点方案的核心就两行 HTML：页面最顶部放一个空锚点，按钮写成指向它的链接。

<!-- 页面最顶部 --> <div id="page-top"></div> <!-- 按钮 --> <a href="#page-top" class="back-to-top">回到顶部</a>

这套写法的最大优势是零 JS。浏览器原生处理，键盘回车能触发，读屏软件能识别成链接，禁用了 JS 的环境照样能跳。在纯内容型站点上，它的性价比高到没有理由拒绝。

但如果你直接用href="#"，会撞上三个副作用。第一个，地址栏尾部会多出一个孤零零的#，看着不干净，某些站点的路由监听 hash 变化，多一个#就会触发一次莫名其妙的路由重置。第二个，href="#"每次点击都会往浏览器的历史记录里推一条记录，用户点完"回到顶部"再按返回键，退不回去上一页，只是把 hash 从#变回空，体验上像"返回键坏了"。第三个，如果你用了前端路由的 hash 模式，锚点跳转和路由会互相打架。

第一个和第二个副作用的解法都很轻：给按钮绑个点击事件，event.preventDefault()之后手动滚动，或者干脆用history.replaceState(null, '', location.pathname + location.search)把 hash 擦掉。但一旦你开始写 JS，锚点方案"零 JS"的优势就已经没了，不如直接上第四节的原生平滑滚动。

2.2 用 scroll-padding-top 解决"被吸顶导航挡住"

这一节是锚点方案里真正有价值的部分。假设页面顶部有个高度 64px 的固定导航栏，锚点跳到#page-top之后，目标元素正好落在视口顶端，被导航栏盖住。传统做法是给锚点元素加padding-top: 64px再配一个负的margin-top，把元素往上顶。

现在有更直接的办法：在根元素上声明滚动内边距。

html { scroll-padding-top: 64px; scroll-behavior: smooth; }

scroll-padding-top的作用是给滚动容器定义一个内边距区域，所有滚动定位（包括锚点跳转、scrollIntoView、Tab 键聚焦自动滚动）都会把这个距离算进去。它比 padding 打补丁的方式干净得多，因为不改变盒模型，也不影响现有的布局。

同样的思路还能解决固定底部工具栏的问题，用scroll-padding-bottom。移动端底部有条 56px 的操作条时，用这个值能让跳转落点自动上移。

注意：scroll-padding-*加在滚动容器上，不是加在目标元素上。很多人加错位置，然后发现没效果。如果页面滚动发生在某个 div 上，这行 CSS 得写到那个 div 上。

2.3 锚点方案什么时候直接排除

有三种情况我会直接把锚点方案从候选里划掉。

第一种，页面用了 hash 路由。锚点跳转本质上就是改 hash，跟路由系统的监听逻辑是同一套东西，强行共用会互相干扰，排查成本远高于收益。

第二种，滚动容器不是页面本身。锚点只认"最近的滚动祖先"，如果做出回顶动作的是某个弹层，而弹层的滚动和页面的滚动是两回事，锚点会把整个页面也带着滚一段，用户看到背景页面在动，非常出戏。

第三种，需要精确控制动画时长和曲线。CSS 的scroll-behavior: smooth用的是浏览器内置的缓动，各平台实现不一样，有的偏快有的偏慢，你做不了任何微调。产品经理要求"500 毫秒匀速收尾"的时候，这条路就走不通了。

3. 写法二：scrollTo(0, 0) 与 scrollTop 直接赋值

3.1 到底该改 documentElement 还是 body

这是纯 JS 方案里最经典的一个历史包袱。早期规范里，文档的滚动位置挂在body上，后来标准模式改成挂在documentElement（也就是<html>）上。怪异模式（页面没有<!DOCTYPE html>声明）下还是会走body。

现在的项目基本都有标准模式声明，所以document.documentElement.scrollTop = 0是对的。但那些从老系统迁移过来的页面、某些富文本渲染出来的 iframe 内部页面，确实可能没有 DOCTYPE。我在一个遗留项目里遇到过，页面在 iframe 里，documentElement.scrollTop赋了值纹丝不动，改成body.scrollTop才生效。

稳妥的写法是两句并排，或者用现代 API 一键拿到真正的滚动元素：

// 兼容写法，两句一起写，多余的赋值不会有副作用 document.documentElement.scrollTop = 0; document.body.scrollTop = 0; // 现代写法，直接拿到实际参与滚动的元素 const scroller = document.scrollingElement || document.documentElement; scroller.scrollTop = 0;

document.scrollingElement在支持它的环境里会返回documentElement（标准模式）或body（怪异模式），一行代码免去判断。它的兼容性已经很好了，配合上面那个||兜底，可以放心用。

还有个细节：window.scrollTo(0, 0)和scrollTop = 0在行为上等价，但前者是函数调用，后者是属性赋值。如果页面上有别的代码监听scroll事件做吸顶导航之类的效果，两者都会触发滚动事件，没有区别。真正的差别在于scrollTo可以传对象参数做平滑滚动，scrollTop只能瞬跳。

3.2 scrollingElement 与"滚动容器不是 window"的排查

这一节值回票价。当你发现"代码看起来没问题但点了没反应"，九成是滚动容器找错了。排查方法很简单：在控制台里跑一句document.scrollingElement.scrollTop，如果页面明明已经滚下去好几屏了，它返回的还是 0，那就说明滚动根本不在文档层级上。

接下来定位真正的容器，用这个逻辑往下找：

function findScroller(el) { while (el && el !== document.body) { const style = getComputedStyle(el); const overflowY = style.overflowY; if ((overflowY === 'auto' || overflowY === 'scroll') && el.scrollHeight > el.clientHeight) { return el; } el = el.parentElement; } return document.scrollingElement; }

它的思路是从按钮所在的元素往上逐层查，找到第一个"纵向可滚动且内容确实溢出"的祖先。找到之后，回到顶部就变成container.scrollTop = 0，跟window一点关系都没有了。

提示：overflow-y: hidden也会让元素成为一个滚动容器（它仍然是 scroll container，只是禁用了用户滚动），所以只判断overflowY === 'auto' || 'scroll'是靠谱的。判断时一定要带上scrollHeight > clientHeight，否则会把一堆普通布局容器误认成滚动容器。

3.3 瞬跳的价值：别急着上平滑滚动

很多人一上手就想要平滑滚动，觉得瞬跳"廉价"。我不同意。瞬跳在有些场景里恰恰是正确选择。

一是长列表翻页。用户在商品列表看了两百条，点"回到顶部"其实是想重新用筛选条件，这时候 300 毫秒的动画就是纯粹的等待。二是连续操作。用户在表单页反复上下跳着填字段，动画会累积成烦躁感。三是无障碍场景，前庭功能敏感的用户对大面积平滑位移有生理不适，系统级的"减少动态效果"开关就是为这个准备的。

所以我的做法是：默认瞬跳，只在"从下往上浏览完一段内容后想回到开头"这种场景里用平滑。判断依据很土但很有效——如果页面有明确的"段落感"（文章、详情页、长图文），用平滑；如果页面是"密集操作型"（列表、表格、表单），用瞬跳。

4. 写法三：scrollIntoView，适合回到"某个位置"

4.1 参数写法与 block 取值

scrollIntoView的思路不是"把滚动位置设成 0"，而是"把某个元素滚进可视区域"。这两件事在效果上接近，在语义上完全不同，用对了很省事。

const top = document.getElementById('page-top'); top.scrollIntoView({ behavior: 'smooth', block: 'start' });

block的几个取值决定了目标元素落在视口的哪个位置：start是顶部对齐（回到页面顶部要的就是这个），center是居中，end是底部对齐，nearest是"就近"，元素已经可见就不动。还有一个inline参数管横向，回顶场景用不上，但不写的话在某些浏览器里横向也会有细微位移，稳妥起见写上inline: 'nearest'。

老版本语法是传一个布尔值scrollIntoView(true)，等价于alignToTop = true，也就是block: 'start'。这个写法兼容性最好，但没有任何平滑能力。现在还在用布尔值的基本是历史遗留代码，可以改。

4.2 它会连带滚动所有祖先容器（弹窗场景的经典事故）

这是scrollIntoView最出名的一个坑，我至少踩过两回。

它的规范行为是：滚动目标元素的所有可滚动祖先，直到元素完全可见。注意是"所有祖先"，不是"最近的那个"。所以在这样一个结构里会出事：页面本身可以滚，页面上叠了一个弹窗，弹窗内部也可以滚。你在弹窗内部的按钮上调用scrollIntoView，弹窗内部会滚，页面背景也会跟着滚。用户关掉弹窗之后发现底下的文章位置变了，一脸懵。

更麻烦的是这个行为你没法用参数关掉。有几个绕法：给页面根元素在弹窗打开时加overflow: hidden（很多弹窗方案本来就这么做，顺带解决了这个问题）；或者干脆放弃scrollIntoView，改成container.scrollTop = 0。

还有一种情况是横向滚动条被意外带动。页面有个横向可滚的表格，用scrollIntoView回顶时，浏览器为了"完全可见"可能顺带调整横向位置，表格的横向滚动位置被重置了。加inline: 'nearest'能缓解，但根治的办法还是直接操作容器。

4.3 我一般怎么用

尽管有一堆毛病，scrollIntoView在"跳转到页面中某个锚点区块"这件事上仍然是最省事的，尤其是配合 CSS 的scroll-padding-top一起用，能自动避开吸顶导航。

我的用法分两种情况：如果目标是"回顶部"，优先用scrollTo，因为落点是明确的 0，不需要浏览器去算元素位置；如果目标是"跳到某个章节""跳到某条评论"，用scrollIntoView，因为它会自动处理元素定位，我不用关心那个元素距离顶部多少像素。判断标准就一句话：目标是坐标系里的一个点，还是页面上的一个元素。点用scrollTo，元素用scrollIntoView。

5. 写法四：scrollTo 的 smooth 选项，一行代码搞定平滑

5.1 对象参数与特性检测（老内核静默失败）

这是目前最主流的方案，代码短到没法再短：

window.scrollTo({ top: 0, left: 0, behavior: 'smooth' });

但它有一个非常恶劣的失败模式：在不支持对象参数的老内核上，它不会报错，也不会滚动。原因不难理解，老版本把scrollTo的第一个参数当坐标处理，你传一个对象进去，会被转换成NaN，NaN转成坐标就是无效值，函数直接静默返回。控制台干干净净，按钮就是不动，这种 bug 排查起来最费神。

所以必须做特性检测。最可靠的判断方式是看scrollBehavior这个 CSS 属性是否存在于元素样式里：

const supportsSmoothScroll = 'scrollBehavior' in document.documentElement.style; function backToTop(distance) { if (supportsSmoothScroll) { window.scrollTo({ top: 0, left: 0, behavior: 'smooth' }); } else { window.scrollTo(0, 0); } }

这个检测是在页面加载时算一次就行，不需要每次点击都判断。把它缓存成一个常量，代码会干净不少。

注意：检测的是"支不支持平滑滚动"，不是"支不支持对象参数"。理论上存在支持对象参数但不支持平滑的内核，那种情况下传了behavior: 'smooth'会退化成瞬跳，不会不工作。所以用scrollBehavior检测是安全的一侧。

5.2 中途打断与"抢方向盘"问题

原生平滑滚动的第二个问题是打断行为不一致。用户点了按钮，动画开始往下走，此时用户自己滚了一下滚轮，理想情况是动画立即停止、控制权交还用户。实际表现是：有的内核会立刻中断，有的会继续走完，有的会算出一个混乱的合成速度。用户在动画期间滚一下，页面可能反而往上冲一段，体验很差。

更麻烦的是，你没法监听"动画结束"这个状态。scrollTo不返回 Promise，也不派发完成事件。想在做完之后做点事（比如恢复焦点、解锁某个交互），只能靠估时加setTimeout，或者监听scrollend事件——scrollend是相对新的东西，覆盖面还不够。

如果你的产品对这段交互有明确要求（比如"动画期间禁止用户干预""结束后焦点必须落回标题"），那第五种手写方案才是正解，因为你能完全掌控开始、中断和结束三个时机。

5.3 无障碍：prefers-reduced-motion 必须处理

这是个容易被跳过但实际很重要的点。系统层面有个"减少动态效果"的开关，用户开了这个开关，说明他对大面积的平滑位移敏感，可能引起眩晕甚至不适。你的页面如果无视这个设置，强行播放 800 毫秒的全屏滚动动画，对这类用户就是纯伤害。

处理方式是在 CSS 和 JS 两边都做响应。CSS 侧管住scroll-behavior：

@media (prefers-reduced-motion: reduce) { html { scroll-behavior: auto; } * { animation-duration: 0.01ms !important; transition-duration: 0.01ms !important; } }

JS 侧在发起滚动前读一下这个媒体查询：

const reduceMotion = window.matchMedia('(prefers-reduced-motion: reduce)'); function backToTop() { const behavior = reduceMotion.matches ? 'auto' : 'smooth'; window.scrollTo({ top: 0, left: 0, behavior }); }

reduceMotion.matches是实时值，用户中途改了系统设置也能生效，不需要重新加载页面。这几行代码成本极低，但它是"这个功能做得是否专业"的分水岭之一。

6. 写法五：requestAnimationFrame 手写缓动

6.1 什么时候值得手写

先说结论：九成场景不需要手写。原生behavior: 'smooth'已经够用，代码量还低。但在下面这几种情况下，我会选择自己动手。

第一种，动效有明确规范。产品的设计规范里写了"回顶动画 450 毫秒，ease-out 曲线，距离超过三屏时延长到 700 毫秒"，这种要求原生方案满足不了，它连时长都不给你设。

第二种，需要中途打断且行为可控。用户一碰滚轮立刻停下，且停下的位置就是当前动画位置，不能有跳变。手写方案能做到毫秒级响应。

第三种，需要和别的动画编排在一起。比如回顶的同时侧边栏收起、顶部提示条淡出，这些需要共用一条时间轴，用原生方案协调不了。

第四种，目标容器是个普通 div。scrollTo的平滑选项对容器元素也有对应写法（element.scrollTo({ top: 0, behavior: 'smooth' })），但覆盖面不如window那么好，有些环境里对容器无效。

6.2 缓动函数与时长怎么定（含参数计算）

缓动函数决定动画的"手感"。回到顶部这个动作，我的经验是必须用 ease-out（先快后慢），不能用线性，更不能用 ease-in。原因是用户的心理预期是"我说回顶，赶紧给我回"，开头慢会让操作显得迟钝；结尾慢是为了让视觉有个收束，不至于戛然而止。

几个常用的缓动实现，都是接收 0 到 1 的进度，返回 0 到 1 的位置系数：

const easings = { // 三次缓出，最通用，收尾自然 easeOutCubic: t => 1 - Math.pow(1 - t, 3), // 四次缓出，前半段更快，适合长距离 easeOutQuart: t => 1 - Math.pow(1 - t, 4), // 正弦缓出，柔和，适合短距离 easeOutSine: t => Math.sin((t * Math.PI) / 2), // 先加速后减速，居中感强 easeInOutQuad: t => (t < 0.5 ? 2 * t * t : 1 - Math.pow(-2 * t + 2, 2) / 2) };

时长的计算有个小技巧：固定时长在长短距离上观感差异极大。从 200px 滚到 0 用 400 毫秒，显得拖沓；从 8000px 滚到 0 用 400 毫秒，速度快到画面糊成一片，用户根本看不清中间内容。我一般按距离动态算：

function calcDuration(distance) { // 基础 240ms，每 1000px 增加 60ms，上下限 240ms ~ 720ms const raw = 240 + (distance / 1000) * 60; return Math.min(720, Math.max(240, raw)); }

按这个公式，滚到顶的距离是 600px 时，时长约 276 毫秒；距离 5000px 时，时长 540 毫秒；距离 12000px 时，算出 960 毫秒，被上限截到 720 毫秒。这个区间是我试下来最不容易出错的范围——低于 200 毫秒用户感觉不到动画，高于 800 毫秒就会开始觉得"怎么还没完"。

6.3 打断机制与完整代码

完整实现如下，包含打断、取消和与滚动位置同步的处理：

function smoothBackToTop(options = {}) { const { container = document.scrollingElement || document.documentElement, easing = easings.easeOutCubic } = options; const start = container.scrollTop; if (start <= 0) return () => {}; const distance = start; const duration = calcDuration(distance); const startTime = performance.now(); let rafId = null; let cancelled = false; function cancel() { if (cancelled) return; cancelled = true; if (rafId !== null) cancelAnimationFrame(rafId); // 移除打断监听，避免监听器堆积 window.removeEventListener('wheel', cancel); window.removeEventListener('touchstart', cancel); } function step(now) { if (cancelled) return; const elapsed = now - startTime; const progress = Math.min(elapsed / duration, 1); container.scrollTop = start * (1 - easing(progress)); if (progress < 1) { rafId = requestAnimationFrame(step); } else { cancel(); } } // 用户一动手就让路，这是我们比原生方案强的地方 window.addEventListener('wheel', cancel, { passive: true }); window.addEventListener('touchstart', cancel, { passive: true }); rafId = requestAnimationFrame(step); return cancel; }

几个关键点值得单独说。第一，start * (1 - easing(progress))这个写法保证最终位置精确落在 0，不会因为浮点误差停在 0.3 上。第二，cancel里的removeEventListener必须写，否则每次点击都往wheel上挂一个监听器，用户点十次就挂十个，全都在等同一个事件，内存和性能都白扔。第三，wheel和touchstart都加了passive: true，这是滚动相关监听的标准做法，不加会让滚动变卡。第四，cancel()被返回出去，调用方可以主动中断，比如在路由跳转前调用一下，避免动画还在跑的时候组件已经卸载。

提示：如果滚动容器是个 div，wheel事件依然会冒泡到 window 上（除非中间有stopPropagation），所以打断监听挂在 window 上是可行的。但如果容器内嵌了 iframe，事情就复杂了，touchstart在 iframe 内部的滚动不会冒泡出来，需要额外处理。

7. 按钮什么时候出现：滚动监听、节流与 IntersectionObserver

7.1 scroll + rAF 节流的老办法

按钮不能一开始就杵在那儿，通常是滚过第一屏之后才淡入。最朴素的实现是监听scroll事件读scrollTop判断，但scroll事件的触发频率高得吓人，移动端滑动时一帧能来好几次，里面只要有一次强制同步布局（读scrollTop、offsetHeight这类），就会引发掉帧。

标准解法是用requestAnimationFrame做节流，保证每帧最多处理一次：

let ticking = false; const btn = document.querySelector('.back-to-top'); window.addEventListener('scroll', () => { if (ticking) return; ticking = true; requestAnimationFrame(() => { const scrolled = (document.scrollingElement || document.documentElement).scrollTop; btn.classList.toggle('is-visible', scrolled > window.innerHeight * 0.8); ticking = false; }); }, { passive: true });

这里passive: true不能省。它告诉浏览器"这个监听器不会调用preventDefault"，浏览器就可以在滚动线程上直接处理，不必等主线程空闲。省掉这个参数，滚动流畅度会有肉眼可见的下降，尤其在低端安卓机上。

阈值我习惯设成视口高度 * 0.8而不是固定的 600px，因为视口高度差异太大了，手机上 600px 可能已经是三屏了，桌面上还不到一屏。用相对值更合理。

7.2 IntersectionObserver 哨兵方案

更好的办法是干脆不监听滚动。在页面顶部放一个哨兵元素，用IntersectionObserver观察它是否可见，不可见就说明用户已经滚下去了，按钮该出来。

<div id="top-sentinel" aria-hidden="true"></div>

const sentinel = document.getElementById('top-sentinel'); const btn = document.querySelector('.back-to-top'); const io = new IntersectionObserver((entries) => { const entry = entries[0]; btn.classList.toggle('is-visible', !entry.isIntersecting); }, { threshold: 0 }); io.observe(sentinel);

哨兵元素不需要高度，1px 就够（高度为 0 的元素在某些环境下可能不产生交叉计算），用 CSS 给它height: 1px并position: absolute掉出布局流。

这套方案的优点非常明显：不用读scrollTop，不触发强制同步布局，不用手写节流逻辑，观察回调由浏览器在空闲时批量派发。而且它天生支持"滚动容器不是 window"的场景——只要给 observer 传root参数指定容器即可：

const io = new IntersectionObserver(handler, { root: scrollContainer, // 不传则默认视口 threshold: 0 });

这是它比监听 scroll 事件强出一大截的地方。用scroll事件方案时，你得先想办法找到真正在滚的那个容器，再给它绑监听，一旦容器变了还要重新绑。IntersectionObserver只要把root换掉就行。

7.3 两种方案的性能与维护成本对照

精度这一项是IntersectionObserver唯一的劣势。它只能回答"哨兵元素看不看得见"，回答不了"已经滚了 1234px"。如果你的显示条件就是"滚过第一屏"，那完全够用；如果条件是"滚过 60% 页面高度"，就得调整哨兵的位置——比如把哨兵放在页面 60% 高度处，或者干脆用scroll方案。

我的实际选择：控制按钮显隐用IntersectionObserver，需要精确滚动数值做其他效果（比如顶部导航的进度条）时才用scroll事件。两者可以在同一个页面上共存，各司其职，不冲突。

8. 样式、层级与可访问性的细节清单

8.1 定位、安全区与过渡动画

按钮的 CSS 看起来简单，但有几个地方不做就会显得"业余"。

.back-to-top { position: fixed; right: 24px; bottom: calc(24px + env(safe-area-inset-bottom, 0px)); z-index: 900; width: 48px; height: 48px; border: none; border-radius: 50%; background: rgba(0, 0, 0, 0.72); color: #fff; cursor: pointer; opacity: 0; visibility: hidden; transform: translateY(12px) scale(0.92); transition: opacity 0.22s ease, transform 0.22s ease, visibility 0.22s; pointer-events: none; } .back-to-top.is-visible { opacity: 1; visibility: visible; transform: translateY(0) scale(1); pointer-events: auto; }

几个关键决定。用visibility而不是display: none，因为display不能参与过渡，会出现"啪一下出现"的硬切。但光有opacity: 0不够，隐藏状态下元素仍然挡在页面上会拦截点击，所以要配pointer-events: none。visibility: hidden的作用是让元素同时从无障碍树和 Tab 顺序里消失，避免用户 Tab 到一个看不见的按钮上。

safe-area-inset-bottom处理的是全面屏底部的横条区域，不处理的话按钮会压在那个小白条上，手机上根本点不准。env()第二个参数是兜底值，老环境里不支持会退回 0。

尺寸 48×48 不是随便定的。可点击区域建议不小于 44×44，这是触屏操作的基本门槛，低于这个值误触率会明显上升。我见过不少页面做成 32×32 的小圆圈，鼠标操作勉强能用，手机上纯靠运气。

8.2 焦点管理与语义标签

这部分几乎没人做，但做了之后体验会有质的提升。

先说标签。用<button type="button">而不是<a>。它不改变 URL、不参与历史记录、原生支持键盘空格和回车触发，语义上也更准确。加一个aria-label，因为按钮里通常是个纯图标：

<button type="button" class="back-to-top" aria-label="回到页面顶部"> <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24" width="20" height="20"> <path d="M12 4l-8 8h5v8h6v-8h5z" fill="currentColor"/> </svg> </button>

aria-hidden="true"挂在 svg 上，读屏软件就不会去念那个没有意义的图形路径，只念aria-label的文字。focusable="false"是给某些老内核的 svg 用的，避免它自己进入 Tab 序列。

再说焦点。用户点击"回到顶部"之后，视觉上到了页面开头，但键盘用户的焦点还停在页面底部的按钮上。这时候按一下 Tab，焦点会跑到按钮后面的下一个元素去，用户完全迷失。正确做法是滚动完成后把焦点移到页面顶部的标题或一个tabindex="-1"的容器上：

function backToTopWithFocus() { const cancel = smoothBackToTop(); const heading = document.querySelector('main h1') || document.querySelector('main'); if (heading) { heading.setAttribute('tabindex', '-1'); // 滚动结束后再移焦点，否则部分环境会把焦点滚动覆盖掉 setTimeout(() => heading.focus({ preventScroll: true }), 500); } return cancel; }

focus({ preventScroll: true })里的preventScroll很重要，不加的话，focus()自己会再触发一次滚动定位，把刚才的动画结果覆盖掉，页面可能又跳一下。

9. 踩坑实录：八个真实场景与排查路径

9.1 常见问题速查表

最后一条值得展开说一下。现代浏览器有个"滚动位置恢复"机制：用户刷新页面时，浏览器会尝试把滚动条恢复到刷新前的位置。这个行为在多数场景下是好功能，但它会让你的"回到顶部"显得很奇怪——用户点回顶部、刷新、又回到了中间位置。如果你的页面是单页应用，或者内容会动态变化（刷新后高度和原来不一样），这个恢复行为基本是有害的。在应用初始化时加一句if ('scrollRestoration' in history) history.scrollRestoration = 'manual';就能关掉。

9.2 我个人的几条经验

第一条，先确定滚动容器，再选写法。顺序反了会浪费大量时间。我现在拿到这类需求，第一件事是在控制台跑document.scrollingElement.scrollTop，确认滚动发生在文档层级还是某个 div 上。这一步花十秒，能省下后面半小时的瞎猜。

第二条，别在滚动回调里做任何布局读取之外的事。scroll事件里写 DOM 修改（改 class 除外）、写样式计算、调用会触发重排的 API，都会让滚动变卡。要改就丢进requestAnimationFrame，或者只改 class 让 CSS 去做动画。

第三条，平滑滚动的时长要跟着距离走。固定 300 毫秒在长页面上快得看不清，短距离上慢得着急。按第 6.2 节那个公式算，成本几行代码，观感提升非常明显。

第四条，测试一定要在真机上做。桌面浏览器上跑得再顺，到了移动端 WebView 里可能完全是另一回事。scrollTo的对象参数在某些定制内核里静默失效、scroll-behavior被系统或框架的全局样式覆盖、fixed定位在软键盘弹出时错位，这些问题只有在真机上点几下才会暴露。我现在的习惯是：这类跟滚动相关的交互，写完先在两个不同品牌的手机上看一遍，再考虑交付。

第五条，给用户一个可中断的出口。任何超过 300 毫秒的动画，都必须允许用户用滚轮、触摸或拖拽打断。动画是服务用户的，不是让用户等的。这一点上，手写requestAnimationFrame方案有天然优势，因为你能精确控制什么时候停、停在哪里。