X-UA-Compatible 在现代项目中已无实际作用，因其仅对已终止支持的 IE8–IE11 生效，且受兼容性列表、BOM、解析顺序等限制而极易失效；当前重点应转向国产双核浏览器的 renderer 控制及服务端响应头配置。
X-UA-Compatible 在现代项目中已无实际作用，别再往 <head> 里加它了。
为什么 X-UA-Compatible 现在基本失效
这个 meta 标签只对 IE8–IE11 生效，而微软已于 2022 年 6 月正式终止所有 IE 版本的支持——包括安全更新。Windows 10/11 默认禁用 IE 模式，Edge 浏览器中启用 IE 模式需手动开启，且仅限极少数政企内网场景。
-
content="IE=edge"不保证触发最新文档模式：若页面被组织级兼容性列表（Compatibility View List）收录，仍会强制降级到IE7文档模式 -
chrome=1依赖 Google Chrome Frame 插件，该插件早在 2014 年 2 月就已停止维护，且仅支持 IE6–IE9 - 即使写了
content="IE=edge,chrome=1"，只要 HTML 开头有 BOM 字节、<script>阻塞解析或空格错位（如content=" IE=edge"），标签就完全失效
国产双核浏览器该用哪个 meta 控制内核
360、QQ、搜狗等浏览器识别的是 renderer，不是 X-UA-Compatible。它们的切换逻辑独立于 IE 文档模式，且至今仍在广泛使用。
- 要强制走 WebKit 内核（“极速模式”），写：
<meta name="renderer" content="webkit"> - 要走 IE 标准模式（非兼容模式），写：
<meta name="renderer" content="ie-stand"> - 要走 IE 兼容模式（模拟旧版 IE 行为），写：
<meta name="renderer" content="ie-comp"> - 注意：
content值严格区分大小写；webkit不是Webkit或WEBKIT - 建议同时加
<meta name="force-rendering" content="webkit">，部分旧版双核浏览器需此标签才生效
真要支持 IE 模式，必须用 HTTP 响应头
极少数政企内网系统仍要求 IE 模式运行时，X-UA-Compatible 必须通过响应头发送——因为它的优先级高于 <meta>，且不受 HTML 解析顺序、JS 阻塞、BOM 影响。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置：
add_header X-UA-Compatible "IE=edge";（注意引号） - Express 中：
res.setHeader('X-UA-Compatible', 'IE=edge'); - 验证方式：打开 DevTools → Network → 找 HTML 请求 → Headers → Response Headers → 查看是否存在
X-UA-Compatible - 不要混用：如果响应头已设，再在 HTML 里写
<meta http-equiv="X-UA-Compatible">会被忽略，但可能干扰调试判断
IE=EmulateIE7 和 IE=7 的区别不是“要不要 DOCTYPE”，而是“会不会进 Quirks”
这两个值在 IE8+ 中行为差异非常具体，容易导致线上错版：
-
IE=7：强制进入 IE7 标准模式，无视<!DOCTYPE html>是否存在或是否合法 -
IE=EmulateIE7：先检查 DOCTYPE——有效则进 IE7 标准模式；无效或缺失则退化为 IE5 Quirks 模式（盒模型、CSS 解析全不同） - 真实项目中，一旦用了
Emulate*，就必须确保每个页面都带合法<!DOCTYPE html>，否则上线后部分页面会突然错版 - IE11 已不推荐用
EmulateIE9：它的标准模式接近 IE10，但 Quirks 模式行为更不可控
现在真正需要控制的，是国产双核浏览器的 renderer，以及服务端能否稳定输出 X-UA-Compatible 响应头——而不是在 HTML 里反复调试一个早已失效的 meta 标签。
