<head>不是可有可无的配置区，它直接决定浏览器渲染起点、页面呈现效果及搜索引擎理解方式；顺序错误会导致白屏、乱码、移动端缩放失效和SEO失败，其中<meta charset="UTF-8">必须为<head>首个标签，<title>次之，<meta name="viewport">紧随其后，<link rel="stylesheet">需靠前且禁用@import，<script>须带defer或async属性。
<head> 不是“可有可无的配置区”，它直接决定浏览器是否能开始渲染、渲染成什么样、以及搜索引擎怎么理解这个页面。没写对，白屏、乱码、移动端缩放失灵、SEO掉坑，全都是立刻可见的后果。
为什么 <head> 顺序错了会导致白屏
浏览器解析 HTML 是从上到下流式进行的。一旦遇到未加控制的 <script> 或阻塞型 <link rel="stylesheet">，就会暂停 DOM 构建，等资源下载、解析、执行完才继续——这意味着首屏内容根本不会出现，直到那个 JS 或 CSS 加载完。
-
<script src="app.js">没加async或defer→ 阻塞解析，首屏延迟不可控 -
<link rel="stylesheet" href="main.css">放在<script>后面 → 样式表加载前，浏览器不敢渲染任何内容（FOUC 风险） -
<meta charset="UTF-8">没放在最前面 → 前面已读取的中文可能已被错误解码为乱码，无法回退
<meta charset="UTF-8"> 必须紧贴 <head> 开头
这个声明不是“写了就行”，而是浏览器解码页面的起点。如果它出现在 <title> 或其他 <meta> 后面，前面已读入的字节可能已被按默认编码（如 ISO-8859-1）错误处理，导致标题、描述甚至内联脚本里的中文变成问号或方块。
- 必须是
<head>中**第一个或第二个标签**（<meta charset>应排第一，<title>可排第二） - 不能用旧式写法
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，部分浏览器不识别为编码声明 - 服务端响应头中的
Content-Type优先级更高，但前端无法控制时，<meta charset>是唯一防线
<meta name="viewport"> 缺失会让移动端彻底失效
没有它，移动浏览器会以桌面模式渲染页面：宽度固定为 980px 左右，文字极小，用户必须双指放大才能阅读。这不是“体验不好”，而是根本不可用。
立即学习“前端免费学习笔记（深入）”；
- 标准写法：
<meta name="viewport" content="width=device-width, initial-scale=1.0"> - 不要加
user-scalable=no—— 屏蔽缩放违反 WCAG 可访问性要求，且 iOS Safari 16+ 已忽略该属性 - 路径无关，但必须存在；SPA 路由切换时无需重复注入，它是全局生效的
<link rel="icon"> 和 <link rel="stylesheet"> 的位置陷阱
图标不显示、样式闪动、FOUT/FOUC，往往不是资源本身问题，而是 <link> 在 <head> 中的位置或属性错配。
-
<link rel="icon">应放在<title>之后、其他<link>之前；用绝对路径（如/favicon.ico），避免子路由下 404 -
<link rel="stylesheet">必须靠前，且禁止在 CSS 文件里用@import—— 它会引发额外网络请求并阻塞渲染 -
<link rel="preload">不要滥用：只用于当前页立即需要的关键资源（如首屏字体、关键 CSS），否则反而抢带宽
真正难的不是记住这些规则，而是在构建工具自动注入、SSR 渲染、SPA 动态更新等场景下，确保最终输出的 <head> 仍满足顺序和语义约束——比如 Webpack 插件插入的 <script> 是否压到了 <meta charset> 下面，React Helmet 更新 <title> 时有没有把旧的 <meta description> 漏掉。这些细节，一不留神就埋进生产环境。
