顶部导航栏这个组件几乎每个前端都写过透明底、白字、压在整屏头图上的那种做法视觉上确实舒服。但这一步也是最容易翻车的地方滚动之后导航栏还是透明白色标题压在白色正文上用户以为导航丢了或者为了省事直接给导航栏一个常驻白底头图那点沉浸感瞬间没了。这篇文章要聊的就是把这个闭环补上——js 实现顶部导航栏随着滚动条下滑显示背景颜色上划到顶部背景颜色消失。说到底就是两件事页面滚下去了导航栏该有个底滚回顶部了导航栏该把底交还给头图。技术上看它很小但真要做到手感自然、真机不抖、性能不拖后腿中间能踩的坑一点不少。这篇内容适合三类人正在练手、想搞懂事件与 DOM 状态联动的前端新人接手了老项目、导航栏用onscroll写得比较粗暴、需要改造的同学以及做官网、作品集、活动页这类以头图吸睛的站点、对视觉细节有要求的开发者。下面我会从需求拆解讲到三种实现路线再到真机上的具体问题包含可直接复制的代码、参数怎么算、以及我自己踩过的坑。1. 先把这个需求拆干净它到底在解决什么1.1 透明导航的视觉诉求与可读性代价导航栏做透明本质上是让首屏那张头图或者首屏视频能完整地铺满视口不被一条 64px 高的白色横条切掉。这不是纯粹的审美问题而是留白和构图问题——一张全幅图被顶部切掉一条视觉重心的位置就变了很多设计稿里把标题放在画面下半部就是为了给导航栏留出透明区。所以首页导航栏透明是有明确的设计意图的不是设计师随便定的。但透明导航的代价也很直接它只在“背景足够暗或足够均匀”的前提下成立。一旦页面往下滚导航栏底下压的就不再是那张精心调过对比度的头图而是正文、表格、图片、代码块颜色完全不可控。白字压在浅灰正文上对比度可能只有 1.2:1基本等于隐形。这就是为什么几乎所有带透明导航的站点都会在滚动后切回实底——这不是锦上添花是可用性补救。顺带说一个很多人忽略的点即使切成了实底也要保证这个实底本身是不透明的或者足够不透明。我见过用rgba(255,255,255,0.6)做背景的滚到彩色图片区域时导航栏文字后面透出一片花色仍然看不清。经验值是不透明度至少到 0.85 以上正文正常流下的可读性才稳。1.2 别把“回到顶部变透明”误读成“按方向隐藏”这个标题容易被误读。“随着滚动条下滑显示背景颜色上划到顶部背景颜色消失”前半句是位置判断后半句限定得很清楚——上划到顶部才消失不是“上划就消失”。它描述的是滚动位置的状态机而不是滚动方向的状态机。这两种东西长得很像实现逻辑完全不同。位置驱动只需要读一个值scrollY是否大于阈值。方向驱动要额外记录上一次的滚动位置比较大小来判断方向而且通常还要求“向下滚才出效果、向上滚才收效果”逻辑分支多一倍手感也更难调。有些站点做的是“向下滚隐藏导航栏、向上滚显示导航栏”那是另一套交互用户往上翻找内容时导航栏会突然冒出来遮住两行字争议比较大。所以第一步先确认需求边界你要的到底是“滚过阈值变色”还是“滚过阈值变色 向上滚出现、向下滚隐藏”。这两件事可以叠加但要分开写、分开测。我建议先只做位置驱动跑通之后再考虑要不要加方向逻辑否则两个状态混在一起出问题时很难判断是阈值算错了还是方向判断错了。1.3 三条技术路线先选对再写代码同一个效果现在至少有三种主流写法选哪条取决于你的项目环境和对兼容性的容忍度。第一种是滚动事件监听监听scroll事件、读滚动位置、切 class。兼容性最好IE 之后的浏览器全支持能精确控制阈值和迟滞缺点是每个滚动帧都要跑一次回调写不好会影响滚动流畅度。第二种是IntersectionObserver 加哨兵元素在页面顶部放一个占位元素观察它是否还和视口交叉。好处是完全不需要监听滚动由浏览器在合成线程附近判断主线程压力几乎为零缺点是阈值控制依赖哨兵元素的高度改参数要改 DOM 或 CSS稍微绕一点。第三种是CSS 滚动驱动动画animation-timeline: scroll()纯 CSS 声明连 JS 都不用。好处是滚动和动画完全同步、不掉帧缺点是它属于比较新的能力支持范围有限必须配降级方案。我的默认选择是主体用 IntersectionObserver滚动监听作为兼容兜底。原因很简单导航栏变色是个纯视觉状态没有“每帧都要跟进”的需求——从 0 到 60px 只需要切一次从 60px 回来也只需要切一次。为一个离散的状态切换去监听每一帧的滚动本身就是资源浪费。方案主线程开销阈值精度兼容范围适用场景scroll 事件监听中每帧回调高可任意微调几乎全支持老项目、需要复杂逻辑IntersectionObserver极低中靠哨兵高度现代浏览器全支持新项目首选CSS 滚动驱动动画无高可用 range 精确控制较新需降级纯视觉、无交互联动2. 结构先行HTML 与样式的准备工作2.1 导航栏的骨架和层级安排在写 JS 之前先把 DOM 定好后面能省很多事。我的习惯是导航栏单独抽出来放在body的最前面和主内容平级而不是塞在某个header容器里。原因是后面要用position: fixed或者sticky包在带overflow: hidden或者transform的父级里fixed 的定位参照会变表现会很诡异——这个坑我在好几个项目里都撞过尤其是父级为了做入场动画加了个transform: translateY(0)结果整个 fixed 导航跟着父级走了。骨架大致是这样nav classsite-nav idsiteNav aria-label主导航 div classsite-nav__inner a classsite-nav__logo href/站点标识/a ul classsite-nav__links lia href/docs文档/a/li lia href/cases案例/a/li /ul /div /nav section classhero h1 classhero__title首屏标题/h1 /section main classcontent ... /main有两个细节值得说。一是给导航加aria-label屏幕阅读器会把这块识别为导航地标跳转更顺畅二是导航内部再套一层__inner用来做宽度约束和水平内边距导航本身负责定位和背景内层负责布局职责分开后面给导航加backdrop-filter或者阴影时不会影响内容宽度。还有一点如果页面要做锚点跳转点击导航里的“文档”跳到某个区块scroll-margin-top一定要给跳转目标加上值大致等于导航栏高度加一点余量。不处理的话跳过去之后标题正好被导航栏压住这个体验问题比变色严重得多但经常被一起忽略。2.2 用 CSS 变量管好三套配色状态切换靠的是类名但配色不要散落在各处。我一般的做法是把导航栏的几套视觉参数抽成 CSS 变量is-scrolled这个类只负责改变量的值具体的颜色、阴影、描边统一从变量取。这样后续想调整比如品牌色改了、想把白色换成深色只改一处。:root { --nav-h: 64px; --nav-bg: transparent; --nav-color: #fff; --nav-shadow: none; --nav-border: transparent; } .site-nav { position: fixed; inset: 0 0 auto 0; height: var(--nav-h); display: flex; align-items: center; background-color: var(--nav-bg); color: var(--nav-color); box-shadow: var(--nav-shadow); border-bottom: 1px solid var(--nav-border); transition: background-color .25s ease, box-shadow .25s ease, border-color .25s ease; z-index: 100; } .site-nav.is-scrolled { --nav-bg: rgba(255, 255, 255, .92); --nav-color: #1b1b1f; --nav-shadow: 0 1px 2px rgba(0, 0, 0, .06), 0 8px 24px rgba(0, 0, 0, .06); --nav-border: rgba(0, 0, 0, .06); } .site-nav__inner { width: min(1200px, 100% - 48px); margin-inline: auto; display: flex; align-items: center; justify-content: space-between; }几个参数不是随手写的。过渡时间选 250ms 是折中低于 150ms 感觉像硬切超过 400ms 会觉得导航“反应慢半拍”250ms 左右在感知上刚好是“顺手一滑就变好了”。阴影用了两层叠加一层 1px 贴边模拟分隔线一层 24px 的扩散做空间感单层阴影要么太硬要么太糊。边框用 1px 半透明而不是纯色是为了在不同背景上都不刺眼。变量方案还有个额外好处如果要做深浅色主题只需要在prefers-color-scheme: dark里重新定义.is-scrolled下的四个变量不用重写一遍选择器。2.3 fixed 还是 sticky这一步选错后面全是补丁这是我在代码评审里见得最多的问题。position: sticky看起来更“现代”不脱流、不需要补padding-top很多人直接上 sticky。但它有两个硬性前提父级链上不能有overflow不为visible的元素且 sticky 元素的高度会被限制在父容器内。导航栏这种“全站唯一、贯穿始终”的元素父级如果是body通常没问题但如果你把导航包在了某个.page容器里而这个容器为了做入场动画设了overflow: hiddensticky 立刻失效滚动时导航栏直接跟着页面滚走了。而且这种失效是静默的控制台不报错只能靠肉眼发现。position: fixed的代价是要手动给主内容补顶部内边距否则第一屏内容会被导航栏盖住。但这个代价是显式的、可控的写一行padding-top: var(--nav-h)就解决了。所以我现在的默认选择是 fixed除了极少数“导航栏只在某个区域内吸顶”的场景才用 sticky。提示如果用了 fixed记得在media print里把导航改回position: static或者直接display: none否则打印出来每页顶部都压着一条导航很难看。3. 核心实现滚动监听版本从能跑到跑稳3.1 最小可用版本与阈值怎么定先写一个能跑的版本再优化。逻辑非常朴素读滚动距离超过阈值就加类否则移除。const nav document.getElementById(siteNav); const THRESHOLD 60; function getScrollTop() { return window.scrollY ?? document.documentElement.scrollTop ?? 0; } function updateNav() { const y getScrollTop(); nav.classList.toggle(is-scrolled, y THRESHOLD); } window.addEventListener(scroll, updateNav, { passive: true }); updateNav(); // 首屏和刷新恢复滚动位置时同步一次阈值 60 不是拍脑袋。它应该和“导航栏高度”以及“首屏第一个正文块的上边距”挂钩。假设导航栏是 64px 高正文第一段距离顶部有 24px 内边距那么页面滚到 60px 左右时正文内容正好进入导航栏所在的条带此时变色视觉上最连贯——用户不会看到“内容已经贴上来了但导航还是透明的”这个空档。如果阈值设成 0那么滚动 1px 就变色用户会觉得稍微动一下鼠标滚轮导航就“啪”地换了颜色很突兀。如果页面顶部是整屏头图另一个常见做法是让阈值等于头图的高度减去导航栏高度这样变色发生在头图刚好滚出导航区域的瞬间观感也很自然。这个值不用精确到像素取整到 10 的倍数就行人眼分辨不出来。注意window.scrollY在极老的环境里不存在用document.documentElement.scrollTop兜底。另外 iOS 顶部橡皮筋回弹时scrollY会是负数虽然对 THRESHOLD的判断没影响但如果你后面要算百分比或者做别的逻辑记得先Math.max(0, y)。3.2 用 rAF 和 passive 把主线程压力降下来上面那段代码功能没问题但有个隐患scroll事件的触发频率在移动端惯性滚动时可以到每秒上百次每次回调都做一次classList.toggle虽然 toggle 内部有优化值没变时不修改 DOM但函数调用和取值本身还是有开销。更重要的是如果以后有人在updateNav里加了getBoundingClientRect()之类的读取就会触发强制布局滚动立刻掉帧。标准做法是用requestAnimationFrame做合并事件回调里只记录“需要更新”这个标记真正的计算放到下一帧。let ticking false; function onScroll() { if (ticking) return; ticking true; requestAnimationFrame(() { ticking false; updateNav(); }); } window.addEventListener(scroll, onScroll, { passive: true });这里{ passive: true }是必须的。浏览器看到passive标记后就不需要等回调执行完再决定是否滚动滚动可以和回调并行移动端的顺滑度差别很明显。如果你的回调里确实需要preventDefault()这个场景不需要才应该关掉 passive。但要注意rAF合并本身也会带来一帧的延迟。对于导航变色这种视觉状态一帧约 16.7ms完全感知不到是值得的。如果做的是滚动视差这类“必须跟手”的效果那就不能这么合并得换 CSS 方案。还有一种更极致的写法用requestIdleCallback或者干脆只在值跨过阈值的那一帧才更新。思路是记录上一次的状态只有状态真的翻转时才碰 DOMlet lastState null; function updateNav() { const next Math.max(0, getScrollTop()) THRESHOLD; if (next lastState) return; lastState next; nav.classList.toggle(is-scrolled, next); }这个提前返回看着不起眼但它把 99% 的回调变成了“读一个数、比一次、直接 return”在高刷屏设备上省下的主线程时间相当可观。3.3 状态抖动和迟滞区间如果你把阈值设得很低比如 4px会看到一个经典现象在阈值附近轻微滑动滚轮导航栏的背景色会疯狂闪烁。原因是浏览器的滚动位置不是整数触控板惯性滚动时会以亚像素级变化scrollY可能在三五个值之间反复跳动再加上某些浏览器的滚动锚定机制页面内容动态加载时会微调滚动位置也会造成阈值附近的振荡。解决办法就是控制里的迟滞hysteresis思路——进入和退出用两个不同的阈值。进入阈值高一点60退出阈值低一点比如 8中间形成一段“死区”在这个区间内状态保持不变。const ENTER 60; const EXIT 8; let solid false; function updateNav() { const y Math.max(0, getScrollTop()); if (!solid y ENTER) { solid true; nav.classList.add(is-scrolled); } else if (solid y EXIT) { solid false; nav.classList.remove(is-scrolled); } }这段逻辑看着比toggle啰嗦但它解决了两个问题。一是防抖用户从 100px 慢慢滚回 50px 时导航栏不会立刻变透明而是继续保持在实底状态直到滚到 8px 以内才交还透明度——视觉上更“沉稳”不会黏在阈值上闪。二是它把状态存在变量里而不是每次去读 DOM 的classList.contains避免读 DOM 带来的性能风险。迟滞区间的宽度没有绝对标准我一般取进入阈值的 10% 到 20%。60 配 8 是 13%比较常见。如果页面特别长、滚动速度快可以让死区更宽一点比如 60 配 20。3.4 初始化时机与那些“刷新后状态不对”的场景updateNav()第一次调用放在哪很讲究。放head里的同步脚本此时 DOM 还没解析出来getElementById拿到 null直接报错。放DOMContentLoaded之后比较稳妥但如果导航栏高度是动态的比如内容变了此时拿到的值可能还不准。更麻烦的是浏览器恢复滚动位置。用户滚到 800px 处按 F5 刷新现代浏览器会尽量把滚动位置恢复到 800px。这个过程可能发生在load之后也可能发生在DOMContentLoaded附近不同浏览器行为不一致。如果你的变色逻辑只绑在scroll事件上刷新后页面停在 800px 但scroll事件没触发过导航栏就维持透明的初始态用户看到的是一条透明的导航压在正文上。我一般会在三个时机各调一次初始化DOMContentLoaded、window.load、以及给window绑一个pageshow事件处理从缓存返回页面的情况即event.persisted为 true 的场景。function init() { updateNav(); } document.addEventListener(DOMContentLoaded, init); window.addEventListener(load, init); window.addEventListener(pageshow, (e) { if (e.persisted) init(); });pageshow这个事件值得单独说一句。用户从详情页按返回键回到列表页时浏览器可能直接从往返缓存里恢复页面此时DOMContentLoaded和load都不会再触发但滚动位置还保留着。不监听pageshow的话就会出现“返回之后导航栏是透明的但页面明显已经滚动过”的 bug。这个 bug 在移动端浏览器里出现率很高桌面端反而少见所以很容易在上线后才被发现。4. 更省事的两条路哨兵观察与滚动驱动动画4.1 IntersectionObserver 加哨兵元素如果你不想碰滚动事件最干净的做法是往页面顶部塞一个“哨兵”。这个元素固定在最上面高度等于你想要的阈值然后用IntersectionObserver观察它是否还和视口相交。它完全离开视口顶部的那一瞬间正是滚动距离越过阈值的一刻。div classnav-sentinel aria-hiddentrue/div.nav-sentinel { position: absolute; top: 0; left: 0; width: 1px; height: 60px; pointer-events: none; visibility: hidden; }const sentinel document.querySelector(.nav-sentinel); const nav document.getElementById(siteNav); const io new IntersectionObserver((entries) { for (const entry of entries) { nav.classList.toggle(is-scrolled, !entry.isIntersecting); } }, { threshold: 0 }); io.observe(sentinel);哨兵的高度直接就是阈值改参数只需要改一行 CSS比在 JS 里维护常量更直观设计师调整视觉方案时前端也不用跟着改逻辑。pointer-events: none是为了防止这个空元素挡住头图上的点击区域虽然它只有 1px 宽但高度有 60px如果不设很可能覆盖住某个按钮的边角。这个方案的迟滞问题也天然解决了isIntersecting是个布尔值浏览器内部判断交叉与否有一点点缓冲不会在临界点上反复横跳。我在几个长列表页面实测过比手写阈值稳。需要留个心如果哨兵放在一个position: relative的容器里top: 0是相对那个容器的不是相对文档顶部。要么确保它在body的直接子级要么把容器设成position: static。4.2 CSS 滚动驱动动画与降级最新的一批浏览器开始支持滚动驱动动画能用纯 CSS 把“滚动进度”映射到“背景色”一行 JS 都不用写。supports (animation-timeline: scroll()) { .site-nav { animation: navSolid linear both; animation-timeline: scroll(root block); animation-range: 0 60px; } keyframes navSolid { from { background-color: rgba(255, 255, 255, 0); box-shadow: none; } to { background-color: rgba(255, 255, 255, .92); box-shadow: 0 1px 2px rgba(0, 0, 0, .06); } } }animation-range: 0 60px的意思是滚动位置在 0 到 60px 之间完成整个动画超过 60px 就停在末态。这比 JS 版本还多了一个好处——它是连续的背景可能在 30px 时是半透明视觉过渡比“两个状态二选一”更细腻。但一定要包在supports里。不支持的环境下这段样式会被整体忽略此时由 JS 方案接盘。也就是说前面写的is-scrolled类和滚动监听代码要保留作为降级路径。这也是我推荐“JS 兜底 现代方案增强”这套组合的原因用户看到的效果不会有落差只是过渡的细腻程度不同。有一点要特别注意滚动驱动动画和is-scrolled类如果同时生效会互相打架——类的背景色和动画的背景色会有一方被覆盖。要么在supports生效时把 JS 版本停掉用CSS.supports()做特性检测要么让动画只作用于一个不影响类的属性。我一般用前者逻辑清晰。4.3 滚动容器不是 window 时怎么改前面所有讨论都默认滚动发生在整个文档上但现实里有一类很常见的布局body设了overflow: hidden真正滚动的是中间一个overflow-y: auto的容器导航栏固定在这个容器的顶部。这种“应用壳”布局在后台管理系统里到处都是。此时window.scrollY永远是 0滚动事件也不在window上触发前面写的监听全部失效。要改两处监听目标变成那个容器元素取值变成container.scrollTop。const scroller document.querySelector(.app-scroll); function getScrollTop() { return scroller.scrollTop; } scroller.addEventListener(scroll, onScroll, { passive: true });用IntersectionObserver的话需要把root指定成这个容器const io new IntersectionObserver(cb, { root: scroller, threshold: 0 });这里最容易被忽略的是“导航栏到底在不在滚动容器里面”。如果导航栏是容器的兄弟节点在容器外面那固定它没问题如果导航栏在容器内部那它会被容器的滚动带上去position: fixed也会因为容器的overflow而表现异常。比较稳的结构是把导航栏放在滚动容器外面容器只负责内容区的滚动。我在一个后台项目里重构过这个问题改结构比改代码省事得多。5. 真机上的坑移动端与浏览器差异5.1 地址栏收缩带来的高度跳变移动端浏览器的地址栏会随着滚动方向自动收起和展开这会导致视口高度在滚动过程中发生变化。如果你的导航栏高度、首屏高度或者阈值是用vh或者window.innerHeight算出来的就会出现一种诡异现象往下滚时地址栏收起视口变高innerHeight变大如果阈值是跟着它算的导航栏的变色时机就会跟着漂移。解决的思路是让阈值依赖固定像素而不是视口比例。前面把阈值定成 60px 就是这个原因它不会因为地址栏高度变化而变。如果确实需要用视口高度优先用dvh动态视口单位它比vh更贴合实际可视区域现代移动浏览器支持都不错.hero { min-height: 100dvh; }另外如果你需要精确知道可视区尺寸的变化可以监听window.visualViewport的resize事件它比window.resize更准确地反映移动端的可视变化。但这个事件触发频率也不低记得同样用 rAF 合并。5.2 毛玻璃与合成层的性能账现在很流行给滚动后的导航栏加一层毛玻璃backdrop-filter: blur(...)效果确实高级。但这一步的性能代价很多人在桌面开发机上完全感觉不到一到中低端安卓机就露馅滚动时整个页面的帧率明显下降甚至出现导航栏区域的色块闪烁。原因是backdrop-filter需要实时采样它背后的内容并做模糊浏览器会为这个元素建一个合成层每一帧都要重新计算。滚动时背景内容在变模糊结果也得跟着重算。如果导航栏下面还有别的动画元素开销会叠加。我的处理办法是分档桌面端和高性能设备开模糊其他环境降级成高不透明度的纯色。.site-nav.is-scrolled { background-color: rgba(255, 255, 255, .96); } media (min-width: 768px) and (prefers-reduced-motion: no-preference) { .site-nav.is-scrolled { background-color: rgba(255, 255, 255, .72); backdrop-filter: saturate(180%) blur(14px); } }顺手提醒一句will-change: transform和transform: translateZ(0)这种“强制提升图层”的写法不要满屏乱撒。图层提上去之后会常驻内存尤其是导航栏这种全站元素多留一层看着不多但配上其他动画元素低端机的内存压力就上来了。真要用就在变色过渡期间用过渡结束后撤掉。5.3 惯性滚动与回弹iOS 的滚动有惯性而且到了边界会回弹。回弹过程中scrollY会变成负值虽然前面用Math.max(0, y)兜住了但还有另一个现象回弹到负值的瞬间如果页面顶部本来就是透明的导航栏视觉上会出现一条小小的空隙在导航栏上方闪一下这通常是因为导航栏用了top: 0但页面本身有transform或者scroll-behavior造成的。检查一下html和body有没有多余的位移属性。还有一点scroll-behavior: smooth和滚动监听混用时要小心。点击锚点后页面会平滑滚动一段距离滚动事件连续触发导航栏会按部就班地变色这没问题。但如果平滑滚动的终点刚好在阈值附近过渡动画还没播完滚动就停了is-scrolled可能停在中间态。稳妥的做法是在滚动结束后再主动调用一次updateNav()用scrollend事件支持度有限或者一个短延时兜底。6. 问题排查速查表与实操心得6.1 症状对照表下面这张表是我这几年遇到过的具体问题按“症状 → 大概率原因 → 处理方式”整理出问题的时候可以先按这张表过一遍比从代码第一行开始读快得多。症状大概率原因处理方式刷新后导航栏一直透明只绑了 scroll没做初始化在DOMContentLoaded、load、pageshow各调一次更新变色时闪一下、来回跳阈值设太低或没有迟滞区进 60 出 8用状态变量记录当前状态滚动明显卡顿回调里有布局读取或没加 passive用 rAF 合并读值集中在一处移动端变色时机“漂移”阈值依赖innerHeight或vh改用固定像素阈值fixed 导航跟着页面滚走祖先元素有transform或filter把导航提到 body 直接子级平滑滚动后状态停在中间动画结束时状态未同步滚动结束后补一次更新后台系统里完全不生效实际滚动的是内部容器改监听目标与 IntersectionObserver 的 root导航文字压在浅色正文上看不清背景不透明度不够不透明度提到 0.85 以上6.2 几条踩出来的经验第一把“颜色”和“布局”分开测。我调试这类问题时习惯先把变色逻辑用一条醒目的红色边框验证确认状态切换的时机对不对再去调颜色和过渡。混在一起调很容易把“阈值不对”误判成“颜色不对”。第二别在滚动回调里做任何可能触发重排的事。读scrollY、scrollTop是安全的读offsetHeight、getBoundingClientRect()就可能触发同步布局。如果确实需要尺寸在页面加载和resize时取一次缓存起来滚动回调里只用缓存值。第三给导航栏变色这件事配一个可关闭的开关。有些用户开了“减少动态效果”prefers-reduced-motion: reduce过渡动画对他们来说可能是干扰。这种情况下我会把transition去掉直接硬切功能不受影响但体验更温和。第四组件化项目里注意解绑。在框架里写这段逻辑监听和观察器都要在组件卸载时清理掉否则单页应用频繁切换路由会累积一堆监听器。IntersectionObserver记得disconnect()scroll事件记得removeEventListener并且传入的必须是同一个函数引用——用匿名函数是解绑不掉的这个错误我见过太多次。第五真机测试不能省。桌面浏览器把窗口缩小模拟移动端和真机是两回事。地址栏行为、惯性滚动、backdrop-filter的性能、pageshow的触发只有真机上才会暴露出来。我现在的习惯是代码写完先在一台中端安卓机上滚两分钟没问题再上桌面验收。最后分享一个我认为性价比最高的做法这个效果本质上是给导航栏加一个“是否已经离开页面顶部”的布尔状态。一旦你这么理解就会发现它不该写在滚动回调里也不该和滚动距离绑定得太死。用哨兵元素 IntersectionObserver表达这个布尔代码量最少、性能最好、也最不容易出错。至于那些需要精确控制阈值的少数场景再退回滚动监听配合 rAF 和迟滞一样能跑得很稳。
顶部导航栏这个组件几乎每个前端都写过透明底、白字、压在整屏头图上的那种做法视觉上确实舒服。但这一步也是最容易翻车的地方滚动之后导航栏还是透明白色标题压在白色正文上用户以为导航丢了或者为了省事直接给导航栏一个常驻白底头图那点沉浸感瞬间没了。这篇文章要聊的就是把这个闭环补上——js 实现顶部导航栏随着滚动条下滑显示背景颜色上划到顶部背景颜色消失。说到底就是两件事页面滚下去了导航栏该有个底滚回顶部了导航栏该把底交还给头图。技术上看它很小但真要做到手感自然、真机不抖、性能不拖后腿中间能踩的坑一点不少。这篇内容适合三类人正在练手、想搞懂事件与 DOM 状态联动的前端新人接手了老项目、导航栏用onscroll写得比较粗暴、需要改造的同学以及做官网、作品集、活动页这类以头图吸睛的站点、对视觉细节有要求的开发者。下面我会从需求拆解讲到三种实现路线再到真机上的具体问题包含可直接复制的代码、参数怎么算、以及我自己踩过的坑。1. 先把这个需求拆干净它到底在解决什么1.1 透明导航的视觉诉求与可读性代价导航栏做透明本质上是让首屏那张头图或者首屏视频能完整地铺满视口不被一条 64px 高的白色横条切掉。这不是纯粹的审美问题而是留白和构图问题——一张全幅图被顶部切掉一条视觉重心的位置就变了很多设计稿里把标题放在画面下半部就是为了给导航栏留出透明区。所以首页导航栏透明是有明确的设计意图的不是设计师随便定的。但透明导航的代价也很直接它只在“背景足够暗或足够均匀”的前提下成立。一旦页面往下滚导航栏底下压的就不再是那张精心调过对比度的头图而是正文、表格、图片、代码块颜色完全不可控。白字压在浅灰正文上对比度可能只有 1.2:1基本等于隐形。这就是为什么几乎所有带透明导航的站点都会在滚动后切回实底——这不是锦上添花是可用性补救。顺带说一个很多人忽略的点即使切成了实底也要保证这个实底本身是不透明的或者足够不透明。我见过用rgba(255,255,255,0.6)做背景的滚到彩色图片区域时导航栏文字后面透出一片花色仍然看不清。经验值是不透明度至少到 0.85 以上正文正常流下的可读性才稳。1.2 别把“回到顶部变透明”误读成“按方向隐藏”这个标题容易被误读。“随着滚动条下滑显示背景颜色上划到顶部背景颜色消失”前半句是位置判断后半句限定得很清楚——上划到顶部才消失不是“上划就消失”。它描述的是滚动位置的状态机而不是滚动方向的状态机。这两种东西长得很像实现逻辑完全不同。位置驱动只需要读一个值scrollY是否大于阈值。方向驱动要额外记录上一次的滚动位置比较大小来判断方向而且通常还要求“向下滚才出效果、向上滚才收效果”逻辑分支多一倍手感也更难调。有些站点做的是“向下滚隐藏导航栏、向上滚显示导航栏”那是另一套交互用户往上翻找内容时导航栏会突然冒出来遮住两行字争议比较大。所以第一步先确认需求边界你要的到底是“滚过阈值变色”还是“滚过阈值变色 向上滚出现、向下滚隐藏”。这两件事可以叠加但要分开写、分开测。我建议先只做位置驱动跑通之后再考虑要不要加方向逻辑否则两个状态混在一起出问题时很难判断是阈值算错了还是方向判断错了。1.3 三条技术路线先选对再写代码同一个效果现在至少有三种主流写法选哪条取决于你的项目环境和对兼容性的容忍度。第一种是滚动事件监听监听scroll事件、读滚动位置、切 class。兼容性最好IE 之后的浏览器全支持能精确控制阈值和迟滞缺点是每个滚动帧都要跑一次回调写不好会影响滚动流畅度。第二种是IntersectionObserver 加哨兵元素在页面顶部放一个占位元素观察它是否还和视口交叉。好处是完全不需要监听滚动由浏览器在合成线程附近判断主线程压力几乎为零缺点是阈值控制依赖哨兵元素的高度改参数要改 DOM 或 CSS稍微绕一点。第三种是CSS 滚动驱动动画animation-timeline: scroll()纯 CSS 声明连 JS 都不用。好处是滚动和动画完全同步、不掉帧缺点是它属于比较新的能力支持范围有限必须配降级方案。我的默认选择是主体用 IntersectionObserver滚动监听作为兼容兜底。原因很简单导航栏变色是个纯视觉状态没有“每帧都要跟进”的需求——从 0 到 60px 只需要切一次从 60px 回来也只需要切一次。为一个离散的状态切换去监听每一帧的滚动本身就是资源浪费。方案主线程开销阈值精度兼容范围适用场景scroll 事件监听中每帧回调高可任意微调几乎全支持老项目、需要复杂逻辑IntersectionObserver极低中靠哨兵高度现代浏览器全支持新项目首选CSS 滚动驱动动画无高可用 range 精确控制较新需降级纯视觉、无交互联动2. 结构先行HTML 与样式的准备工作2.1 导航栏的骨架和层级安排在写 JS 之前先把 DOM 定好后面能省很多事。我的习惯是导航栏单独抽出来放在body的最前面和主内容平级而不是塞在某个header容器里。原因是后面要用position: fixed或者sticky包在带overflow: hidden或者transform的父级里fixed 的定位参照会变表现会很诡异——这个坑我在好几个项目里都撞过尤其是父级为了做入场动画加了个transform: translateY(0)结果整个 fixed 导航跟着父级走了。骨架大致是这样nav classsite-nav idsiteNav aria-label主导航 div classsite-nav__inner a classsite-nav__logo href/站点标识/a ul classsite-nav__links lia href/docs文档/a/li lia href/cases案例/a/li /ul /div /nav section classhero h1 classhero__title首屏标题/h1 /section main classcontent ... /main有两个细节值得说。一是给导航加aria-label屏幕阅读器会把这块识别为导航地标跳转更顺畅二是导航内部再套一层__inner用来做宽度约束和水平内边距导航本身负责定位和背景内层负责布局职责分开后面给导航加backdrop-filter或者阴影时不会影响内容宽度。还有一点如果页面要做锚点跳转点击导航里的“文档”跳到某个区块scroll-margin-top一定要给跳转目标加上值大致等于导航栏高度加一点余量。不处理的话跳过去之后标题正好被导航栏压住这个体验问题比变色严重得多但经常被一起忽略。2.2 用 CSS 变量管好三套配色状态切换靠的是类名但配色不要散落在各处。我一般的做法是把导航栏的几套视觉参数抽成 CSS 变量is-scrolled这个类只负责改变量的值具体的颜色、阴影、描边统一从变量取。这样后续想调整比如品牌色改了、想把白色换成深色只改一处。:root { --nav-h: 64px; --nav-bg: transparent; --nav-color: #fff; --nav-shadow: none; --nav-border: transparent; } .site-nav { position: fixed; inset: 0 0 auto 0; height: var(--nav-h); display: flex; align-items: center; background-color: var(--nav-bg); color: var(--nav-color); box-shadow: var(--nav-shadow); border-bottom: 1px solid var(--nav-border); transition: background-color .25s ease, box-shadow .25s ease, border-color .25s ease; z-index: 100; } .site-nav.is-scrolled { --nav-bg: rgba(255, 255, 255, .92); --nav-color: #1b1b1f; --nav-shadow: 0 1px 2px rgba(0, 0, 0, .06), 0 8px 24px rgba(0, 0, 0, .06); --nav-border: rgba(0, 0, 0, .06); } .site-nav__inner { width: min(1200px, 100% - 48px); margin-inline: auto; display: flex; align-items: center; justify-content: space-between; }几个参数不是随手写的。过渡时间选 250ms 是折中低于 150ms 感觉像硬切超过 400ms 会觉得导航“反应慢半拍”250ms 左右在感知上刚好是“顺手一滑就变好了”。阴影用了两层叠加一层 1px 贴边模拟分隔线一层 24px 的扩散做空间感单层阴影要么太硬要么太糊。边框用 1px 半透明而不是纯色是为了在不同背景上都不刺眼。变量方案还有个额外好处如果要做深浅色主题只需要在prefers-color-scheme: dark里重新定义.is-scrolled下的四个变量不用重写一遍选择器。2.3 fixed 还是 sticky这一步选错后面全是补丁这是我在代码评审里见得最多的问题。position: sticky看起来更“现代”不脱流、不需要补padding-top很多人直接上 sticky。但它有两个硬性前提父级链上不能有overflow不为visible的元素且 sticky 元素的高度会被限制在父容器内。导航栏这种“全站唯一、贯穿始终”的元素父级如果是body通常没问题但如果你把导航包在了某个.page容器里而这个容器为了做入场动画设了overflow: hiddensticky 立刻失效滚动时导航栏直接跟着页面滚走了。而且这种失效是静默的控制台不报错只能靠肉眼发现。position: fixed的代价是要手动给主内容补顶部内边距否则第一屏内容会被导航栏盖住。但这个代价是显式的、可控的写一行padding-top: var(--nav-h)就解决了。所以我现在的默认选择是 fixed除了极少数“导航栏只在某个区域内吸顶”的场景才用 sticky。提示如果用了 fixed记得在media print里把导航改回position: static或者直接display: none否则打印出来每页顶部都压着一条导航很难看。3. 核心实现滚动监听版本从能跑到跑稳3.1 最小可用版本与阈值怎么定先写一个能跑的版本再优化。逻辑非常朴素读滚动距离超过阈值就加类否则移除。const nav document.getElementById(siteNav); const THRESHOLD 60; function getScrollTop() { return window.scrollY ?? document.documentElement.scrollTop ?? 0; } function updateNav() { const y getScrollTop(); nav.classList.toggle(is-scrolled, y THRESHOLD); } window.addEventListener(scroll, updateNav, { passive: true }); updateNav(); // 首屏和刷新恢复滚动位置时同步一次阈值 60 不是拍脑袋。它应该和“导航栏高度”以及“首屏第一个正文块的上边距”挂钩。假设导航栏是 64px 高正文第一段距离顶部有 24px 内边距那么页面滚到 60px 左右时正文内容正好进入导航栏所在的条带此时变色视觉上最连贯——用户不会看到“内容已经贴上来了但导航还是透明的”这个空档。如果阈值设成 0那么滚动 1px 就变色用户会觉得稍微动一下鼠标滚轮导航就“啪”地换了颜色很突兀。如果页面顶部是整屏头图另一个常见做法是让阈值等于头图的高度减去导航栏高度这样变色发生在头图刚好滚出导航区域的瞬间观感也很自然。这个值不用精确到像素取整到 10 的倍数就行人眼分辨不出来。注意window.scrollY在极老的环境里不存在用document.documentElement.scrollTop兜底。另外 iOS 顶部橡皮筋回弹时scrollY会是负数虽然对 THRESHOLD的判断没影响但如果你后面要算百分比或者做别的逻辑记得先Math.max(0, y)。3.2 用 rAF 和 passive 把主线程压力降下来上面那段代码功能没问题但有个隐患scroll事件的触发频率在移动端惯性滚动时可以到每秒上百次每次回调都做一次classList.toggle虽然 toggle 内部有优化值没变时不修改 DOM但函数调用和取值本身还是有开销。更重要的是如果以后有人在updateNav里加了getBoundingClientRect()之类的读取就会触发强制布局滚动立刻掉帧。标准做法是用requestAnimationFrame做合并事件回调里只记录“需要更新”这个标记真正的计算放到下一帧。let ticking false; function onScroll() { if (ticking) return; ticking true; requestAnimationFrame(() { ticking false; updateNav(); }); } window.addEventListener(scroll, onScroll, { passive: true });这里{ passive: true }是必须的。浏览器看到passive标记后就不需要等回调执行完再决定是否滚动滚动可以和回调并行移动端的顺滑度差别很明显。如果你的回调里确实需要preventDefault()这个场景不需要才应该关掉 passive。但要注意rAF合并本身也会带来一帧的延迟。对于导航变色这种视觉状态一帧约 16.7ms完全感知不到是值得的。如果做的是滚动视差这类“必须跟手”的效果那就不能这么合并得换 CSS 方案。还有一种更极致的写法用requestIdleCallback或者干脆只在值跨过阈值的那一帧才更新。思路是记录上一次的状态只有状态真的翻转时才碰 DOMlet lastState null; function updateNav() { const next Math.max(0, getScrollTop()) THRESHOLD; if (next lastState) return; lastState next; nav.classList.toggle(is-scrolled, next); }这个提前返回看着不起眼但它把 99% 的回调变成了“读一个数、比一次、直接 return”在高刷屏设备上省下的主线程时间相当可观。3.3 状态抖动和迟滞区间如果你把阈值设得很低比如 4px会看到一个经典现象在阈值附近轻微滑动滚轮导航栏的背景色会疯狂闪烁。原因是浏览器的滚动位置不是整数触控板惯性滚动时会以亚像素级变化scrollY可能在三五个值之间反复跳动再加上某些浏览器的滚动锚定机制页面内容动态加载时会微调滚动位置也会造成阈值附近的振荡。解决办法就是控制里的迟滞hysteresis思路——进入和退出用两个不同的阈值。进入阈值高一点60退出阈值低一点比如 8中间形成一段“死区”在这个区间内状态保持不变。const ENTER 60; const EXIT 8; let solid false; function updateNav() { const y Math.max(0, getScrollTop()); if (!solid y ENTER) { solid true; nav.classList.add(is-scrolled); } else if (solid y EXIT) { solid false; nav.classList.remove(is-scrolled); } }这段逻辑看着比toggle啰嗦但它解决了两个问题。一是防抖用户从 100px 慢慢滚回 50px 时导航栏不会立刻变透明而是继续保持在实底状态直到滚到 8px 以内才交还透明度——视觉上更“沉稳”不会黏在阈值上闪。二是它把状态存在变量里而不是每次去读 DOM 的classList.contains避免读 DOM 带来的性能风险。迟滞区间的宽度没有绝对标准我一般取进入阈值的 10% 到 20%。60 配 8 是 13%比较常见。如果页面特别长、滚动速度快可以让死区更宽一点比如 60 配 20。3.4 初始化时机与那些“刷新后状态不对”的场景updateNav()第一次调用放在哪很讲究。放head里的同步脚本此时 DOM 还没解析出来getElementById拿到 null直接报错。放DOMContentLoaded之后比较稳妥但如果导航栏高度是动态的比如内容变了此时拿到的值可能还不准。更麻烦的是浏览器恢复滚动位置。用户滚到 800px 处按 F5 刷新现代浏览器会尽量把滚动位置恢复到 800px。这个过程可能发生在load之后也可能发生在DOMContentLoaded附近不同浏览器行为不一致。如果你的变色逻辑只绑在scroll事件上刷新后页面停在 800px 但scroll事件没触发过导航栏就维持透明的初始态用户看到的是一条透明的导航压在正文上。我一般会在三个时机各调一次初始化DOMContentLoaded、window.load、以及给window绑一个pageshow事件处理从缓存返回页面的情况即event.persisted为 true 的场景。function init() { updateNav(); } document.addEventListener(DOMContentLoaded, init); window.addEventListener(load, init); window.addEventListener(pageshow, (e) { if (e.persisted) init(); });pageshow这个事件值得单独说一句。用户从详情页按返回键回到列表页时浏览器可能直接从往返缓存里恢复页面此时DOMContentLoaded和load都不会再触发但滚动位置还保留着。不监听pageshow的话就会出现“返回之后导航栏是透明的但页面明显已经滚动过”的 bug。这个 bug 在移动端浏览器里出现率很高桌面端反而少见所以很容易在上线后才被发现。4. 更省事的两条路哨兵观察与滚动驱动动画4.1 IntersectionObserver 加哨兵元素如果你不想碰滚动事件最干净的做法是往页面顶部塞一个“哨兵”。这个元素固定在最上面高度等于你想要的阈值然后用IntersectionObserver观察它是否还和视口相交。它完全离开视口顶部的那一瞬间正是滚动距离越过阈值的一刻。div classnav-sentinel aria-hiddentrue/div.nav-sentinel { position: absolute; top: 0; left: 0; width: 1px; height: 60px; pointer-events: none; visibility: hidden; }const sentinel document.querySelector(.nav-sentinel); const nav document.getElementById(siteNav); const io new IntersectionObserver((entries) { for (const entry of entries) { nav.classList.toggle(is-scrolled, !entry.isIntersecting); } }, { threshold: 0 }); io.observe(sentinel);哨兵的高度直接就是阈值改参数只需要改一行 CSS比在 JS 里维护常量更直观设计师调整视觉方案时前端也不用跟着改逻辑。pointer-events: none是为了防止这个空元素挡住头图上的点击区域虽然它只有 1px 宽但高度有 60px如果不设很可能覆盖住某个按钮的边角。这个方案的迟滞问题也天然解决了isIntersecting是个布尔值浏览器内部判断交叉与否有一点点缓冲不会在临界点上反复横跳。我在几个长列表页面实测过比手写阈值稳。需要留个心如果哨兵放在一个position: relative的容器里top: 0是相对那个容器的不是相对文档顶部。要么确保它在body的直接子级要么把容器设成position: static。4.2 CSS 滚动驱动动画与降级最新的一批浏览器开始支持滚动驱动动画能用纯 CSS 把“滚动进度”映射到“背景色”一行 JS 都不用写。supports (animation-timeline: scroll()) { .site-nav { animation: navSolid linear both; animation-timeline: scroll(root block); animation-range: 0 60px; } keyframes navSolid { from { background-color: rgba(255, 255, 255, 0); box-shadow: none; } to { background-color: rgba(255, 255, 255, .92); box-shadow: 0 1px 2px rgba(0, 0, 0, .06); } } }animation-range: 0 60px的意思是滚动位置在 0 到 60px 之间完成整个动画超过 60px 就停在末态。这比 JS 版本还多了一个好处——它是连续的背景可能在 30px 时是半透明视觉过渡比“两个状态二选一”更细腻。但一定要包在supports里。不支持的环境下这段样式会被整体忽略此时由 JS 方案接盘。也就是说前面写的is-scrolled类和滚动监听代码要保留作为降级路径。这也是我推荐“JS 兜底 现代方案增强”这套组合的原因用户看到的效果不会有落差只是过渡的细腻程度不同。有一点要特别注意滚动驱动动画和is-scrolled类如果同时生效会互相打架——类的背景色和动画的背景色会有一方被覆盖。要么在supports生效时把 JS 版本停掉用CSS.supports()做特性检测要么让动画只作用于一个不影响类的属性。我一般用前者逻辑清晰。4.3 滚动容器不是 window 时怎么改前面所有讨论都默认滚动发生在整个文档上但现实里有一类很常见的布局body设了overflow: hidden真正滚动的是中间一个overflow-y: auto的容器导航栏固定在这个容器的顶部。这种“应用壳”布局在后台管理系统里到处都是。此时window.scrollY永远是 0滚动事件也不在window上触发前面写的监听全部失效。要改两处监听目标变成那个容器元素取值变成container.scrollTop。const scroller document.querySelector(.app-scroll); function getScrollTop() { return scroller.scrollTop; } scroller.addEventListener(scroll, onScroll, { passive: true });用IntersectionObserver的话需要把root指定成这个容器const io new IntersectionObserver(cb, { root: scroller, threshold: 0 });这里最容易被忽略的是“导航栏到底在不在滚动容器里面”。如果导航栏是容器的兄弟节点在容器外面那固定它没问题如果导航栏在容器内部那它会被容器的滚动带上去position: fixed也会因为容器的overflow而表现异常。比较稳的结构是把导航栏放在滚动容器外面容器只负责内容区的滚动。我在一个后台项目里重构过这个问题改结构比改代码省事得多。5. 真机上的坑移动端与浏览器差异5.1 地址栏收缩带来的高度跳变移动端浏览器的地址栏会随着滚动方向自动收起和展开这会导致视口高度在滚动过程中发生变化。如果你的导航栏高度、首屏高度或者阈值是用vh或者window.innerHeight算出来的就会出现一种诡异现象往下滚时地址栏收起视口变高innerHeight变大如果阈值是跟着它算的导航栏的变色时机就会跟着漂移。解决的思路是让阈值依赖固定像素而不是视口比例。前面把阈值定成 60px 就是这个原因它不会因为地址栏高度变化而变。如果确实需要用视口高度优先用dvh动态视口单位它比vh更贴合实际可视区域现代移动浏览器支持都不错.hero { min-height: 100dvh; }另外如果你需要精确知道可视区尺寸的变化可以监听window.visualViewport的resize事件它比window.resize更准确地反映移动端的可视变化。但这个事件触发频率也不低记得同样用 rAF 合并。5.2 毛玻璃与合成层的性能账现在很流行给滚动后的导航栏加一层毛玻璃backdrop-filter: blur(...)效果确实高级。但这一步的性能代价很多人在桌面开发机上完全感觉不到一到中低端安卓机就露馅滚动时整个页面的帧率明显下降甚至出现导航栏区域的色块闪烁。原因是backdrop-filter需要实时采样它背后的内容并做模糊浏览器会为这个元素建一个合成层每一帧都要重新计算。滚动时背景内容在变模糊结果也得跟着重算。如果导航栏下面还有别的动画元素开销会叠加。我的处理办法是分档桌面端和高性能设备开模糊其他环境降级成高不透明度的纯色。.site-nav.is-scrolled { background-color: rgba(255, 255, 255, .96); } media (min-width: 768px) and (prefers-reduced-motion: no-preference) { .site-nav.is-scrolled { background-color: rgba(255, 255, 255, .72); backdrop-filter: saturate(180%) blur(14px); } }顺手提醒一句will-change: transform和transform: translateZ(0)这种“强制提升图层”的写法不要满屏乱撒。图层提上去之后会常驻内存尤其是导航栏这种全站元素多留一层看着不多但配上其他动画元素低端机的内存压力就上来了。真要用就在变色过渡期间用过渡结束后撤掉。5.3 惯性滚动与回弹iOS 的滚动有惯性而且到了边界会回弹。回弹过程中scrollY会变成负值虽然前面用Math.max(0, y)兜住了但还有另一个现象回弹到负值的瞬间如果页面顶部本来就是透明的导航栏视觉上会出现一条小小的空隙在导航栏上方闪一下这通常是因为导航栏用了top: 0但页面本身有transform或者scroll-behavior造成的。检查一下html和body有没有多余的位移属性。还有一点scroll-behavior: smooth和滚动监听混用时要小心。点击锚点后页面会平滑滚动一段距离滚动事件连续触发导航栏会按部就班地变色这没问题。但如果平滑滚动的终点刚好在阈值附近过渡动画还没播完滚动就停了is-scrolled可能停在中间态。稳妥的做法是在滚动结束后再主动调用一次updateNav()用scrollend事件支持度有限或者一个短延时兜底。6. 问题排查速查表与实操心得6.1 症状对照表下面这张表是我这几年遇到过的具体问题按“症状 → 大概率原因 → 处理方式”整理出问题的时候可以先按这张表过一遍比从代码第一行开始读快得多。症状大概率原因处理方式刷新后导航栏一直透明只绑了 scroll没做初始化在DOMContentLoaded、load、pageshow各调一次更新变色时闪一下、来回跳阈值设太低或没有迟滞区进 60 出 8用状态变量记录当前状态滚动明显卡顿回调里有布局读取或没加 passive用 rAF 合并读值集中在一处移动端变色时机“漂移”阈值依赖innerHeight或vh改用固定像素阈值fixed 导航跟着页面滚走祖先元素有transform或filter把导航提到 body 直接子级平滑滚动后状态停在中间动画结束时状态未同步滚动结束后补一次更新后台系统里完全不生效实际滚动的是内部容器改监听目标与 IntersectionObserver 的 root导航文字压在浅色正文上看不清背景不透明度不够不透明度提到 0.85 以上6.2 几条踩出来的经验第一把“颜色”和“布局”分开测。我调试这类问题时习惯先把变色逻辑用一条醒目的红色边框验证确认状态切换的时机对不对再去调颜色和过渡。混在一起调很容易把“阈值不对”误判成“颜色不对”。第二别在滚动回调里做任何可能触发重排的事。读scrollY、scrollTop是安全的读offsetHeight、getBoundingClientRect()就可能触发同步布局。如果确实需要尺寸在页面加载和resize时取一次缓存起来滚动回调里只用缓存值。第三给导航栏变色这件事配一个可关闭的开关。有些用户开了“减少动态效果”prefers-reduced-motion: reduce过渡动画对他们来说可能是干扰。这种情况下我会把transition去掉直接硬切功能不受影响但体验更温和。第四组件化项目里注意解绑。在框架里写这段逻辑监听和观察器都要在组件卸载时清理掉否则单页应用频繁切换路由会累积一堆监听器。IntersectionObserver记得disconnect()scroll事件记得removeEventListener并且传入的必须是同一个函数引用——用匿名函数是解绑不掉的这个错误我见过太多次。第五真机测试不能省。桌面浏览器把窗口缩小模拟移动端和真机是两回事。地址栏行为、惯性滚动、backdrop-filter的性能、pageshow的触发只有真机上才会暴露出来。我现在的习惯是代码写完先在一台中端安卓机上滚两分钟没问题再上桌面验收。最后分享一个我认为性价比最高的做法这个效果本质上是给导航栏加一个“是否已经离开页面顶部”的布尔状态。一旦你这么理解就会发现它不该写在滚动回调里也不该和滚动距离绑定得太死。用哨兵元素 IntersectionObserver表达这个布尔代码量最少、性能最好、也最不容易出错。至于那些需要精确控制阈值的少数场景再退回滚动监听配合 rAF 和迟滞一样能跑得很稳。
