上拉加载容器必须用div而非ul，因ul在旧版Safari中scrollTop计算偏移、scrollIntoView失效，且框架批量插入li易引发重排跳动；需设overflow-y:auto与固定高度，禁用transform等属性，并用document.documentElement.scrollTop加阈值判断触底。
上拉加载的 DOM 结构必须用 div 而非 ul
消息流、商品列表这类无限滚动容器，如果套 ul，滚动定位和动态插入会出问题：旧版 Safari 对 ul 的 scrollTop 计算偏移，scrollIntoView 失效；部分框架在 ul 内部批量追加 li 时触发重排，导致滚动跳动。真实项目中统一用 <div id="list-container"></div> 作外层，每条数据用独立 <div class="item" id="item-123"></div>。
关键约束：
- 容器必须设
overflow-y: auto和固定高度（如height: 500px），不能靠flex: 1或min-height动态撑开 - 每条
item必须有唯一id，后续滚底、编辑、撤回都依赖它 - 容器上禁用
transform、will-change、filter，否则scrollTop值计算失准
window.addEventListener('scroll') 触发条件要防误判
用 window.innerHeight + window.scrollY >= document.body.scrollHeight 判断触底，在移动端极易误触发——图片懒加载后撑开页面、键盘弹起改变视口高度、小屏滑动惯性都会让这个等式提前为真。实际应统一用 document.documentElement.scrollTop，并预留阈值。
推荐写法：
立即学习“前端免费学习笔记（深入）”；
- 用
document.documentElement.scrollTop替代window.scrollY，兼容 IE 和旧 Safari - 触发条件改为
document.documentElement.scrollTop + window.innerHeight >= document.documentElement.scrollHeight - 100（即距离底部还有 100px 就加载） - 首屏内容不足一屏时，
scroll事件根本不会触发，需手动检查一次：if (document.documentElement.scrollHeight
loading 状态必须与 fetch 生命周期强绑定
用户快速上滑两次，可能发起两个 fetch，后一个先返回，把前一个的数据覆盖掉；或者请求被 abort，但 loading 还挂着。核心是把状态控制收进请求流里，不靠全局变量硬塞。
实操要点：
- 每次调用
fetch前立刻设isLoading = true，并同步更新 DOM：loadingDiv.style.display = 'block' - 在
fetch().then()和.catch()两个分支末尾都执行isLoading = false; loadingDiv.style.display = 'none' - 用
AbortController配合signal参数，新请求发起时abort()上一个未完成的请求 - 后端返回空数组不等于到底了——只信任
has_more: false字段决定是否禁用后续加载
新增数据后自动滚底不能只靠 scrollIntoView
对最后一条消息调用 scrollIntoView({ behavior: 'smooth' }) 经常不生效，不是 API 问题，而是执行时机不对：DOM 可能还没渲染完，或容器高度尚未更新。尤其在 WebSocket 回调或异步插入场景下更明显。
可靠方案分两种：
- 需要立即生效（如消息撤回后重新定位）：用
listEl.scrollTop = listEl.scrollHeight - listEl.clientHeight，绕过渲染队列，强制滚动到底 - 仅新增消息且允许轻微延迟：用
lastItemEl.scrollIntoView({ block: 'nearest', inline: 'start' })，block: 'nearest'避免反复跳动 - 绝对不要在循环中对每条消息都调用
scrollIntoView；只操作最后一条，或批量插入后调用一次
真正容易被忽略的是：容器首次渲染时 scrollHeight 可能为 0，得用 Promise.resolve().then(() => { ... }) 或 requestAnimationFrame 延迟执行滚底逻辑。
