用灰度色而非透明度做骨架屏，因opacity会导致模糊失焦，而灰度色（如hsl(210,0%,85%)）能保持清晰边界与结构稳定性，适配深色模式需css自定义属性+媒体查询，尺寸须严格匹配真实内容防跳变。
为什么用灰度色而不是透明度做骨架屏
骨架屏不是为了“看起来像在加载”，而是为了让用户感知到界面结构稳定、内容区域明确。用 opacity 降透明度会导致文字区域模糊、边框虚化，视觉上反而像“失焦”或“渲染异常”，尤其在深色模式下更易误判为 bug。灰度色（如 #e0e0e0）能保留清晰的块级边界和文字占位轮廓，且与真实内容色差可控，过渡自然。
常见错误现象：background-color: #f5f5f5 在浅色背景上几乎不可见；opacity: 0.3 让图标和按钮失去可识别形状。
- 推荐用 HSL 灰度：比如真实文字是
hsl(210, 10%, 20%)，骨架就用hsl(210, 0%, 85%)—— 保持色相一致，仅去饱和+提明度 - 避免直接写死
#ccc：它在不同设备亮度下对比度浮动大，WCAG 可访问性不稳 - 图片占位建议用
background-image: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%)模拟扫描动效，比纯色更显“加载中”
CSS 骨架屏如何适配深色模式
硬写两套 color 或 background-color 容易漏掉子元素，也难维护。正确做法是依赖系统级颜色语义，让骨架色随主题自动偏移。
使用场景：用户切换系统偏好后，骨架屏必须立刻响应，不能等 JS 重绘或刷新。
立即学习“前端免费学习笔记（深入）”；
- 用
CSS custom property定义基础灰阶：比如--skeleton-bg: hsl(210 5% 92%)，再在@media (prefers-color-scheme: dark)里覆盖为hsl(210 5% 18%) - 禁止对骨架元素单独加
class="dark:skeleton"：这会和主题切换逻辑耦合，JS 控制时易出竞态 - 所有骨架节点统一用
background-color: var(--skeleton-bg)，不写具体值
React 中用 CSS-in-JS 渲染骨架屏的性能坑
很多人用 styled-components 或 emotion 动态生成骨架样式，但没注意它会在每次组件渲染时重复计算 CSS 字符串，尤其列表项多时明显卡顿。
性能影响：100 个骨架项可能触发上百次 style 插入/重排，比纯 CSS 类名方案慢 3–5 倍。
- 骨架样式必须提取为静态
className，比如skeleton-text、skeleton-avatar，通过 className 切换状态 - 如果必须用 CSS-in-JS，用
css标签模板而非动态插值：css`background-color: ${theme.skeleton}`是错的，应写死变量或用useTheme+useMemo缓存 - 服务端渲染（SSR）时，骨架组件若含
useEffect或依赖 window 尺寸，会导致 hydration mismatch 错误 —— 骨架屏必须是纯静态 DOM 结构
骨架屏宽度高度怎么设才不跳变
跳变（content reflow）本质是骨架尺寸和真实内容不一致。浏览器先画骨架，再替换内容，若两者盒模型差异大，页面就会抖动甚至触发回流重排。
容易踩的坑：width: 100% 的骨架容器在字体加载前被压缩；height: auto 的段落骨架撑不开行高，内容进来后突然拉高。
- 文字类骨架用
min-width+min-height固定占位，比如标题设min-height: 1.5em，段落设min-height: 2.4em - 图片骨架必须带
aspect-ratio或明确width/height，禁用object-fit: cover等动态缩放属性 - Flex/Grid 容器里的骨架项，要和真实内容用同一套
flex或grid-area声明，否则布局引擎会重新计算位置
