name属性用于描述网页元数据（如description、keywords）、供搜索引擎分类；http-equiv属性则模拟HTTP响应头（如refresh、content-security-policy），二者均需配合content值使用，非标准写法将被爬虫忽略。
搜索引擎只认标准 name 和 http-equiv 属性
Google、Bing、百度等主流爬虫在解析 <meta> 时，严格按 HTML 规范执行：只提取 name（如 description、robots）或 http-equiv（如 refresh、content-security-policy）属性对应的 content 值。任何非标准写法——比如 <meta data-user="xxx"> 或缺失 content 的 <meta name="foo">——都会被直接跳过，不参与索引或渲染决策。
charset 必须放在 <head> 最前面，否则乱码风险真实存在
浏览器解析 HTML 是流式的，一旦遇到非 UTF-8 字符且 <meta charset="UTF-8"> 位置靠后（比如在 <link> 或内联 <style> 之后），前面已读入的字节可能已被错误解码，导致标题、描述等元数据出现乱码，进而影响 SEO 展示。W3C 明确要求它必须是 <head> 中第一个可解析的标签（除 <!DOCTYPE> 和 <html> 外）。
-
<meta charset="UTF-8">应紧贴<head>开始，前面不插任何 JS、CSS 或注释 - 不要用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">替代——它兼容性差，且部分旧爬虫不识别 - 服务端响应头
Content-Type: text/html; charset=utf-8优先级高于 meta，但不能省略 meta，因部分静态托管平台不支持自定义响应头
viewport 写错等于放弃移动端体验
移动端页面“缩成一团”或“文字糊成一片”，90% 是因为 <meta name="viewport"> 没生效或参数残缺。爬虫和浏览器都依赖它判断页面是否适配移动设备，缺失或错误会降低移动友好度评分。
- 必须写为
<meta name="viewport" content="width=device-width, initial-scale=1.0">——二者缺一不可 - 动态插入（如 JS 创建并 append）完全无效：浏览器只在初始 HTML 解析阶段读取它
- 禁止加
user-scalable=no：不仅 WCAG 可访问性不合规，iOS 16.4+ 已无视该指令，还可能触发安卓 WebView 的 DPR 校正失败 - CMS 或 SSR 模板中重复注入多个 viewport 标签，会导致行为不可预测，应确保全局唯一
自定义数据别塞进 <meta>，用 <script type="application/json"> 更安全
想把用户信息、配置项等服务端数据传给前端？硬塞进 <meta name="app-config"> 看似方便，但 name 值一旦与未来 HTML 标准冲突（比如某天规范新增了 name="app-config"），你的数据就可能被覆盖或忽略。更稳妥的方式是用语义明确、专为数据设计的容器。
立即学习“前端免费学习笔记（深入）”；
- 推荐写法：
<script type="application/json" id="initial-data">{"user":{"id":123}}</script> - 读取方式：
const data = JSON.parse(document.getElementById("initial-data").textContent) - 优势：不污染元数据语义、W3C 验证通过、无未来兼容风险、支持任意嵌套结构
- 注意：避免内联脚本含未转义的
</script>字符串，需对 JSON 做 HTML 实体转义（如）
charset 和 viewport 的位置与时序约束——它们不是“写了就行”，而是“必须在特定位置、以特定形式、在 HTML 解析最早期出现”。其他所有元数据，都是建立在这两个基础之上的。 
