通过document.compatMode可判断文档模式：返回"CSS1Compat"为标准或准标准模式，"BackCompat"为混杂模式；准标准模式需结合DOCTYPE进一步区分，最稳妥做法是确保为文件首行首字符。
怎么判断当前页面处于哪种文档模式
打开浏览器开发者工具（F12），在控制台执行 document.compatMode：返回 "CSS1Compat" 表示标准模式（standards mode），返回 "BackCompat" 表示混杂模式（quirks mode）。准标准模式（almost standards mode）也返回 "CSS1Compat"，需结合 DOCTYPE 进一步区分。
哪些 DOCTYPE 会触发 quirks mode
只要 DOCTYPE 缺失、拼写错误，或使用过时的声明，浏览器大概率降级到 quirks mode。常见踩坑点包括：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
—— frameset 型 DOCTYPE 在多数现代浏览器中触发准标准模式，但在 IE6–IE8 中可能退化为 quirks—— 缺少 URI（即引号里的 DTD 地址），IE6–IE9 直接进入 quirks- DOCTYPE 前存在任何字符（哪怕一个空格、
<!-- comment -->或 BOM），IE 系列（尤其 IE6–IE9）立即 fallback 到 quirks （小写 doctype）在旧版 IE 中无影响，但某些校验工具或 CMS 模板引擎可能误判，建议统一用大写 <code>
standards mode 和 almost standards mode 的实际差异在哪
二者都返回 document.compatMode === "CSS1Compat"，但渲染行为有细微差别，主要集中在表格和图片相关布局：
- 在 almost standards mode 下（如 XHTML 1.0 Transitional 或 HTML 4.01 Transitional 带完整 URI），
<table> 中的图片默认基线对齐方式不同，可能导致行高异常<li>图片的 <code>vertical-align行为在 almost standards mode 中更接近标准，但在 quirks mode 下会忽略部分对齐规则 - 盒模型本身无区别 —— 二者都采用 W3C 标准盒模型（width 不含 padding/border），这点常被误认为是差异点
- 准标准模式本质是“对表格/图片做一点点妥协的标准模式”，不是中间态，也不推荐主动选用
- 服务端模板（如 PHP、JSP）在 DOCTYPE 前输出了空白、调试
echo或 UTF-8 BOM（尤其 Windows 记事本保存的 .html 文件） - 前端构建工具（如 Webpack/Vite）注入的 runtime 脚本或注释被插在 DOCTYPE 之前
- 某些 CMS（如早期 WordPress 主题、Drupal 模板）动态拼接头部时漏掉 DOCTYPE，或把
<meta http-equiv="X-UA-Compatible" content="IE=edge">放在 DOCTYPE 前面 - IE 兼容性 meta 标签（如
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">）无法修复缺失 DOCTYPE 导致的 quirks —— 它只影响 IE 的排版引擎版本，不改变文档模式判定逻辑
为什么现在还可能遇到 quirks mode
不是因为开发者故意写错，而是以下场景容易意外触发：
立即学习“前端免费学习笔记（深入）”；
最稳妥的做法只有一条：确保 是 HTML 文件的**第一行、第一个字符**，前面零字节。其他所有“兼容性补丁”都是临时止痛，不是根治方案。
