<link>标签必须放在<head>中，因其阻塞HTML解析与渲染以确保样式正确；放到底部会导致白屏更久、FOUC风险升高，优化关键在提取关键CSS、合理使用media属性、配置HTTP缓存及CDN。
link 标签放 <head> 里是正确做法，不是“可以放底部”的问题
浏览器解析 HTML 是流式进行的，遇到 <link rel="stylesheet"> 会立即发起 CSS 请求，并**阻塞后续 HTML 解析与渲染**，直到该 CSS 加载并解析完成。这恰恰是浏览器保障样式正确性的机制——不能先画无样式的页面再重绘。所以把 <link> 放到底部（比如 </body> 前），会导致：HTML 已解析完、DOM 构建完毕，但浏览器仍卡在等待 CSS，最终整个页面白屏更久，且可能触发 FOUC（Flash of Unstyled Content）风险反而升高。
- 现代浏览器对
<head>中的<link>有预加载优化，能尽早发起请求 - 放在
<body>底部时，CSS 加载完成前，DOMContentLoaded事件不会触发，JS 执行被拖慢 - 部分构建工具（如 Webpack + mini-css-extract-plugin）默认也只生成
<head>内的<link>
真正要解决的是「阻塞」本身，而不是挪位置
想让 CSS 不阻塞首屏渲染，核心不是移动 <link> 标签，而是控制它加载的**内容量和优先级**：
- 提取关键 CSS（Critical CSS）：把首屏用到的样式内联到
<style>标签中，用media="print"或onload回调切换回正常媒体类型 - 非关键 CSS 用
rel="preload"+as="style"预加载，再通过 JS 动态插入<link rel="stylesheet"> - 确保服务器开启 HTTP/2 或 HTTP/3，多个
<link>可并行传输，减少队列等待 - 避免在 CSS 文件中用
@import，它会串行加载，比<link>更慢
media 属性不是摆设，用错反而加重阻塞
media 属性决定浏览器是否**立即加载并应用**该样式表。如果写成 media="screen"（默认值）或 media="all"，浏览器会立刻加载；但如果写成 media="(min-width: 768px)"，浏览器会先做媒体查询匹配，仅当条件满足时才加载——这对响应式断点外的设备是有效优化。
- 慎用
media="print"存放非打印样式：虽然不阻塞屏幕渲染，但若误把首屏样式放进去，页面会彻底无样式 -
media值必须是合法媒体查询，写成media="not screen"或语法错误会导致浏览器忽略该属性，退化为media="all" - 动态修改
link.media的 JS 逻辑，需注意触发时机——太早改，CSS 还没加载；太晚改，样式已错乱
HTTP 缓存和 CDN 配置比标签位置影响更大
用户第二次访问时，CSS 是否阻塞，几乎完全取决于缓存策略。一个没设 Cache-Control 或 ETag 错配的 CSS 文件，哪怕放在 <head>，也会重新请求、重新阻塞。
立即学习“前端免费学习笔记（深入）”；
- 静态 CSS 文件应配置长期缓存：
Cache-Control: public, max-age=31536000 - 文件名带哈希（如
main.a1b2c3.css），确保内容变更后 URL 变更，绕过旧缓存 - CDN 节点若未缓存 CSS，或设置了
Cache-Control: no-cache，本地位置再优也没用 - 检查实际网络面板：看 CSS 请求是否返回
200 OK（未命中缓存）还是304 Not Modified或200 OK (from memory cache)
<link> 塞到 DOM 底部假装看不见。 
