IE已停服，X-UA-Compatible仅对IE8–IE11有效且易被企业策略覆盖；现代项目应移除该meta，改用HTTP响应头（优先级更高），并关注国产双核浏览器的renderer meta。
IE 已于 2025 年 6 月 15 日正式终止支持，X-UA-Compatible 在现代开发中已无实际生效场景；但若你仍在维护遗留系统（如内网 IE11 环境、旧版 Edge 的 IE 模式），它仍是最后一道兼容性干预手段——不过约束力极弱，且极易被绕过。
为什么 X-UA-Compatible 常常不生效
它不是强制指令，而是一份“建议”。浏览器在多个信号冲突时会按固定优先级裁决：
-
X-UA-CompatibleHTTP 响应头 ><meta>标签（即使后者写得再早） - 用户手动启用「兼容性视图」或企业组策略强制降级，会直接覆盖前两者
-
<meta http-equiv="X-UA-Compatible">必须紧贴<head>开始，前面不能有注释、BOM、空格或非<meta charset>标签 - 若页面缺失
<!DOCTYPE html>，IE 可能直接进入 Quirks 模式，忽略该 meta
content 值的实际效果差异
不同取值对应不同解析逻辑，但仅对 IE8–IE11 有效（IE12+ 和新版 Edge 的 IE 模式已弃用该机制）：
-
IE=edge：请求以当前 IE 最高可用文档模式渲染（如 IE11 下为 11），但不保证成功——受组策略限制时可能回落到 7 或 8 -
IE=EmulateIE9：模拟 IE9，但尊重<!DOCTYPE>；若无 doctype，则退化为 Quirks，此时该值失效 -
IE=7,IE=9：多值写法已被 IE10+ 忽略，只认第一个（即IE=7），后续值无意义 -
chrome=1：早已失效——Google Chrome Frame 项目 2014 年停止维护，现代 IE/Edge 完全无视
服务端配置比 HTML meta 更可靠
因为 HTTP 头无法被页面内容干扰，且在 HTML 解析前就送达：
立即学习“前端免费学习笔记（深入）”；
- Nginx：在
server或location块中加add_header X-UA-Compatible "IE=edge"; - Apache：
Header set X-UA-Compatible "IE=edge"（需启用mod_headers） - Express：
res.setHeader('X-UA-Compatible', 'IE=edge');（必须在res.send()前调用） - IIS：可通过 web.config 的
<httpProtocol><customHeaders>添加
注意：若同时设置响应头和 meta，响应头胜出；但若响应头值是 IE=5 而 meta 是 IE=edge，IE 仍会按 IE=5 执行——它不比较“哪个更先进”，只机械执行收到的值。
真正起效前必须验证的三件事
别只看 HTML 源码里有没有写，要确认运行时是否真正加载并生效：
- 打开 DevTools → Network → 刷新页面 → 点击 HTML 请求 → 查看 Response Headers 中是否存在
X-UA-Compatible字段 - 在 IE11 或开启 IE 模式的 Edge 中，按 F12 → 切换到「仿真」标签页 → 查看「文档模式」显示的数字（不是「用户代理」）
- 检查浏览器地址栏右侧是否有「兼容性视图」图标；若有，说明用户或域策略已强制干预，
X-UA-Compatible完全无效
它从来不是一道锁，而是一张便条——写得再清楚，也拦不住别人撕掉重写。真要保兼容，优先重构 DOM/CSS/JS，而不是依赖这个早已被架空的 meta。
