document.documentMode 的实际取值逻辑是：5（怪异模式）、7（IE7）、8（IE8）、9（IE9）、10（IE10）、11（IE11），其值由IE解析器最终采用的渲染模式决定，而非仅由DOCTYPE声明控制，且受intranet区域策略等影响可能降级。
IE 兼容模式下 document.documentMode 的实际取值逻辑
html5 页面在旧版 IE（如 IE8/9/10）中是否走兼容模式，不取决于你写了 ，而取决于文档加载时 IE 解析器最终采用的渲染模式——这由 document.documentMode 决定。它不是布尔开关，而是具体数值：5（Quirks）、7（IE7 模式）、8（IE8）、9（IE9）、10（IE10）、11（IE11）。哪怕写了标准 DOCTYPE，如果页面被放进 intranet 区域或受企业策略影响，仍可能 fallback 到 documentMode === 7。
实操建议：
- 用
console.log(document.documentMode)在控制台直接验证，别只看 F12 开发者工具顶部显示的“文档模式”——那个有时会缓存或误报 - 禁用兼容视图设置：在 IE 设置 → “兼容性视图设置”里取消勾选“在兼容性视图中显示内网站点”
- 服务器端加响应头比 meta 更可靠：
X-UA-Compatible: IE=edge,chrome=1，避免被 meta 标签后置或 js 动态插入干扰
这个 meta 标签必须是 中**第一个** meta 或 http-equiv 类标签，且必须在任何 css、JS、甚至其他 meta（比如 charset）之前。IE 解析到它时还没开始构建 dom，一旦错过时机，后续再写就完全无效。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 写了
在前，X-UA-Compatible在后 → IE 直接忽略后者 - 用 JS 动态注入：
document.head.innerHTML += '...'→ 绝对不生效 - 模板里用
{% include 'common_head.html' %}引入，但 common_head 里混了其他 meta → 实际顺序失控
正确写法示例（必须严格顺序）：
Page html5 新语义标签在 IE 兼容模式下的真实表现
、
、
这些标签在 documentMode 下默认没有样式，也不被识别为块级元素——它们不是“不支持”，而是被当成未知 inline 元素处理，导致布局塌陷、CSS 选择器失效。
关键点：
-
documentMode === 7时，document.createElement('section')返回的是一个无样式的HTMLUnknownElement，不是HTMLElement - 单纯引入 html5shiv.js 不够：它只解决 createElement 问题，但若页面已用
display: block声明过这些标签，shiv 可能被覆盖 - 兼容方案必须同时满足：① shiv 注册元素；② CSS 显式声明
section, article, nav { display: block; }；③ 确保 CSS 在 shiv 执行后加载（或用document.write注入）
XMLHttpRequest 和 fetch 在 IE 兼容模式下的行为分叉
IE8/9 的 XMLHttpRequest 对象不支持 responseType = 'json'，也不支持 timeout 属性；而 fetch 在所有 IE 版本中都不存在。但更隐蔽的问题是：当页面运行在 documentMode === 7 时，即使你用了 polyfill（如 whatwg-fetch），底层 XHR 仍受限于 IE7 的安全策略——比如跨域请求会被静默拦截，且不触发 onerror，只卡在 readyState === 0。
排查建议：
- 不要只检查
if (window.fetch)，要结合document.documentMode 做降级分支 - IE8/9 中 XHR 的
getResponseHeader()对自定义 header（如X-Request-ID）返回NULL，不是空字符串 - 发送 JSON 数据时，IE8 的 XHR 不支持
JSON.stringify()自动序列化，必须手动转成字符串并设Content-Type: application/json
真正麻烦的不是语法兼容，而是不同 documentMode 下网络栈的底层限制——这些差异往往只在特定内网环境复现，本地调试容易漏掉。