最稳方案是scroll-view+scroll-top动态计算高度，必须设固定高度（如70vh）、overflow:hidden，禁用scroll-into-view；流式场景需防抖节流，键盘弹出时重算滚动位置。
直接用 scroll-view + scroll-top 动态计算滚动高度是最稳的方案，scroll-into-view 在消息高频增删或流式输出时容易失焦、卡顿甚至失效。
scroll-view 必须设固定高度，否则滚动不生效
这是最常被忽略的前提。uni-app 的 scroll-view 不像 Web 的 div，它不会自动撑开或响应内容高度变化。没设高度，就等于没启用滚动能力。
- 推荐用
vh单位，比如height: 70vh，兼顾不同屏幕；避免用100%，容易因父容器未设高而塌陷 - 必须加
overflow: hidden（CSS 中显式声明），否则 iOS 端可能出现双滚动条或滚动异常 - 不要依赖
flex: 1或flex-grow来“自适应高度”，实测在多个平台（尤其是微信小程序）中不可靠
用 scroll-top 实现回到底部，别依赖 scroll-into-view
scroll-into-view 看似简单，但实际在 uni-app 中有三个硬伤：新消息 v-for 渲染后 DOM 未必就绪、流式追加文本时反复触发导致抖动、id 动态生成易冲突或遗漏。而 scroll-top 是纯数值控制，可控性强。
- 计算公式是：
scrollTop = scrollHeight - clientHeight，其中scrollHeight是整个消息区域总高度，clientHeight是可视区域高度 - 必须用
uni.createSelectorQuery()获取真实布局尺寸，不能用ref+$el.offsetHeight（小程序无 DOM） - 每次新增消息后，要包裹在
nextTick里再查尺寸，确保渲染完成 - 示例关键逻辑：
const scrollToBottom = () => { nextTick(() => { uni.createSelectorQuery() .in(this) .select('.message-list') .fields({ scrollHeight: true, clientHeight: true }) .exec(res => { if (res[0]) { const { scrollHeight, clientHeight } = res[0] scrollTop.value = scrollHeight - clientHeight } }) }) }
流式输出（如 AI 回复逐字显示）时防抖 + 节流是刚需
如果后端返回的是 SSE 或分 chunk 的文本流，每来一个字符都调一次 scrollToBottom()，UI 会疯狂抖动，体验极差。这不是 bug，是设计缺陷。
- 对输入内容变化做防抖（debounce），延迟 100–150ms 再执行滚动，覆盖绝大多数流式场景
- 若消息本身很长（如大段 Markdown），可加节流（throttle），限制 1 秒最多滚动 1 次
- 更优解是结合
flex-direction: column-reverse布局（需配合消息顺序翻转），但会增加数据渲染逻辑复杂度，适合新项目；老项目建议先走防抖 - 注意：防抖函数不能写在
setup外部全局作用域，必须绑定到组件实例或使用ref+onBeforeUnmount清理定时器，否则内存泄漏
键盘弹出时滚动位置错乱，需监听软键盘事件
Android 和 iOS 微信小程序中，软键盘弹出会压缩视口，导致 clientHeight 突变，原本算好的 scrollTop 值失效，新消息可能被顶出可视区。
- uni-app 提供了
uni.onKeyboardHeightChange和uni.onSoftKeyboardInput，优先用前者 - 监听到键盘高度变化后，重新执行一次
scrollToBottom()，而不是缓存旧值 - 不要在键盘收起时强行恢复原
scrollTop，用户可能已手动往上翻阅历史消息，应保持其滚动位置 - 测试时务必在真机（尤其华为/小米 Android 机型）上验证，模拟器无法准确还原软键盘行为
真正难的不是“怎么滚到底”，而是“什么时候该滚、什么时候不该滚”。消息追加、流式更新、键盘弹起、用户手动滚动——这些信号混在一起，必须靠精确的时机判断和状态隔离来处理，漏掉任意一种，都会在特定机型或操作路径下崩掉体验。
