定位“package not found”需先确认包名是否正确、是否存在、大小写是否匹配，并检查minimum-stability配置；再验证PHP版本兼容性、依赖关系及autoload映射是否生效。
composer install 报错 “package not found” 怎么定位真实原因
不是所有 composer install 失败都因为包名写错了。更常见的是：包在 Packagist 上根本不存在、拼写大小写不一致、或用了非稳定版本但没配 "minimum-stability"。
- 先用
composer search <em>spider</em>或直接去 packagist.org 搜关键词，确认包名是否为guzzlehttp/guzzle（HTTP 客户端）或symfony/dom-crawler（HTML 解析），而不是臆想的php-spider或web-crawler - 如果搜到的是
spatie/crawler，注意它依赖 PHP 8.0+ 和guzzlehttp/guzzle:^7.5，PHP 7.4 下装会静默失败，错误里可能只显示your requirements could not be resolved - 别直接
composer require spatie/crawler就跑，先看它的composer.json里"require"字段——很多爬虫库把 Guzzle 当可选依赖，但实际发请求时缺它就抛Class "GuzzleHttpClient" not found
用 guzzle + dom-crawler 写最简网页抓取，为什么 file_get_contents 不行
不是不能用 file_get_contents，而是它默认没 User-Agent、不支持自动重定向、无法设超时、不能带 Cookie，目标网站一加反爬（比如返回 403 或空白页），你就卡住。
-
guzzlehttp/guzzle提供统一的异步/同步接口，$client->get($url)返回ResponseInterface，状态码、头、body 分离清晰 -
symfony/dom-crawler不是独立 HTTP 库，它只处理 HTML 字符串，必须配合 Guzzle 或其他方式拿到 HTML 后再喂给它：new Crawler($response->getBody()->getContents()) - 别漏掉
curl扩展和mbstring——DomCrawler 依赖后者解析 UTF-8，没启用会报Call to undefined function mb_convert_encoding()
spatie/crawler 跑不起来：配置里最容易漏的三项
这个库封装了队列、并发、延迟，但开箱即用的前提是你主动关掉“安全限制”，否则它连自己本地的测试页都爬不了。
- 必须调用
setCrawlProfile(new NoFollowCrawlProfile())，否则默认只爬同域名下链接，https://example.com/a里的https://google.com直接被过滤 - 默认
setMaximumDepth(1)，意思是只抓首页，子页面全跳过；要深度遍历得显式设成3或null - 没配
setDelayBetweenRequests(1000)的话，它会瞬间发几十个请求，轻则被封 IP，重则触发目标站的 429 响应，而库默认不重试也不报错
为什么 vendor/autoload.php require 后还是 Class not found
不是自动加载失效，大概率是命名空间没对上，或者类文件压根没进 autoload 配置。
- 检查
vendor/composer/autoload_psr4.php里有没有对应包的映射，比如"Spatie\Crawler\" => ["src/"]；没有说明 composer 没成功写入 autoload 规则 - 运行
composer dump-autoload -o强制重生成优化版 autoload，尤其在手动改过composer.json的"autoload"字段后 - 如果用的是自定义命名空间（比如自己写的爬虫工具类），确保
"autoload": {"psr-4": {"MyCrawler\": "src/"}}已加，并且src/下有MyCrawler/Crawler.php文件，类声明是class Crawler而不是class MyCrawler
真正麻烦的从来不是装上哪个包，而是每个库对 HTTP 状态、重定向、编码、JS 渲染的默认处理逻辑都不一样。抓动态页面前，先确认你用的库到底发没发请求、收没收到真实 HTML、解没解对 charset——别让 var_dump 输出一堆 就以为是代码问题。
