<meta http-equiv="X-UA-Compatible">是IE8–IE11渲染硬性开关，必须置于<head>最开头（零BOM、零空格、零注释、零前置标签），content值严格为IE=edge等大写格式，否则退至Quirks模式；HTTP响应头优先级更高，国产双核浏览器需额外添加renderer meta。
meta http-equiv="X-UA-Compatible" 不是“可选配置”，而是 IE8–IE11 渲染模式的硬性开关——它一旦失效，页面大概率直接退回到 Quirks 模式或 IE5 文档模式，JS 执行异常、CSS 盒模型错乱、querySelector 失效等现象会集中爆发。
必须放在 <head> 最开头，且零干扰
IE 解析 HTML 时，只要开始构建 DOM，就彻底忽略后续所有 meta http-equiv="X-UA-Compatible"。这意味着：
- 前面不能有任何字符：UTF-8 BOM、空格、换行、注释（
<!-- -->）、<title>、甚至其他<meta> - 推荐写法：
<meta http-equiv="X-UA-Compatible" content="IE=edge">紧贴<head>开始，后面紧跟<title> - 常见失效场景：PHP/Node 模板自动注入 BOM；编辑器保存为“UTF-8 with BOM”；IDE 预览服务插入调试脚本或注释
content 值大小写敏感且格式严格
IE 对该属性值解析极脆弱，稍有偏差即降级为默认文档模式：
-
ie=edge（小写）无效；IE = edge（含空格）无效；IE=Edge（首字母大写但其余小写）部分版本不识别 - 合法写法仅限：
IE=edge、IE=10、IE=EmulateIE11、IE=7—— 全部大写IE=+ 小写或驼峰后缀 -
chrome=1已无实际意义：Google Chrome Frame 插件自 2014 年起停止维护，现代 Edge（Chromium 内核）完全不识别该指令
meta 与 HTTP 响应头冲突时以 header 为准
当服务器通过响应头发送 X-UA-Compatible: IE=5，而 HTML 中写 content="IE=edge"，IE 会强制采用 header 的值——meta 被静默覆盖：
立即学习“前端免费学习笔记（深入）”；
- Nginx 示例：
add_header X-UA-Compatible "IE=edge";（需放在server或location块内） - Express 示例：
res.setHeader('X-UA-Compatible', 'IE=edge'); - 优先级顺序：
HTTP header > meta tag；若两者共存且冲突，header 赢；若 header 值非法（如IE=xxx），IE 会 fallback 到meta - 验证方式：打开 DevTools → Network → 找 HTML 请求 → Headers → Response Headers，确认是否存在
X-UA-Compatible字段
国产双核浏览器需额外声明 renderer
360、QQ、搜狗等浏览器在 IE 内核下仍可能无视 X-UA-Compatible，必须补上国产特供 meta：
-
<meta name="renderer" content="webkit">（强制 WebKit 内核） -
<meta name="renderer" content="ie-comp">（IE 兼容模式） -
<meta name="renderer" content="ie-stand">（IE 标准模式） - 该标签无标准定义，仅对特定 UA 生效；顺序无关，但建议紧随
X-UA-Compatible后放置
真正麻烦的不是怎么写，而是你根本不知道它有没有生效——F12 开发者工具里的 “Document Mode” 显示值，可能被缓存、被重定向、被中间代理篡改，最稳妥的方式永远是抓包看响应头 + 实机 IE11 打开 F12 实时观察控制台报错和渲染结果。
