HTML骨架屏是占位加载的一种具体形态，即结构化、可预测、对布局友好的真实DOM占位方案，需定义尺寸、模拟视觉节奏并支持动画，区别于仅作提示且不参与布局的placeholder属性。
HTML骨架屏本身就是一种占位加载实现方式，不是“和占位加载有区别”，而是“占位加载的一种具体形态”。很多人误以为“占位加载”只是 placeholder 属性或简单 loading 动画，其实骨架屏才是结构化、可预测、对布局友好的占位加载——它不光占位，还占形、占尺寸、占节奏。
HTML骨架屏 ≠ 表单 placeholder 属性
表单里的 placeholder 是纯文本提示，只作用于 <input> 和 <textarea></textarea>，且不参与布局（无宽高、无盒模型），屏幕阅读器可能忽略它。骨架屏是真实 DOM 元素，必须带明确 width、height 或 aspect-ratio，否则一渲染就塌缩、引发重排。常见错误是把 placeholder 当成通用占位方案，结果在列表页或卡片流里完全失效。
- placeholder 不撑开容器，骨架元素必须自己定义尺寸
- placeholder 无法模拟图片/头像/段落的视觉节奏，骨架需按真实结构建模（如
.skeleton-avatar+.skeleton-content） - placeholder 没有动画控制权，骨架依赖
background渐变 +animation实现流动感
纯 HTML + CSS 骨架屏能不用 JS 吗？能，但有硬限制
可以只用 HTML + CSS 做静态骨架占位，比如预设好 3 条 .skeleton-item，靠 visibility: hidden 控制显隐。但关键限制在于：无法感知数据加载状态，不能自动切换内容。一旦 JS 被禁用或加载失败，骨架就永远卡住。所以生产环境必须搭配 JS 控制生命周期，哪怕只是最简逻辑：
- 用
document.querySelector('.skeleton').remove()替换整个骨架节点（比innerHTML = ''更安全） - 避免用
display: none切换，改用opacity: 0+pointer-events: none保布局流 - 若服务端能直出骨架 HTML（SSR 场景），则首屏可零 JS 渲染，但后续分页仍需 JS 接管
为什么 intersectionObserver 比 onscroll 更适合骨架屏触发？
无限滚动加载新数据时，如果等用户“滚到底部”再触发，骨架屏会突然出现大片空白，体验断层。而 IntersectionObserver 监听一个页尾占位符（如 <div id="infinite-trigger"></div>），配合 { rootMargin: '200px' } 提前 200px 触发，能让骨架屏自然衔接上一屏末尾，视觉更连贯。手动监听 onscroll 容易因 DOM 更新延迟、防抖漏判、快速滚动丢帧等问题导致骨架闪现或加载滞后。
立即学习“前端免费学习笔记（深入）”；
- onscroll 在快速滚动时每秒触发几十次，CPU 占用高；IntersectionObserver 是浏览器原生优化的异步回调
- rootMargin 设太小（如 '50px'）可能来不及渲染骨架就已滚过；设太大（如 '500px'）又可能白发请求
- 必须在每次加载完成后重新调用
observer.observe(triggerEl)，否则只触发一次
骨架屏替换真实内容时最容易被忽略的坑
很多人用 innerHTML 直接覆盖骨架容器，结果 Vue 组件丢失响应式、代码高亮没重刷、焦点中断、甚至 SEO 爬虫只抓到骨架 HTML。根本原因是 DOM 结构不一致或替换方式粗暴。真正安全的做法是保持骨架与真实内容的结构镜像：
- 同级元素数量、class 名、data 属性名必须严格一致（例如都叫
.item，不能骨架用.skeleton-item而真实内容用.post-item） - 推荐用
<template></template>标签存骨架结构，加载后用replaceWith()整体替换，避免子节点 diff 错乱 - 低配设备上加
will-change: opacity优化动画帧率，并监听prefers-reduced-motion关闭动画
结构一致性不是“看起来像”，而是框架 diff 的前提——这点在 SSR + hydration 场景下尤为致命，错一个 class 就可能导致整块内容重渲染。
