Guzzle 返回空内容或403主因是目标站反爬，需设浏览器User-Agent、allow_redirects=true；DomCrawler解析前应打印html()确认内容存在，filter后须count()判断再text()，属性提取前用hasAttribute()，并发用Pool配concurrency和http_errors=false。
用 Guzzle 发起请求时，为什么返回空内容或 403？
多数情况不是代码写错了，而是目标网站做了基础反爬：比如检查 User-Agent、拒绝非浏览器请求、或重定向到登录页。Guzzle 默认的 User-Agent 是 GuzzleHttp/7 这类标识，极易被拦截。
- 必须手动设置模拟浏览器的
User-Agent，例如：['User-Agent' => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'] - 加上
allow_redirects => true（默认开启，但显式声明更稳妥），否则遇到 302 会直接返回跳转响应体而非最终页面 - 如果目标站有 Cloudflare 或 JS 渲染逻辑，Guzzle + DomCrawler 无法执行 JS，此时抓不到真实内容——这不是配置问题，是技术边界
- 部分站点还校验
Accept、Accept-Language，补全这两个 header 能显著提升成功率
DomCrawler 解析 HTML 时，select() 返回空数组怎么办？
常见错觉是“选择器写错了”，其实更可能是 HTML 结构和你看到的不一致：比如服务端渲染和浏览器渲染不同、HTML 被注释包裹、或节点在 <script></script> 中动态插入。
- 先用
$crawler->html()打印原始 HTML，确认目标内容是否真的存在；不要依赖浏览器开发者工具里“Elements”面板的实时 DOM - DomCrawler 默认只解析顶层文档，若目标在 iframe 或异步加载的 fragment 里，它压根看不到
- CSS 选择器不支持伪类（如
:nth-child）和部分属性匹配（如[class*="price"]需用 XPath 替代） - 推荐优先用 XPath：更稳定，且可跨层级定位，例如
$crawler->filterXPath('//div[contains(@class, "item")]/span[1]')
如何安全提取文本，避免 Notice: Trying to get property 'text' of non-object？
DomCrawler 的 filter() 不保证一定有匹配节点，直接链式调用 ->text() 会崩。PHP 8+ 的 nullsafe 操作符（?->）能缓解，但不如主动判断清晰。
- 永远对
filter()结果做数量检查：if ($crawler->filter('.price')->count()) { ... } - 提取文本前加 trim：
trim($node->text())，防止空格、换行、零宽字符干扰后续处理 - 需要取属性值时，用
$node->attr('href')，但要先hasAttribute('href')判断，否则报 Warning - 批量提取时别用 foreach($crawler->filter(...) as $node)，应改用
each()方法，它自动跳过空节点
并发请求怎么写？Guzzle 的 Promise 和 Pool 容易踩哪些坑？
单请求写法简单，但批量抓取时不用并发就是自我惩罚。Guzzle 提供了 Pool，但它对异常处理很“刚”：一个请求失败，默认整个池子中断。
立即学习“PHP免费学习笔记（深入）”；
- 必须传入
concurrency参数控制并发数（如5），否则可能触发目标站限流或本地 socket 耗尽 - 错误不能靠 try/catch 包裹 Pool，而要用
http_errors => false+ 后续检查$response->getStatusCode() - 每个请求的 options（如 headers、timeout）必须独立构造，复用同一数组会导致意外覆盖
- 别在循环里反复 new Client()，复用一个
GuzzleHttp\Client实例，否则 DNS 缓存、连接池都失效
真正麻烦的从来不是语法，而是每次换一个网站就得重新猜它的反爬套路、HTML 嵌套逻辑、以及哪段数据藏在 JSON 里又没暴露 API。DomCrawler 只负责“解析静态 HTML”这件事，超出这个范围，就得换工具或者加中间层。
