词法分析由状态机驱动流式消费，HTMLTokenizer从字节流首帧启动，避开正则冲突与简单配对缺陷，依赖几十种状态的有限状态机处理注释、CDATA、引号等特殊场景。
词法分析不是一次性切字符串，而是状态机驱动的流式消费
浏览器不会等整个 HTML 文件下载完再开始解析，HTMLTokenizer 从字节流第一帧就开始工作。它不靠正则全局匹配，因为 <script></script> 里的 if (a d) 会和标签尖括号冲突；也不靠简单找 和 <code>> 配对，因为注释、CDATA、引号内内容都必须跳过。真正起作用的是一个几十种状态组成的有限状态机：比如遇到 进入 <code>TagOpenState，接着读到 / 切到 EndTagOpenState，读到字母就进 TagNameState，中间穿插处理属性值引号配对、转义序列（如 &、\'）、跨行注释等。
AtomicHTMLToken 是所有后续处理的原子单位
Blink 中每个 token 都是 AtomicHTMLToken 实例，不是字符串片段。它携带结构化字段：type_（如 kStartTag、kCharacter）、name_（"div"）、attributes_（键值对列表）、self_closing_（是否自闭合）。这个对象不负责渲染，也不参与样式计算，只做一件事：把原始字节流变成可被 HTMLTreeBuilder 消费的确定性输入。如果 token 构造失败（比如属性值没闭合引号），解析器会按容错规则补全或丢弃，但绝不会抛异常中断流程。
错误处理不是报错，而是“降级生成合理 DOM”
词法分析阶段遇到非法输入时，不会停止或报 SyntaxError。常见情况包括：
- 未闭合的
<p></p>：在BeforeHtmlInsertionMode下自动补<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p><div class="aritcle_card flexRow"> <div class="artcardd flexRow"> <a class="aritcle_card_img" href="/xiazai/skill8714" title="HTML汇报生成器"><img src="https://img.php.cn/upload/skill/000/000/081/179220974213190.jpg" alt="HTML汇报生成器" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a href="/xiazai/skill8714" title="HTML汇报生成器">HTML汇报生成器</a> <p>🚀 不用写一行代码！把项目总结、工作汇报、研究报告、技术文档、提案、数据看板直接变精美HTML。12种主题 × 11种背景动效 × 9种鼠标特效 × 10种边框样式 × 实时调色器 × 毛玻璃卡片 × PDF导出，生成后还能自由调色，零门槛AI直出。触发词：项目总结、工作汇报、PPT、生成报告、做个总结、HTML文档、数据报告、流程文档、会议纪要、技术文档、研究报告、数据看板、提案、做个展示页、帮我做个汇报、文档生成。</p> </div> <a href="/xiazai/skill8714" title="HTML汇报生成器" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>并继续 - 嵌套错误如
<div><p></p></div>：先关闭<p></p>，再关闭<div>，不还原已 emit 的 token <li>UTF-8 BOM 或开头空格：直接触发怪异模式，但 tokenization 照常进行</li> <li>注释中含 <code>-->外的短横：当作普通文本吞掉，不中断注释状态
这种设计让页面即使写错也能出结果，代价是 DOM 结构可能和源码不一致——这也是为什么不能靠肉眼检查 HTML 就断定最终渲染效果。
编码识别必须在 tokenization 开始前完成
<meta charset="utf-8"> 必须出现在前 1024 字节内，否则 Blink 已用默认编码（ISO-8859-1）解码了前面内容，再改也晚了。更隐蔽的问题是：VS Code “BOM on save” 选项、CMS 模板注入的不可见字符、甚至 HTTP 响应头里缺失 charset，都会导致后续 token 的 name_ 或 attributes_ 字段乱码。这时候看到的 AtomicHTMLToken.name_ 可能是 "á" 而不是 "á"，但解析器照常把它当标签名处理——DOM 树建出来了，只是节点名错了。
<div>，而是确保在任意脏数据、任意编码混杂、任意网络分块到达顺序下，都能持续输出结构正确的 <code>AtomicHTMLToken 流。一旦这一步出偏差，后面 DOM 构建、CSSOM 合并、Layout 计算全跟着漂移。
