tokenizer本身不产生漏洞，但它是html解析最前端且最敏感的环节：字符编码错位或token切分异常会导致后续dom构建、转义逻辑和xss防御全部失效；其核心流程是先按charset声明将字节解码为unicode字符，再依html语法切分为token；若声明编码与实际不符（如gbk文件声明utf-8），就会引发乱码、标签截断、注释提前闭合等问题。
HTML 渲染引擎的令牌化（Tokenizer）过程本身不产生“漏洞”，但它是整个解析链里最前端、最敏感的环节——一旦字符编码错位或 Token 切分异常，后续所有 DOM 构建、转义逻辑、XSS 防御都会失效。排查这类问题，关键不是找“漏洞代码”，而是验证「字节 → 字符 → Token」这三步是否一致。
Tokenizer 如何把字节变成 Token？
浏览器拿到 HTML 文件后，第一步是按 charset 声明（如 <meta charset="UTF-8">）将原始字节流解码为 Unicode 字符；第二步才交给 Tokenizer 按 HTML 语法切分。如果声明的编码和实际字节不匹配（比如文件存为 GBK 却声明 UTF-8），Tokenizer 就会把一个中文字符切成两个非法字节序列，导致：
- 文本 Token 出现乱码（如 “张三” 变成 “三”）
- 起始标签 Token 错位（
<div> 被截断成 <code><di> + <code>v>） - 注释或 script 标签提前闭合，意外暴露未转义内容
- 后端返回已转义的字符串，前端又用
el.innerHTML = `<div>${data.content}</div>` - 模板引擎（如 Jinja）默认转义，但传入的
data.content已是双重转义结果（如<script>） - 用户输入含 UTF-8 BOM 或零宽空格（
），Tokenizer 识别为合法字符，但 JS 字符串比较时忽略它，导致白名单校验绕过
为什么 htmlspecialchars() 在 Tokenizer 阶段就可能失效？
服务端用 htmlspecialchars() 处理字符串，输出的是 HTML 实体（如 <script></script>）。但这只是字符串层面的替换——如果该字符串最终被拼进 JSON 后再由 JS 插入 innerHTML，Tokenizer 会把整个 <script></script> 当作普通文本 Token，而不是标签 Token，也就不会触发任何 HTML 解析行为。真正危险的是：
排查 Tokenizer 层面的特殊字符问题，该看什么？
不用翻源码，直接用浏览器 DevTools 的 Elements 面板观察 DOM 结构是否“看起来不对”：文本里出现异常符号、标签被截断、
