虚拟列表中骨架屏不能硬塞，因滚动容器高度动态计算，骨架节点结构不匹配会破坏滚动条比例、导致跳动或白屏；必须复用真实列表的外层标签（如ul/ol）、每个占位项对应li/article并带相同class与data-index，图片占位用img标签而非div，CSS需显式声明尺寸（如height、aspect-ratio），服务端直出骨架需带data-skeleton="true"，客户端用remove()销毁而非隐藏，且骨架高度须与真实itemHeight严格一致以保障可视范围计算准确。
虚拟列表里骨架屏为什么不能用硬塞
因为虚拟列表的滚动容器高度是动态计算的，骨架节点若结构不匹配，会直接破坏滚动条比例、导致跳动或白屏。真实列表用ul + li，骨架就必须是同样层级和语义的ul + li；如果骨架用div包裹一堆span，CSS里的display: flex或grid-template-rows就全乱套了。
常见错误现象：scrollTop突变、滚动条缩成一个小点、快速滚动时空白区域突然拉长。
- 骨架节点必须复用真实列表的外层容器标签（如
ul、ol、section），不能降级为div
- 每个占位项必须对应一个
li或article，且带相同class与data-index属性
- 图片占位必须用
img标签 + src="data:image/svg+xml,..."，不能用div模拟——否则getBoundingClientRect()测高不准
固定高度虚拟列表中骨架节点怎么撑开空间
骨架元素塌陷不是样式没写对，而是浏览器把空li渲染成 0×0，后续 JS 动态插入真实内容时触发重排。必须靠 CSS 显式声明尺寸，且不能依赖父容器高度。
正确做法是：文字行用line-height × 行数，图片用aspect-ratio或padding-top + position: relative。
立即学习“前端免费学习笔记（深入）”；
Wechat Article Html
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
下载
-
li自身设height: 80px（与真实项一致），禁用min-height或fit-content
- 标题占两行 →
height: 2.4em（假设line-height: 1.2）
- 图片占位 →
aspect-ratio: 16 / 9（现代）或padding-top: 56.25% + 子元素position: absolute; top: 0; left: 0; width: 100%; height: 100%
- 所有骨架元素加
overflow: hidden，防止 shimmer 动画溢出圆角
服务端直出骨架后，客户端怎么安全替换而不闪屏
关键不是“显示/隐藏”，而是“销毁”。用display: none或opacity: 0会让骨架节点长期驻留，JS 框架 hydration 时可能误判为差异节点，引发 DOM 替换闪动。
必须让骨架成为可识别、可精准移除的 HTML 片段。
- 服务端输出时，骨架节点带
data-skeleton="true"，真实内容节点带data-skeleton="false"
- 客户端拿到数据后，用
document.querySelectorAll('[data-skeleton="true"]')批量获取，调用.remove()彻底销毁
- 禁止用
replaceWith()传字符串——容易 XSS；必须传DocumentFragment或真实Element
- 替换动作需在
requestIdleCallback中执行，避免阻塞主线程影响滚动响应
虚拟列表+骨架屏组合下，滚动节流和占位高度缓存怎么协同
骨架屏撑开的是“静态占位高度”，而虚拟列表需要的是“动态可视范围计算依据”。两者共用同一套高度模型，但初始化时机不同：骨架高度用于首屏渲染，真实高度用于后续滚动计算。
最容易被忽略的一点：骨架节点的高度必须和后续真实项的itemHeight完全一致，否则calculateVisibleRange()算出来的startIndex会偏移。
- 服务端直出骨架时，把
itemHeight作为内联变量注入 HTML，例如<script>window.ITEM_HEIGHT = 80;</script>
- 客户端初始化虚拟列表时，优先读这个值，而不是等第一个真实项渲染后再测量
- 若真实项高度可能变化（比如图文混排），骨架只能按最小高度撑开，后续靠
resizeObserver动态校正，不能依赖骨架本身做高度预测
- 滚动节流函数里，不要对骨架节点做
getBoundingClientRect()——它已被移除，查不到
因为虚拟列表的滚动容器高度是动态计算的，骨架节点若结构不匹配，会直接破坏滚动条比例、导致跳动或白屏。真实列表用ul + li，骨架就必须是同样层级和语义的ul + li；如果骨架用div包裹一堆span，CSS里的display: flex或grid-template-rows就全乱套了。
常见错误现象：scrollTop突变、滚动条缩成一个小点、快速滚动时空白区域突然拉长。
- 骨架节点必须复用真实列表的外层容器标签（如
ul、ol、section），不能降级为div - 每个占位项必须对应一个
li或article，且带相同class与data-index属性 - 图片占位必须用
img标签 +src="data:image/svg+xml,..."，不能用div模拟——否则getBoundingClientRect()测高不准
固定高度虚拟列表中骨架节点怎么撑开空间
骨架元素塌陷不是样式没写对，而是浏览器把空li渲染成 0×0，后续 JS 动态插入真实内容时触发重排。必须靠 CSS 显式声明尺寸，且不能依赖父容器高度。
正确做法是：文字行用line-height × 行数，图片用aspect-ratio或padding-top + position: relative。
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
li自身设height: 80px（与真实项一致），禁用min-height或fit-content - 标题占两行 →
height: 2.4em（假设line-height: 1.2） - 图片占位 →
aspect-ratio: 16 / 9（现代）或padding-top: 56.25%+ 子元素position: absolute; top: 0; left: 0; width: 100%; height: 100% - 所有骨架元素加
overflow: hidden，防止 shimmer 动画溢出圆角
服务端直出骨架后，客户端怎么安全替换而不闪屏
关键不是“显示/隐藏”，而是“销毁”。用display: none或opacity: 0会让骨架节点长期驻留，JS 框架 hydration 时可能误判为差异节点，引发 DOM 替换闪动。
必须让骨架成为可识别、可精准移除的 HTML 片段。
- 服务端输出时，骨架节点带
data-skeleton="true"，真实内容节点带data-skeleton="false" - 客户端拿到数据后，用
document.querySelectorAll('[data-skeleton="true"]')批量获取，调用.remove()彻底销毁 - 禁止用
replaceWith()传字符串——容易 XSS；必须传DocumentFragment或真实Element - 替换动作需在
requestIdleCallback中执行，避免阻塞主线程影响滚动响应
虚拟列表+骨架屏组合下，滚动节流和占位高度缓存怎么协同
骨架屏撑开的是“静态占位高度”，而虚拟列表需要的是“动态可视范围计算依据”。两者共用同一套高度模型，但初始化时机不同：骨架高度用于首屏渲染，真实高度用于后续滚动计算。
最容易被忽略的一点：骨架节点的高度必须和后续真实项的itemHeight完全一致，否则calculateVisibleRange()算出来的startIndex会偏移。
- 服务端直出骨架时，把
itemHeight作为内联变量注入 HTML，例如<script>window.ITEM_HEIGHT = 80;</script> - 客户端初始化虚拟列表时，优先读这个值，而不是等第一个真实项渲染后再测量
- 若真实项高度可能变化（比如图文混排），骨架只能按最小高度撑开，后续靠
resizeObserver动态校正，不能依赖骨架本身做高度预测 - 滚动节流函数里，不要对骨架节点做
getBoundingClientRect()——它已被移除，查不到
