Webman 本身不是
爬虫
框架，它只是个高性能 PHP 网络应用框架；所谓“Webman 驱动的高性能爬虫系统”，实际是指基于 Webman 构建调度/服务层，再搭配专用爬虫引擎（如
）或 HTTP 客户端（如
）来实现数据采集。直接用 Webman 的
或
去发请求、解析 HTML，性能和稳定性都会很快见顶。
为什么不能直接在 Webman 的 HTTP 路由里写爬虫逻辑
常见错误现象：
超时、内存溢出、页面卡死、并发一高就 502。这是因为 Webman 的 HTTP 请求生命周期默认是同步阻塞的，每个请求独占一个进程/线程，而爬虫本质是 IO 密集型任务，需要异步、复用连接、可控超时、自动重试——这些 Webman 原生不提供。
使用场景：适合做爬虫任务的 Web 控制台、状态看板、API 触发入口，而不是执行爬取动作本身。
路由中只负责接收任务参数（如 URL、抓取深度、回调地址），写入队列（如 Redis）
真实爬取由独立的
进程或
的 Producer/Consumer 模型完成
避免在
回调里调用
这类同步阻塞操作
PHPCreeper 是当前最匹配 Webman 的爬虫引擎
（爬山虎）不是插件，而是基于
内核重构的完整爬虫运行时，与 Webman 共享底层事件循环和多进程模型，因此能真正发挥“高性能”价值。
关键配置差异：
php爬虫采集类-phpQuery：支持抓取网站,非常强大的php类库
下载
设为
可避免重复下载，但需确保
有写权限且路径非临时目录（否则重启丢失）
动态页面必须启用
，但会显著增加内存占用，建议单个 Worker 进程只跑 1–2 个无头实例
分布式部署时，
作为任务队列和去重存储，
的
命令要禁用，改用
+
控制优先级
示例片段（
）：
用 GuzzleHttp + Webman 做轻量采集时的避坑点
适合单页抓取、API 数据拉取等简单场景，但极易踩坑：
实例必须复用，不能每次请求都 new 一个——否则 DNS 缓存失效、TCP 连接无法复用，QPS 直接腰斩
务必设置
，否则 4xx/5xx 会抛
中断流程
HTML 解析别用
直接加载远程响应体，先用
处理编码，否则中文乱码或解析失败
并发控制靠
，但
的最大协程数别设超过 20，PHP 的 curl 扩展对高并发支持有限
海量数据下的关键瓶颈不在“怎么发请求”，而在“怎么存”和“怎么去重”
当目标站点 URL 数量超 100 万，或单日采集量超 50GB 时，以下两点比选什么框架更重要：
URL 去重必须用布隆过滤器（
）+ Redis
组合，纯 MySQL
插入会成为 I/O 瓶颈
原始 HTML 存储建议用对象存储（如 MinIO），而非数据库 blob 字段——数据库只存元信息（URL、状态、指纹 hash、抓取时间）
的
方法若含复杂 XPath 查询，务必加缓存层（如 APCu），否则 DOM 构建开销远超网络耗时
真正的海量采集，从来不是“写个脚本能跑就行”，而是调度粒度、失败重试策略、指纹生成一致性、存储分片规则这些细节决定成败。别迷信“高性能框架”，先想清楚你的 URL 规模、页面平均大小、更新频率和容忍丢率——这些才是压倒一切的设计前提。
PHPCreeperGuzzleHttpWorkerHttpServermax_execution_timeWorkerPHPCreeperonRequest$client->request()PHPCreeperWorkermancache_enabledtruecache_directoryheadless_browserredisredisSCANzsetscoreapp/spider/TinywanProducer.phppublic function makeTask()
{
return [
'url' => 'https://example.com/list?page=1',
'context' => ['depth' => 1, 'max_depth' => 3],
'options' => ['timeout' => 8, 'connect_timeout' => 5]
];
}
GuzzleHttp\Clienthttp_errors => falseGuzzleExceptionDOMDocument::loadHTML()mb_convert_encoding()PoolPool::send()BloomFilterPFADDUNIQUE KEYPHPCreeperparseHtml()