PHP中处理超大HTML文件应使用FileInputStream分块读取（如8192字节），避免内存溢出；需手动提取meta编码、及时unset变量；前端可用ReadableStream流式解析，配合Worker解码与标签栈管理；htmlparser2.WritableStream适合轻量字段提取；结构规律强时宜预拆为JSON分块。
用 FileInputStream 分块读取大 HTML（PHP 场景）
PHP 中处理超大 HTML 文件（比如几十 MB），不能直接 file_get_contents()，否则内存爆满、脚本超时。html5-php 的 FileInputStream 类就是为此设计的：它不加载全文，而是按需拉取字节块。
关键点是控制每次读取大小，8KB（8192）是经验平衡值——太小导致 I/O 频繁，太大又吃内存：
use HTML5\Parser\FileInputStream;
$stream = new FileInputStream('huge-report.html');
while ($chunk = $stream->read(8192)) {
// 对 $chunk 做轻量解析，比如正则提取 title 或 meta charset
// 切忌在这里调用 DOMDocument::loadHTML($chunk) —— 它会尝试补全结构，出错率高
}- 不要在循环里反复新建
DOMDocument实例，容易泄漏；优先用字符串处理或流式 parser（如htmlparser2的WritableStream） -
FileInputStream不自动识别编码，若 HTML 含<meta charset="gbk">，得先读前 1024 字节手动提取，再传给解码器 - 读完一块后，显式
unset($chunk)，避免 PHP 引用计数延迟释放
用 Response.body.getReader() 流式解析（浏览器端）
服务端启用 Transfer-Encoding: chunked 后，前端可用 getReader() 边收边解，避免等完整响应才开始工作。这不是“快”，而是让解析时间与网络传输重叠。
常见错误是把每块 Uint8Array 直接转成字符串后塞进 innerHTML —— 这会触发重复 DOM 构建，卡顿明显：
立即学习“前端免费学习笔记（深入）”；
const reader = response.body.getReader();
while (true) {
const { done, value } = await reader.read();
if (done) break;
// 累积到 ~64KB 再交给 Worker，别每块都 decode
buffer.push(value);
if (buffer.length > 64 * 1024) {
worker.postMessage({ buffer: concatBuffers(buffer) });
buffer = [];
}
}- 主线程只做切分和转发，
TextDecoder.decode()必须放在 Worker 里，否则阻塞渲染 - 若 HTML 含未闭合标签（如
<div><p>...</div>），流式解析会断裂；需在 Worker 内维护一个简单标签栈，缓存未闭合节点状态 - 禁止在
onopentag回调中保存整个node对象引用，只取node.name和node.attribs.id这类原始值
用 htmlparser2.WritableStream 实现无 DOM 流式提取
比起构建完整 DOM 树，多数场景只需提取特定字段（如所有 <a href>、标题层级、图片尺寸）。htmlparser2 的 WritableStream 模式专为此优化：它不保留节点树，只触发回调。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
它对内存友好，但要求你主动管理解析状态，比如判断是否在 <main> 内部：
const parser = new htmlparser2.WritableStream({
onopentag(name, attribs) {
if (name === 'main') inMain = true;
if (inMain && name === 'img' && attribs.src) {
images.push(attribs.src);
}
},
onclosetag(name) {
if (name === 'main') inMain = false;
}
});
stream.pipe(parser);- 如果目标是提取文本内容，别用
ontext()回调直接拼接——空格、换行、CDATA 会混乱；应结合onopentag/onclosetag推断上下文 -
WritableStream不处理自闭合标签的嵌套逻辑（如<img><div>），遇到<div>就认为新块开始，这点要写进业务逻辑 - 若 HTML 含内联 script，其内容会被当作纯文本传入
ontext()，需额外正则过滤，否则可能误提 JS 变量名
什么时候该停掉流式，改用静态分块 + 缓存
流式不是银弹。当 HTML 具备强结构规律（比如日志列表、商品目录、文档章节），且后续要频繁随机访问某一块时，硬扛流式反而低效。
典型信号包括：
- 流式解析后，你总要
JSON.stringify()结果并存在localStorage供下次复用 - 同一份 HTML 被多个页面/组件反复解析，但内容更新频率低于每天一次
- Worker 解析耗时稳定超过 300ms/块，且无法进一步拆细逻辑
这时更适合预处理：用 Node.js 脚本一次性将 HTML 按 <section> 或 <h2> 拆成 JSON 数组，每个元素含 id、html、title 字段，存为 chunks.json。前端按需 fetch('/chunks.json') + find()，比流式快一个数量级。
真正难的不是“怎么分”，而是判断哪块该提前加载、哪块可懒加载、哪块必须同步渲染——这些边界往往藏在语义标签嵌套深度和用户滚动行为里，得靠真实数据反馈来调。
