骨架屏CSS必须内联到head中，因@media不控制下载仅控制应用，外链或@import仍会引发网络请求导致弱网白屏；内联后可用@media作显隐开关，断点需匹配逻辑视口宽度。
骨架屏 CSS 必须内联，不能靠 @media 控制加载时机——否则低网速下照样白屏。 浏览器解析 HTML 时根本不会等外部 CSS，而 @media 只是开关规则，不改变下载行为。真要“优先”在弱网下生效，得让骨架样式零延迟可用。
为什么 @media 不能解决低网速下的骨架屏加载问题
常见误解是给骨架屏加个 @media (max-width: 768px) 就能“只在手机上加载”，但实际所有带 @media 的 CSS 都随主文件一起下载。弱网下：主 CSS 文件卡在传输中 → 骨架样式没解析 → 页面空白 200–500ms → 用户已以为卡死。
-
@media不控制下载，只控制应用；它甚至无法阻止大图、字体、动画等冗余规则被下载 - 用
<link media="(max-width: 767px)">引入骨架屏 CSS？不行——浏览器仍需发起一次网络请求，弱网下这个请求本身就会延迟 - 用
@import更糟：它阻塞主 CSS 解析，首屏白屏时间可能翻倍
正确做法：骨架屏 CSS 必须内联到 <head> 中
服务端渲染（SSR）或构建时，把精简后的骨架屏样式直接写进 HTML 的 <head>，不走任何网络请求。
- 只保留必要类名，如
.skeleton、.skeleton-text、.skeleton-avatar，删掉注释和空行 - 渐变动画用
background-size: 200% 100%+animation，别用复杂滤镜或 transform - 所有颜色值写成十六进制（如
#f0f0f0），避免rgb()或变量导致兼容性风险 - 加
!important确保不被后续外链 CSS 覆盖，例如：.skeleton { background: linear-gradient(...) !important; }
移动端断点要对齐逻辑视口，不是设计稿像素
内联骨架屏后，若想在平板或横屏手机上隐藏或微调，@media 才真正起作用——但此时它只是“显隐开关”，不是“加载开关”。断点必须匹配真实设备逻辑宽度。
立即学习“前端免费学习笔记（深入）”；
- iPhone 14 Pro 竖屏逻辑宽度是
430px，不是物理像素1290px；写@media (max-width: 430px)比768px更精准 - iPad Air（第5代）竖屏逻辑宽度约
820px，建议用@media (min-width: 768px) and (max-width: 1024px)单独适配 - 避免
@media (max-height: ...)：地址栏收起/展开会让window.innerHeight突变，导致骨架屏闪烁 - 深色模式适配用
@media (prefers-color-scheme: dark)，不要用 JS 动态切 class，否则弱网下会闪回亮色
容易被忽略的细节：内联样式里不能有 @import 或外链字体
内联的骨架屏 CSS 是纯文本插入 HTML，一旦里面写了 @import url("fonts.css") 或 @font-face 引用远程字体，就又引入了额外请求，彻底破坏“零延迟”目标。
- 字体图标一律用 inline SVG 或系统字体替代；如果必须用 icon font，请确保字体文件已转为 base64 内联（但体积 >4KB 就不推荐）
- 所有路径（如
url(./img/sprite.png)）在内联 CSS 中都会失效，一律改用 data URL 或删除 - 构建工具（如 Webpack/Vite）打包时，检查是否误把骨架屏 CSS 当作普通资源处理，导致它被抽离成外链
真正卡住低网速体验的，从来不是“要不要骨架屏”，而是“骨架屏能不能在 HTML 解析完第一行时就生效”。只要它还依赖一次 HTTP 请求，就不是真正的首屏保障。
