X-UA-Compatible在现代浏览器中已完全失效，仅适用于明确需IE11支持的内网系统；其meta标签必须紧贴<head>开头、无任何前置字符，content值严格区分大小写和空格，合法值仅IE=edge等少数几种。
X-UA-Compatible 在现代政务系统和主流浏览器中已完全失效，写它不如不写——除非你还在维护明确要求 IE11 运行的内网系统，且确认用户真用 IE 模式访问。
IE=edge 写了但没生效？先看是不是位置错了
这个 meta 不是“放在 <head> 里就行”，而是必须紧贴 <head> 开始，前面不能有任何字符：零 BOM、零空格、零换行、零注释、零其他标签。哪怕前面有个 <meta charset="utf-8"> 都可能让它失效（虽然 charset 通常被宽容，但不保险）。
- 常见踩坑点：
VS Code默认保存为 “UTF-8 with BOM”，导出 HTML 后开头多出三个不可见字节，X-UA-Compatible直接被忽略 -
Webpack或Vite插件在 HTML 中注入调试脚本或<!-- dev comment -->，插在了meta前面，导致失效 - PHP 模板用
file_get_contents()读取 HTML 后echo，BOM 被原样输出 - 正确写法示例：
<meta http-equiv="X-UA-Compatible" content="IE=edge"><title>首页</title>—— 中间不能有换行或空格
content 值大小写和空格敏感，错一个字符就退到 Quirks 模式
IE 对 content 值解析极其脆弱。ie=edge、IE = edge、IE=Edge 全部无效，会直接 fallback 到 IE5 Quirks 模式，JS 选不到元素、CSS 盒模型错乱、querySelector 返回 null 都是典型表现。
- 合法值只有：
IE=edge、IE=7、IE=8、IE=EmulateIE11—— 注意全部大写IE=+ 小写/驼峰后缀 -
chrome=1已彻底无意义：Google Chrome Frame 自 2014 年停更，所有现代 IE/Edge 版本完全不识别 - 多值写法如
IE=edge,chrome=1不仅 W3C 验证失败，部分旧 IE 还会因解析异常直接降级
HTTP 响应头比 meta 更可靠，但同样过时
如果服务端设置了 X-UA-Compatible 响应头，它永远优先于 HTML 中的 meta 标签。但要注意：这个响应头对 Chrome、Firefox、新版 Edge 和所有国产双核浏览器的极速模式也完全无效。
立即学习“前端免费学习笔记（深入）”；
- Nginx 配置：
add_header X-UA-Compatible "IE=edge";（需启用headers_module） - Express 配置：
res.setHeader('X-UA-Compatible', 'IE=edge');—— 必须在res.send()之前调用 - IIS 配置：通过
web.config的<httpProtocol><customHeaders>添加 - 验证方式：打开 DevTools → Network → 找 HTML 请求 → Headers → Response Headers，确认是否存在该字段
国产双核浏览器根本不认 X-UA-Compatible，得加 renderer meta
360、QQ、UC 等浏览器在 IE 内核下压根不解析 http-equiv="X-UA-Compatible"。它们靠 name="renderer" 控制内核切换，不加就大概率走兼容模式（模拟 IE7），页面样式和 JS 行为全崩。
- 默认走极速模式（Chromium 内核）：
</meta name="renderer" content="webkit"> - 强制走 IE 标准模式（非兼容模式）：
</meta name="renderer" content="ie-stand"> - 需要模拟旧版 IE（极少用）：
</meta name="renderer" content="ie-comp"> - 这些
meta同样必须放在<head>最前面，且不能有前置空白或注释
真正关键的不是有没有写 X-UA-Compatible，而是运行时文档模式是否被采纳——打开 IE11 的 F12 工具，看「文档模式」显示的是「Edge」还是「5」。如果显示 5，说明整个兼容性链条已经断裂，光改 HTML 没用，得从 BOM、服务端头、国产浏览器 meta、甚至组策略和用户手动兼容视图设置一层层排查。
