htmltop跳转到头部

页面滚到一半，跳头部右下角弹出个“回到顶部”的跳头部小按钮，点一下，跳头部唰地滑回最上面。跳头部这功能太常见了，跳头部常见到很多人觉得它天生就该在那儿。跳头部但如果你自己动手写过一个带这种按钮的跳头部页面，就知道这事没那么简单——尤其是跳头部当页面用了锚点跳转，或者你试图用纯CSS去实现的跳头部时候。

先说说最原始的跳头部做法。HTML里有个东西叫锚点，跳头部<a href="#">，跳头部点一下浏览器就会把滚动条拉到文档顶部。跳头部这办法古老、跳头部直接、跳头部零JavaScript。但它有个副作用：URL末尾会多出一个#，而且如果页面本身用了hash做路由，比如Vue或React的history模式之外的场景，这一下可能把当前路由状态给冲掉。我就吃过这个亏——一个单页应用里放了返回顶部的按钮，用户点完，页面确实上去了，但URL变了，前端路由监听hash变化，直接跳到了首页。用户一脸懵，我也一脸懵。

后来改用JavaScript。window.scrollTo(0, 0)，一行搞定。但直接这么写，滚动是瞬间完成的，生硬得像被人拽上去。加个behavior: 'smooth'就顺滑多了：

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

这行代码在Chrome、Firefox、Safari里都跑得通。但如果你要兼容IE——虽然现在说IE有点考古——那就得自己写动画函数，用requestAnimationFrame一帧一帧把scrollTop减下去。我抽屉里还留着那段代码，每次翻出来都觉得，当年为了一个“回到顶部”写几十行，真是够执着的。

再说按钮本身的出现时机。很多网站的做法是：页面一加载，按钮就在那儿，只是透明不可见。滚动超过一屏，加个class让它淡入。这逻辑没问题，但监听scroll事件得注意性能。早期我用window.onscroll直接判断scrollTop > 300，页面一滚，回调疯狂触发，主线程被占得死死的。后来学会用throttle，或者干脆用IntersectionObserver去观察页面顶部的一个哨兵元素——哨兵离开视口，按钮出现；哨兵回来，按钮消失。这方案干净，不碰scroll事件，浏览器自己调度，省心。

有个细节容易被忽略：按钮固定在右下角，用position: fixed。但如果页面有transform的祖先元素，fixed会失效，变成相对那个祖先定位。我见过一个后台管理系统，侧边栏用了transform: translateX做动画，结果“回到顶部”按钮跟着侧边栏一起滑走了。排查了半天，最后把按钮挪到body直接子级才解决。

还有锚点跳转和“回到顶部”的冲突。页面里如果有<a name="top">或者id="top"的元素，用href="#top"也能跳。但浏览器对#top有个特殊处理：如果文档里没有id="top"的元素，它会默认跳到文档最顶部。这算是个隐藏福利，但依赖它不太靠谱，万一哪天你在页面里真加了个id="top"的