DomCrawler的extractText()返回空或乱码，因其仅扁平拼接所有文本节点，不跳过script/style、不处理语义与换行；需先用html()确认原始HTML含目标内容，再filter定位正文区域，对JS渲染内容则需改用Puppeteer等方案。
为什么 DomCrawler 对某些页面 extractText() 返回空或乱码？
不是 DOM 解析失败，而是 extractText() 本身只做“扁平化拼接”，不理解语义、不跳过 script/style、不处理换行缩进——它把所有文本节点原样缝起来，包括隐藏的、注释里的、JS 注入前的占位符。
常见现象：抓到一堆空白符、重复标题、页脚版权、甚至内联 JS 变量值。这不是 bug，是设计如此。
- 先用
$crawler->html()确认原始 HTML 确实含目标正文（别信 Elements 面板） - 若正文被包裹在
<div class="content">里，优先$crawler->filter('.content')->extractText()，而非全文调用 - 遇到富文本编辑器生成的 HTML（如 CKEditor、TinyMCE），
<br>和<p>混用、空标签泛滥，extractText()会把换行压成一团；此时改用textContent+ 自定义清理更可控
用 XPath 定位正文区域比 CSS 选择器更稳
CSS 选择器在不规范 HTML 下极易失效：class 名动态生成、嵌套层级错乱、属性值含空格或特殊字符（如 class="article-content js-loaded"），.article-content 就匹配不到。
XPath 的 contains() 和 normalize-space() 天然适配这类场景：
立即学习“前端免费学习笔记（深入）”；
$crawler->filterXPath('//main//article | //div[contains(@class, "post-body") or contains(@id, "content")]')->extractText();
- 用
|合并多个可能结构，避免单点失效 -
normalize-space()在 XPath 表达式里写不了，但可在 PHP 层对结果调用trim(preg_replace('/\s+/', ' ', $text)) - 别依赖
:nth-of-type(1)这类伪类——DomCrawler 不支持，必须转成 XPath：[1]
如何安全跳过广告、侧栏、导航栏等干扰块？
不规范 HTML 常把广告代码直接塞进正文容器里，靠 class 名过滤容易误杀。更可靠的做法是：按视觉权重剔除低信息密度区块。
- 统计每个
<div>子节点的文本长度，剔除textLength < 20 && childCount > 5的“高噪低文”节点（典型广告位） - 用
$crawler->filter('script, style, nav, header, footer, aside')先移除明确无关节点：$crawler->reduce(function ($node) { return !$node->matches('script, style'); }) - 若目标正文集中在某段连续
<p>中，用$crawler->filter('p')->each(function ($p) { return strlen($p->text()) > 50 ? $p->text() : null; })过滤短段落
DOM 加载后仍取不到内容？检查是否是 JS 渲染注入
DomCrawler 解析的是服务端返回的原始 HTML，不是浏览器最终渲染结果。如果正文由 JS 动态插入（如 React/Vue SSR 后 hydrate、或 AJAX load），$crawler->html() 里根本不存在那段文字。
- 打开 Chrome DevTools → Network → 刷新页面 → 找 XHR/Fetch 请求，看是否有独立接口返回正文 JSON 或 HTML 片段
- 若存在，直接用 Guzzle 请求那个接口，再用 DomCrawler 解析返回体，绕过前端 JS
- 若无独立接口，且必须执行 JS，DomCrawler 无法胜任——此时该换 Puppeteer 或 Playwright，PHP 生态没轻量级替代方案
真正麻烦的从来不是怎么写 selector，而是得花时间确认：这段文字，到底是在哪一层吐出来的。
