link 必须置于 <head> 且禁用 @import，否则移动端首屏渲染阻塞、重绘抖动；preload 需正确配 as 并紧贴 charset/viewport 后；关键 CSS 应内联（≤14KB），避免 @import 或跨域字体破坏内联效果。
link 标签放错位置或配错属性，会直接让移动端首屏按钮点不动、文字跳、布局抖——不是 JS 没执行，而是浏览器根本没画出来。
为什么 link rel="stylesheet" 必须在 <head> 里且不能带 @import
移动端 WebView（尤其旧款安卓）解析 HTML 时，一旦遇到 link 就立刻阻塞 DOM 构建，等 CSS 下载+解析完才继续。这个机制只在 <head> 里有效：此时 DOM 还没开始渲染，CSSOM 就绪后可一次性绘制；如果 link 在 <body> 里，DOM 已部分构建并尝试渲染，再加载 CSS 只能重绘，用户肉眼可见“先白后跳”。
更糟的是 @import：它藏在 CSS 文件里，浏览器必须先下载并完整解析主样式表，才能发起被 import 的文件请求。实测在 3G 网络下比并行 link 多拖 300–800ms，首屏按钮背景色、字体声明全卡住。
-
@import不会被预加载器识别，无法与 HTML 并行下载 - PostCSS 内联
@import后 source map 易断，真机调试时定位不到样式来源 - 暗色主题等条件加载，应改用
<link rel="stylesheet" media="(prefers-color-scheme: dark)">，而非@import套壳
link rel="preload" 加错 as 或位置反而拉长白屏时间
preload 是调度指令，不是加速开关。加错地方，会抢带宽、挤掉真正关键的 HTML 或 CSS 请求。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
常见错误现象：<link rel="preload" href="app.js"> 放在 <head> 里，但 app.js 依赖 vendor.js，而后者没 preload，结果 app.js 下载完卡住等待，白屏更久。
- 必须配
as属性：<link rel="preload" href="font.woff2" as="font" crossorigin>，否则按as="fetch"处理，优先级错乱 - 首屏关键图片用
as="image"，但别对loading="lazy"的图也 preload——Chrome 可能降级或丢弃，策略冲突 -
preload应紧贴<meta charset>和<meta name="viewport">之后，避免被其他脚本或注释延迟触发
移动端特别容易踩的 link 静默失效点
这些错误不会报错，但会让首屏交互延迟 400ms 以上，尤其在低端安卓机上：
-
rel拼错：写成rel="style"或rel="css"，浏览器当普通链接处理，不阻塞也不解析 -
href路径返回 404 或空响应，DevTools Network 面板里看状态码和响应体才能发现 -
link被包裹在<script>或<meta>里，不是<head>的直接子元素，某些 WebView 直接忽略 - 字体
preload漏了crossorigin，跨域字体请求被 CORS 拦截，文字先崩再重排
真正影响首屏交互的不是有没有 link，而是 CSS 加载时机是否可控
把 link 放对位置只是解决顺序问题，没解决延迟问题。网络往返、TLS 握手、服务器响应都会让外部 CSS 至少延迟几百毫秒。
- 首屏必需样式（如 header 高度、按钮背景色、基础字体声明）必须提取出来，用
<style></style>内联在<head>最顶部 - 内联 CSS 体积控制在 ≤14 KB，否则拖慢 TTFB 和 TCP 初始拥塞窗口
- 非关键 CSS 用
<link rel="preload" as="style" href="non-critical.css" onload="this.rel='stylesheet'">，注意 IE 不支持onload，需 fallback
最容易被忽略的是：内联 CSS 里写了 @import，或者用了未声明 crossorigin 的字体 URL——这两样会让内联失去意义，浏览器仍要等外部资源就绪才敢渲染。
