<p>确认Tokenization卡在字节流接收处是网络问题：若Chrome DevTools中HTML响应只显示前几百字节即中断、curl显示Content-Length与实际响应体长度不符、performance指标中responseEnd - fetchStart > 500ms且domInteractive同步延迟，则表明CDN截断、代理超时等网络层导致HTML流不完整，解析器因字节不足无法产出首个StartTag Token。</p>
Tokenization卡在字节流接收处，怎么确认是网络问题？
不是JS卡住，也不是DOM操作慢，而是HTML解析器根本没收到足够字节来产出第一个StartTag Token——此时document.readyState会死在"loading"，且performance.getEntriesByType("navigation")[0].responseEnd - fetchStart > 500ms，同时domInteractive延迟同步放大。
实操建议：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 打开Chrome DevTools → Network → 找首屏HTML请求 → 点击Response → View Source，看是否只显示前几百字节就断了（常见于CDN截断、代理超时）
- 用
curl -v http://your-site.com观察Content-Length和实际响应体长度是否一致 - 禁用所有浏览器扩展，排除中间件注入脚本导致流中断
为什么<script>和<textarea>会让Tokenizer反复回溯？</script>
Tokenizer不靠标签闭合符号“猜”结束位置，而是靠状态机严格匹配。遇到<script></script>或<textarea></textarea>，它必须扫描到对应或才能退出当前状态——如果内容里含未转义的字符串（比如JSON里写{"html":""}），状态机会误判闭合点，触发回溯重试，性能陡降。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- JSON数据块统一用
<script type="application/json"></script>包裹，并确保JSON.stringify()输出已转义双引号和 - 避免在
<script></script>内联代码中拼接HTML字符串，改用textContent或innerHTML动态赋值 - 检查HTML压缩配置，禁用
removeOptionalTags: true——删掉或起始标签会让Tokenizer降级为容错模式
DOM深度不影响Tokenization耗时，那什么才真正拖慢解析？
Tokenization只做字节→Token映射，不管嵌套；Tree Construction阶段才按Token建树。所以100层<div>和100个平铺<code><div>的Tokenizer耗时几乎一样，但后者在Tree Construction阶段快得多——节点插入路径短、样式计算层级少、布局重排成本低。<p>实操建议：</p>
<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>
<ul>
<li>用<code>document.compatMode === "CSS1Compat"确认是否启用标准模式，怪异模式会激活兼容性补丁，额外消耗CPU周期
document.write()或同步XHR打断字符流，它们会强制Tokenizer清空当前Token队列并重启<link rel="stylesheet">放顶部不会阻塞Tokenization，但<script src></script>没加async或defer就会停住整个流程自闭合标签真的不影响性能吗？
是的。<meta>、<link>、<img alt="网页DOM树构建：HTML文档结构Token序列化过程研究" >这类标签有专用快速解析路径，Tokenizer对它们的处理开销恒定。真正危险的是那些「结束位置不确定」的标签：比如<script></script>要等匹配闭合，<textarea></textarea>要扫描到下一个，而嵌套的<script type="application/json"></script>若含未转义，Tokenizer会反复回溯。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要迷信HTML压缩工具的“极致精简”，删掉
或起始标签反而让Tokenizer更慢 - 用
performance.getEntriesByType("navigation")[0].domComplete - domInteractive衡量Tree Construction阶段耗时，这才是DOM深度真正起作用的地方 - 如果页面首屏DOM构建慢，先查
responseEnd和domInteractive差值，再查domInteractive和domComplete差值——前者指向Tokenization瓶颈，后者指向Tree Construction瓶颈
真正容易被忽略的是：Tokenization卡住时，DevTools里Network面板看起来“请求已完成”，但Elements面板空空如也，控制台也无报错——它既不是JS错误，也不是CSS加载问题，而是底层字节流还没喂够。
