虚拟列表专为解决长列表卡顿而生，问题源于误用：滚动容器未设固定高度、干扰滚动样式的父级、itemSize传错或动态计算、itemCount误用items.length、position:sticky失效、新增数据不自动滚动、过度重算渲染逻辑。
虚拟列表不是“导致”长列表的问题，它就是专为解决长列表卡顿而生的——真正出问题的，是把虚拟列表当普通列表用，或者在不该用的地方硬套。
滚动容器没设固定高度，虚拟列表直接失效
虚拟列表依赖可视区域精确计算起始索引，如果 #container 没设 height 或用了 min-height、overflow: visible，框架就无法知道“当前能看到几行”，只能退化成全量渲染或计算错乱。
- 必须给滚动容器（如
div#list-container）设置明确的height或max-height，且不能是auto - 禁用会干扰滚动上下文的样式：避免父级有
transform、will-change、filter，否则getBoundingClientRect()偏移不准 - Vue 场景下，
ref绑定的容器需确保已挂载且尺寸稳定；React 中若用useRef，别在render里反复调用getBoundingClientRect()
itemSize 传错或动态变化，滚动跳变/白屏
FixedSizeList 要求每行高度严格一致，一旦传了错误值（比如把 48 写成 50），后续所有位置计算都会偏移；VariableSizeList 则要求 itemSize 函数必须返回确定值，且首次渲染后要缓存真实高度，否则反复调用拖慢滚动。
- 固定高度场景：确认 CSS 中
.list-item的height/line-height+padding总和等于itemSize值 - 可变高度场景：不要在
itemSize里直接读 DOM 高度，改用useMemo或外部 Map 缓存；首次渲染后立即用measureRef（如 react-window 提供）更新缓存 - 禁止把
items.length当作itemCount传入——必须传原始总条数，否则 filter 后索引错乱，新数据插入时定位失准
position: sticky 在虚拟列表里不生效
因为虚拟列表靠 transform: translateY() 移动内容块，而 position: sticky 需要最近的非 transform 滚动祖先。此时 sticky 元素找不到有效锚点，自动降级为 relative。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 方案一：单独渲染 sticky header，用
onScroll+scrollTop手动控制其top和z-index，加requestAnimationFrame防抖 - 方案二：用 IntersectionObserver 监听顶部 item 进入视口，动态切换 header 的
fixed状态 - 方案三：放弃 sticky，改用绝对定位 + 动态
top偏移，但要注意 iOS Safari 下position: absolute在 overflow-scroll 容器中仍可能跟随滚动（需测试）
实时追加数据后新项不可见
虚拟列表不会自动滚动到底部，哪怕你 push 了一条新消息到数组末尾，scrollTop 仍停在原位，用户得手动拉——这对聊天、日志等场景极不友好。
- 监听数据变更，当新增项且当前已滚动到底部（
scrollTop + clientHeight >= scrollHeight - 1），再调用scrollTo({ top: scrollHeight }) - 慎用
scrollIntoView({ block: 'end' })：它会触发 layout，频繁调用易卡顿；优先用scrollTop = scrollHeight+requestAnimationFrame - 如果用的是服务端分页+无限滚动，别让虚拟列表管理“全部历史”，只维护当前页 + 缓冲页的数据片段，滚动到底部再预加载下一页并拼接
最常被忽略的一点：虚拟列表的性能瓶颈不在“渲染多少”，而在“每次滚动时重算多少”。哪怕只渲染 5 行，如果 itemRenderer 里做了深 clone、正则匹配或未 memoized 的计算，照样卡。优化永远从单项开销开始，不是从总条数开始。
