这几天群里有人在聊一个前端交互问题实录我看了好几遍一个 AI 聊天界面里用户正往上翻看昨天的一段长对话看到关键结论的时候助手的新回复到了整个视口“刷”一下被拽到最底部正在读的那几行内容直接被顶出屏幕。来来回回试了几次每次都能复现。这不是个例。聊天类产品接入流式 AI 输出之后“我明明在看上面的内容为什么非要把我拖回去”几乎成了高频吐槽。说穿了这就是滚动锁定做得到不到位的问题。标题里问的“如何阻止 AI 新消息把它顶下去”背后不只是一个函数调用而是一套关于用户注意力、滚动状态和渲染时序的完整交互设计。1. 新消息为什么能抢走用户的视口自动滚动与原生锚定1.1 自动滚动逻辑才是最先要查的“元凶”大部分聊天组件的初始版本都有一个非常朴素的实现收到新消息之后执行一次scrollTop scrollHeight或者调用scrollIntoView()把最新一条消息送进视口。这个逻辑的初衷很善良——让用户第一时间看到新回复。但它完全没考虑一个前提用户当前到底在不在底部。如果你正在底部等回复自动滚动是合理的但如果你正在往上翻历史这行代码就变成了一次“视口抢劫”。尤其当 AI 回复是流式输出时新消息会频繁到达滚动代码被反复触发用户几乎没有任何机会停留在历史区域。更麻烦的是有些实现用scrollIntoView({ behavior: smooth })。平滑滚动会带来一个运动过程而不是瞬间跳转。用户明明已经在历史位置停下来了又被迫看着视口“滑走”这个体验比瞬间跳转还要糟糕。scrollIntoView还会把目标元素之外的滚动容器也牵扯进来如果页面里存在多个可滚动的祖先节点你甚至不一定能预测它最终滚的是哪个容器。1.2 浏览器原生 scroll anchoring 会偷偷调整你的滚动位置就算你一句自动滚动代码都没写浏览器也可能主动帮倒忙。现代浏览器普遍实现了 scroll anchoring滚动锚定机制核心目的是当视口上方的 DOM 内容发生插入、删除或尺寸变化时自动调整滚动位置让用户正在看的元素尽量保持原位。听起来很贴心但到了聊天场景里会产生奇怪的行为。比如某条历史消息里的图片延迟加载完成高度突然从 0 变成几百像素或者你向上加载了更早的记录把一批旧消息插到了列表顶部再或者某个富文本消息里的代码块从折叠变成展开。这些变化发生在用户当前视口的上方浏览器就会自动重算 scrollTop试图把“锚点元素”稳住。这时候你会看到的现象就是用户什么都没碰页面却微妙地动了一下。可能不是标题里描述的“顶下去”那么夸张但同样会破坏阅读节奏。所以排查问题时不能只盯着业务代码还要留意浏览器这个“隐形的手”。1.3 为什么“底部插入新消息”也会让上方内容看起来在动从几何上讲普通从上到下的流式布局里新消息追加在底部并不会推动上方已经渲染的消息。用户当前视口里的文本位置应该是稳定的。那为什么还是有大量“被顶下去”的反馈因为大多数不是几何位移而是程序主动改变了scrollTop。可能来自自动滚动逻辑也可能来自某个基于scrollHeight裁剪内容的自适应组件。另外当scrollHeight变大时浏览器某些渲染路径会触发滚动回调而回调里如果包含“判断是否在底部并执行滚动”的操作就会出现连锁反应新消息让scrollHeight变大滚动事件被触发状态机误判用户已经回到底部然后真的执行了滚动到底部。所以核心问题并不是“消息插在了哪里”而是“你有没有在滚动事件里做出错误的自动行为”。2. 那些看似合理、实战却翻车的防顶方案2.1 用 scrollTop 判断“是否贴底”阈值怎么选都有问题最流行的方案是在滚动事件里计算scrollHeight - scrollTop - clientHeight当结果小于某个阈值时认为用户处于底部。然后新消息到达时只有处于底部才执行滚动。这个思路方向是对的但它没有想象中那么可靠。第一阈值不好选。设成 40px用户可能为了看倒数第二条消息的结尾停在了距离底部 30px 的位置系统会把他当成“在底部”新消息一来照样被拉走。设成 10px又可能在用户尚未完全滚到底时提前解锁或者因为滚动动量导致误判。第二流式输出会让这个计算变得不稳定。AI 消息每几百毫秒就可能增长一段scrollHeight不断变化即使scrollTop没变scrollHeight - scrollTop - clientHeight的结果也在来回跳动。特别是当新消息长到一定高度后这个差值可能从 30 突然变成 200然后又跌回 30状态在“贴底”和“不贴底”之间反复横跳。第三滚动事件是异步的且触发频率远超你的想象。移动端惯性滚动、桌面端鼠标滚轮的细粒度滚动都会产生高频回调。你还要花额外的功夫做节流否则一个简单的判断也能拖累整个页面的滚动流畅度。2.2 用 IntersectionObserver 盯底部哨兵延迟和嵌套容器的坑有人会在列表底部放一个高度为 1px 的哨兵元素用 IntersectionObserver 观察它是否进入视口以此判断用户是否在底部。这个方案比裸scrollTop优雅一些而且不依赖滚动事件触发性能理论上有优势。但实战中同样有坑。IntersectionObserver 是异步回调触发时机在帧之后。当新消息刚插入时底部哨兵的可视状态还没被及时上报你可能会错过一次需要滚动的机会。对于 AI 聊天的流式场景错过了也就错过了底部那点内容被遮挡在视口下面用户感受很直观。更麻烦的是嵌套滚动容器。如果消息列表是页面主滚动区域里的一个子容器或者外层有 transform、filter 之类的属性哨兵的交叉计算会和实际滚动行为产生偏差。跨 iframe 的场景就更不用说了IntersectionObserver 的穿透限制会直接让哨兵失效。综合下来这个方案适合结构非常简单的页面复杂一点就难伺候。2.3 每次渲染后无脑滚动到底部覆盖用户意图的典型错误还有一类实现更简单粗暴监听消息数组的长度一旦变化就在渲染完成后的生命周期回调里执行滚动到底部。数组从 10 变成 11就滚一次从 11 变成 12再滚一次。这在“用户永远只想看最新消息”的产品里能用比如监控日志、实时行情。但在 AI 对话产品里就是灾难因为用户不仅想看最新消息还想回看之前的推理过程、方案结论、代码示例。你每次新消息都滚动等于明说“我不接受你看历史”。轮询场景会更离谱。如果消息来自轮询接口每 3 秒拉一次每拉一次列表就多一条用户手放在滚轮上想往上翻一点结果每 3 秒被打断一次。这种体验已经不是“瑕疵”而是“不可用”。2.4 给这些方案做一个横向对比方案实现成本流式输出下的稳定性用户意图识别复杂布局兼容性综合评价scrollTop距离判断低较差容易抖动一般阈值难调一般可作辅助不适合单独使用底部哨兵 IntersectionObserver中一般存在异步延迟较好较差嵌套容器失效适合固定结构的小型列表渲染后无脑滚动到底部极低极差无一般只适合自动刷新的日志页状态机 程序滚动标志中高好好好推荐正文马上就讲对比之后你会发现真正需要的不是“更精确地判断用户是否在底部”而是“把用户当前正在做什么”当成一个显式状态来维护。3. 一套可落地的滚动锁定状态机代码与取舍3.1 核心思路把“用户在看哪里”变成显式状态我把滚动行为拆成两个状态FOLLOWING和EXPLORING。FOLLOWING是“跟随底部”状态用户当前在底部附近新消息到达后应该保持视口贴底。EXPLORING是“浏览历史”状态用户已经离开底部不管历史区域有多近新消息到达时都不允许抢走视口。这两个状态的切换由滚动事件驱动。关键点在于区分“用户主动滚动”和“程序化滚动”。每次程序滚动都设置一个临时标志在滚动回调里看到这个标志就跳过状态判断避免自己的滚动操作反过来污染状态。3.2 React 里的实现示例我用 React 的useRef加useLayoutEffect写了一个最小可运行版本。为什么用useLayoutEffect因为新消息触发状态更新后需要在浏览器完成实际绘制之前拿到最新的scrollHeight并执行滚动避免闪一帧。import { useRef, useLayoutEffect, useState } from react; function ChatList({ messages }) { const containerRef useRef(null); // 是否处于“跟随底部”的状态 const isFollowingRef useRef(true); // 标记当前滚动是否由程序发起 const programmaticScrollRef useRef(false); const isNearBottom (el, threshold 40) { if (!el) return false; return el.scrollHeight - el.scrollTop - el.clientHeight threshold; }; const scrollToBottom () { const el containerRef.current; if (!el) return; programmaticScrollRef.current true; el.scrollTop el.scrollHeight; isFollowingRef.current true; // 在下一帧释放标志避免后续滚动事件覆盖状态 requestAnimationFrame(() { programmaticScrollRef.current false; }); }; const handleScroll () { const el containerRef.current; if (!el) return; if (programmaticScrollRef.current) return; // 这里就是一个简单阈值判断但配合滚动方向会更稳 isFollowingRef.current isNearBottom(el); }; // 新消息到达且用户处于跟随状态时滚动到底部 useLayoutEffect(() { if (messages.length 0 isFollowingRef.current) { scrollToBottom(); } }, [messages]); return ( div ref{containerRef} onScroll{handleScroll} style{{ height: 100%, overflowY: auto }} {messages.map((msg) ( div key{msg.id} classNamemessage {msg.content} /div ))} /div ); }这个版本解决了最核心的问题用户不在底部时新消息不会触发滚动。programmaticScrollRef保证了程序滚动产生的回调不会误把状态从FOLLOWING改成EXPLORING。3.3 阈值、滚动方向和“距离底部”的三个细节实际工程里光靠上面这个版本还不够。第一个细节是阈值。不要用 0因为用户滚动到真正的scrollHeight末端时客户端高度和滚动高度的差值不一定是 0移动端底部工具栏和全屏键盘都可能吃掉一段空间。我一般建议 32px 到 48px低于 20px 会导致判断过分敏感高于 80px 会在用户还没真正准备看新消息时就提前激活跟底。第二个细节是滚动方向。用户可能快速向上滚动后停在距离底部 30px 的位置此时按照阈值判断他“在底部”新消息一到照样把他拽下去体验依然不好。我在实际项目中会多记录一个lastScrollDirection。只有最后一次滚动方向是向下并且距离底部小于阈值时才进入FOLLOWING。如果用户是向上滚动后停住的即使停在底部附近也暂时不跟随给他一个缓冲时间。第三个细节是程序滚动的标志释放时机。上面用了requestAnimationFrame但严格来说还是不够稳。如果滚动容器在 iframe 或者有动画驱动的滚动滚动事件可能会在多个帧里持续触发。更稳妥的做法是维护一个时间戳lastProgrammaticScrollTime滚动事件回调里检查“距上次程序滚动是否超过 150ms”超过才算是用户主动滚动。这个时间窗口够长既能挡住自己引发的事件又不至于妨碍用户连续滚动。4. 流式 AI 输出是滚动锁定的加强版考验4.1 消息高度每秒都在变位置补偿怎么做普通聊天场景里新消息是整条到达的高度变化一次问题好处理。AI 流式输出完全不同一条消息从第一个 token 开始就在不断生长几百毫秒变一次。如果用户在FOLLOWING状态容器要保持贴底如果用户在EXPLORING状态又要保证他正在看的那段内容不被推跑。麻烦的地方在于即使普通布局中底部插入不会推动上方元素浏览器渲染时依然会因为scrollHeight的增长触发各种副作用。有些浏览器会重新计算滚动锚选择一个视口内的锚点元素尝试保持它的位置。如果锚点选择不理想页面就会产生肉眼可见的微小位移。这种情况下我采用的办法是在容器上挂一个ResizeObserver监听scrollHeight的变化。当回调触发时如果当前不是FOLLOWING就把scrollTop显式恢复到变化前的值。由于布局变化和恢复滚动发生在同一帧内用户几乎感知不到。const previousScrollTopRef useRef(0); useLayoutEffect(() { const el containerRef.current; if (!el) return; const observer new ResizeObserver(() { if (!isFollowingRef.current) { // 如果用户不在底部强制保持原来的滚动位置 el.scrollTop previousScrollTopRef.current; } else { // 如果用户在底部则保持贴底 el.scrollTop el.scrollHeight; } }); // 每次用户滚动时记录当前位置 const handleScroll () { if (!programmaticScrollRef.current) { previousScrollTopRef.current el.scrollTop; } }; el.addEventListener(scroll, handleScroll, { passive: true }); observer.observe(el); return () { observer.disconnect(); el.removeEventListener(scroll, handleScroll); }; }, []);这个“锚点恢复”方案的关键在于previousScrollTopRef的更新时机。它必须在浏览器布局变化之前记录而用户滚动事件天然是实时更新的所以我直接在滚动回调里同步更新这个值。注意ResizeObserver的回调里不能再去修改previousScrollTopRef否则会形成事件循环。4.2 更精准的锚点策略锁定视口里的第一条消息恢复scrollTop是最简单的补偿方式但在极端场景下不够精准。因为你恢复的是“容器滚动距离”而用户稳定的其实是“视口里那几行文字的位置”。如果变化发生位置的上下文中还有 margin 折叠、padding 变化、图片撑高这类影响恢复scrollTop就可能导致视觉偏移。这时候可以把锚点思路再深化一步记录视口里第一条可见消息元素的offsetTop以及这条消息距离视口顶部的偏移量。当列表高度变化时把scrollTop调整到让该元素的视觉位置重新对齐。这里给一个简化思路滚动事件里用document.elementsFromPoint或者遍历消息节点找到第一个offsetTop el.scrollTop的子节点作为锚点。变化发生后计算锚点的新位置然后设置el.scrollTop anchorEl.offsetTop - fixedOffset;fixedOffset是锚点原本离视口顶部的距离。这样做的好处是即使布局因为图片加载、代码块展开而发生了较大变化用户看到的那个“起始位置”始终保持稳定。代价是计算成本略高不建议在每次滚动事件里全量遍历应该只在ResizeObserver触发的低频回调里做。4.3 column-reverse 反向列表到底要不要用聊到滚动锁定绕不开display: flex; flex-direction: column-reverse这个反向列表技巧。它的设计思路非常聪明让容器以底部为滚动原点列表项的视觉顺序正常排列但滚动条数值是反的。这样新消息 append 到容器末尾时如果用户原本就在底部新消息会“停在原地”不需要任何滚动操作如果用户上翻了新消息在视觉上位于用户下方也不会推动当前视口。这个方案对于“纯展示聊天记录”的产品确实好用代码量少稳定性高。但换到 AI 对话这种带着输入框、富文本、虚拟滚动的场景就有几个问题。第一滚动方向反转。鼠标滚轮往下滚内容表现是向上移动还是反向移动在不同浏览器里的处理不统一你得多做一层兼容。第二加载更早历史消息时原本在列表前部的旧消息会插入到视觉顶部此时必须调整 scrollTop否则视口会跳。第三iOS Safari 某些版本对column-reverse和输入框聚焦时的页面滚动有组合缺陷。我建议在可用性要求高、交互复杂的 AI 聊天界面里还是用“正常布局 状态机 锚点补偿”来解决问题反向列表留给日志流这类简单场景。5. 回归测试清单与我最终的建议5.1 发版前至少跑一遍的场景矩阵滚动锁定这种交互只靠开发时手动验一遍根本不够。AI 消息是流式到达的用户手速、网络延迟、图片加载时机都不一样。我给自己准备了一张测试矩阵每次改动后都要跑一遍。测试场景用户滚动位置触发动作期望行为普通新消息底部插入一条完整的消息视口始终贴着底部普通新消息距离底部 50px插入一条完整的消息视口位置不跳变流式消息增长底部目标消息持续输出 token视口保持贴底流式消息增长上翻到历史区域目标消息持续输出 token用户正在看的内容稳定用户在快速向上滚动滚动中新消息到达不打断手势不强制跳转图片异步加载历史区域某条消息的图片加载完成该消息位置不跳动代码块展开/折叠历史区域上方消息高度变化当前视口内容稳定窗口尺寸变化任意无新消息只缩放浏览器不误触发跟随底部移动端键盘弹出底部键盘顶起容器不把阅读位置推到奇怪位置这套矩阵不是让你全部自动化至少人工回归的时候要覆盖到。每条都要有明确的“期望行为”不然测了跟没测一样。5.2 复现和调试的技巧滚动问题最大的痛点是复现难。你等半天新消息才来等到了又未必对上用户的手势。我一般直接在控制台往消息列表里批量注入假数据模拟不同频率的流式到达。比如在 React 项目里可以直接在 DevTools 里执行// 模拟流式输出每 500ms 追加一段内容 const timer setInterval(() { const el document.querySelector([data-chat-list]); if (!el) return; const node document.createElement(div); node.textContent 模拟新增内容 Date.now(); el.appendChild(node); }, 500);跑起来之后手动把列表滚到某个历史位置观察是否跳动。这个方法的优点是可以稳定复现、随意控制频率和内容长度。调试定位时推荐两个手段。第一是 DevTools 里的“Event Listener Breakpoints”勾选scroll一类的事件在滚动回调里断点看每一次触发是从哪里来的。第二是 Elements 面板里右键滚动容器选择 Break on - subtree modifications能看到每次列表变化是哪个模块写进来的方便区分“是自动滚动抢跑”还是“外部插入导致锚点重算”。5.3 我踩过的坑和最终建议我在这类问题上踩过不少坑。最典型的一个是只判断scrollTop 0完全忽略clientHeight和scrollHeight的动态变化。在带底部 inset 的移动端浏览器里这个判断几乎从来不等于 0底部跟随时好时坏。第二个坑是同步执行scrollTo造成性能问题。聊天列表里消息很多时一轮滚动到底部涉及的布局计算量不小不应该被流式到达的每个 token 都触发一次。要合并到同一帧一个消息批次到达只在最后一条写入 DOM 后执行一次滚动。第三个坑是 AI 消息中的图片和代码块。消息先以纯文本形式渲染随后图片才加载完成高度突然撑开。如果用户正停在历史区域这个延迟高度变化会被很多人忽略结果视口还是悄悄动了。解决方案就是前面讲的ResizeObserver补偿这个钱必须花。最后说一点个人体会。滚动锁定的核心不是算法有多精巧而是产品要不要“尊重用户注意力”。我后来在两个项目里都用了同一个思路新消息到达时如果用户正在浏览历史我不滚动他的视口只在底部显示一条“有新消息”的浮条点击浮条才回到最新位置。结果用户投诉反而比自动滚动更少。因为对人来说被强行打断注意力比少看一条新消息更难受。你可以在自己的项目里试试这个优先级大概率会发现自动滚动的必要性并没有想象中那么高。