HTML严格模式由<!DOCTYPE html>触发，决定浏览器按W3C标准解析HTML/CSS/JS；而"use strict"仅约束JS执行。DOCTYPE缺失、位置错误或BOM字符会导致混杂模式，引发盒模型异常、乱码等问题。
严格模式由 DOCTYPE 触发，不是 JS 的 "use strict"
HTML 严格模式（标准模式）和 JavaScript 严格模式是两回事。HTML 的严格模式由 <!DOCTYPE html> 声明触发，它决定浏览器用 W3C 标准解析 HTML 结构、CSS 盒模型和脚本行为；而 "use strict" 是 JS 语法层面的约束，只影响 JS 执行上下文。混淆这两者会导致误判问题根源——比如盒模型错乱、margin: 0 auto 失效、或 IE6 下宽高计算异常，根本原因往往在 HTML 没声明 DOCTYPE，而非 JS 缺少严格模式。
DOCTYPE 缺失或错误会直接降级为混杂模式
只要 <!DOCTYPE html> 不在文件**第一行**、前面有空格/注释/BOM 字符，或拼写成 <!doctype html>（大小写敏感？不，但某些旧工具会误判）、<!DOCTYPE HTML PUBLIC ...>（XHTML 遗留写法），浏览器都可能回退到混杂模式。典型现象包括：
-
document.compatMode返回"BackCompat"而非"CSS1Compat" - IE 下
div设置width: 100px却包含 padding 和 border（怪异盒模型） -
getBoundingClientRect()返回值与 CSS 计算值不一致 - 某些 CSS 选择器（如
:focus-within）完全不生效
验证方式：打开 DevTools 控制台，输入 document.compatMode，结果必须是 "CSS1Compat"。
lang 和 charset 必须紧随 DOCTYPE 后立即声明
<html lang="zh-CN"> 和 <meta charset="utf-8"> 不只是“建议”，而是强制前置项。它们的位置直接影响解析起点：
立即学习“前端免费学习笔记（深入）”；
-
lang属性缺失 → 屏幕阅读器语音库切换失败，SEO 语言识别偏差 -
<meta charset="utf-8">未放在<head>最开头 → 浏览器可能先按系统默认编码（如 GBK）解析前几行，导致中文乱码，且无法被后续meta覆盖 - 若
<title>或外部<link>出现在charset之前 → Chrome 会触发重排，增加 FOUC（Flash of Unstyled Content）风险
正确顺序只能是：<!DOCTYPE html> → <html lang="zh-CN"> → <head> → <meta charset="utf-8"> → 其他 <meta> 和 <title>。
语义化标签不是“锦上添花”，而是严格模式下结构校验的基础
在标准模式中，HTML 验证器（如 W3C Validator 或 VS Code 的 HTMLHint）会对嵌套逻辑做深层检查。例如：
-
<main>内部出现多个<header>不报错，但出现<main>嵌套<main>会直接标记为错误 -
<article>必须有可访问标题（<h1>–<h6>），否则 ARIA 检查工具警告 -
<time datetime="2026-07-01">的datetime值格式错误（如缺年份或用斜杠分隔）会被 lint 工具拦截
这些检查只在标准模式下可靠生效。混杂模式下，解析器会宽容跳过很多结构错误，掩盖真实问题——等项目做大、接入自动化测试或无障碍审计时，才发现大量不可修复的语义断层。
实际落地时，最易被忽略的是 BOM 字节序和编辑器保存编码。哪怕写了正确的<!DOCTYPE html>，如果文件以 UTF-8 with BOM 保存，BOM（EF BB BF）会卡在首字节，导致浏览器无视 DOCTYPE。用 VS Code 打开文件后，右下角编码显示应为 UTF-8，而非 UTF-8 with BOM。 
