简介这是一份微信公众号文章采集的PHP实现程序面向需要批量抓取公众号文章数据的技术人员或运营人员用于解决手工逐篇保存效率低的问题。程序围绕文章内容、发表时间、公众号ID、头像、封面、标题、公众号名称、BizID、摘要等核心字段进行采集覆盖了公众号文章页面的主要结构化信息。压缩包内共1个文件为单个PHP脚本资源整体仅1KB代码集中便于阅读和二次修改适合有一定PHP基础、希望快速上手采集逻辑的开发者。目前已有1170人学习下载参考价值得到初步验证。通过阅读该脚本可以了解PHP实现HTTP请求、内容解析及关键字段提取的实现思路也可根据自身需求调整采集规则是学习公众号数据采集的轻量示例。 做PHP开发这些年我陆陆续续接过好几个和“微信公众号文章采集”相关的需求。有的是想把自己公众号的历史文章备份到本地有的是要给客户官网做内容聚合展示还有的是要把分散在多个公众号里的行业资料统一归档方便团队内部查阅。听上去都是“把微信文章抓下来”这一件事可真正动手做的时候你会发现里面的门道比想象中多得多——链接结构怎么拆、正文怎么解析、图片怎么处理防盗链、接口访问限制怎么规避每一项都够你踩上几个坑的。这篇文章就围绕一套我用PHP编写的微信公众号文章采集程序来聊聊。内容偏向实战我会把实现思路、核心代码、踩过的坑以及二次开发时要注意的细节都摊开讲清楚。如果你有PHP基础想自己搞一套能跑起来的采集程序那这篇文章应该能帮你省下不少摸索时间。1. 先理清需求再动手写代码1.1 采集任务的核心拆解很多人一上来就写采集脚本结果写到一半发现需求根本没想清楚。我习惯先把任务拆成三个层面文章入口、正文解析、资源本地化。文章入口是指从哪里拿到文章的链接。常见的来源有三个手动粘贴单个链接、从公众号历史消息页批量抓取、通过微信官方接口拉取素材列表。前两种不需要特殊权限适合个人小批量采集第三种需要公众号后台有对应接口权限适合企业级自研系统。正文解析是指从HTML页面里提取出标题、作者、发布时间、正文内容、原文链接这些字段。这个环节最麻烦因为微信文章的HTML结构在不同时期、不同系统下会有差异解析规则要写得足够健壮否则页面一改版你的程序就废了。资源本地化是指把文章里的图片、视频、附件下载到自己的服务器然后把正文里的引用地址替换成本地地址。这步不做的话文章发到你自己的站点上图片会裂掉因为微信图床有防盗链机制外部域名直接引用的图片大概率加载不出来。1.2 为什么用PHP而不是Python说到写采集程序很多人第一反应是PythonScrapy也好、Requests加BeautifulSoup也罢生态确实成熟。但我最终选PHP原因其实很实在这套程序要嵌进一个基于ThinkPHP 3.2.3的老项目里团队里其他人也以PHP为主如果单独引一套Python服务进来部署、维护、交接都是额外负担。ThinkPHP 3.2.3这个版本虽然老但胜在稳定、简单做定时采集任务完全够用。如果你是自己新写项目可以用ThinkPHP 6或者Laravel思路是一样的。要是就写个单文件脚本那连框架都不用上PHP自带的cURL、DOMDocument就足够了。我在这个项目里的技术选型总结下来就一句话能用现成PHP能力解决的事不引入额外组件必须引入第三方库时也只挑最成熟、维护最活跃的。2. 文章链接解析与正文提取实战2.1 微信文章链接的结构微信文章的URL长这样https://mp.weixin.qq.com/s?__bizMzA3NDIyNzc4Mgmid2650734567idx3sn7f3e6c8f1d7c5a9d2e0b6a4c8e1d2f3a四个核心参数分别是__biz公众号的唯一标识相当于微信号在微信服务器里的身份证mid这条消息在公众号消息列表里的序号idx文章在当天推送里的位置1表示头条sn内容签名用于校验链接合法性防止被篡改解析链接时我用PHP自带的parse_str函数把参数拆出来然后用__biz、mid、idx三个字段拼一个唯一索引用来做去重判断。为什么要加上idx因为同一个mid下可能有多篇文章只有mid加idx才能唯一锁定一篇文章。$query []; parse_str(parse_url($url, PHP_URL_QUERY), $query); $biz $query[__biz] ?? ; $mid $query[mid] ?? ; $idx $query[idx] ?? 1; $uniqueKey md5($biz . _ . $mid . _ . $idx);注意sn这个参数我一般不会拿来做键因为同一篇文章在不同入口分享时sn可能不同用它做去重会产生重复数据。2.2 正文HTML解析的两种方案解析正文我实验过两种方案正则表达式和DOMDocument。正则写起来快但对付微信这种结构复杂、标签嵌套深的HTML很容易翻车。比如正文里会有一些带转义字符的代码块、SVG图标、自定义标签正则一不留神就误伤还会出现贪婪匹配把整个页面吞掉的问题。我最终用的是DOMDocument加XPath的方案。先加载HTML然后定位到id为js_content的div节点这个节点就是正经的文章正文区域页面头部、底部、推荐阅读这些信息都排除在外。$dom new DOMDocument(); libxml_use_internal_errors(true); $dom-loadHTML(mb_convert_encoding($html, HTML-ENTITIES, UTF-8)); libxml_clear_errors(); $xpath new DOMXPath($dom); $contentNode $xpath-query(//*[idjs_content])-item(0);这里有个关键细节loadHTML之前必须先做编码转换。微信页面声明的是UTF-8但PHP的DOMDocument默认按ISO-8859-1解析不转码的话中文大概率变成乱码。用mb_convert_encoding统一转成HTML实体再加载是目前最稳妥的做法。标题、作者、发布时间这些字段我用的是meta标签加XPath双保险。优先读meta里的og:title、og:article:author取不到再回退到页面里的h1标签这样即使页面改版也能扛住一阵子。$title $xpath-query(//meta[propertyog:title]/content)-item(0)-nodeValue ?? $xpath-query(//h1[idactivity-name])-textContent; $author $xpath-query(//meta[propertyog:article:author]/content)-item(0)-nodeValue ?? ; $publishTime $xpath-query(//*[idpublish_time])-item(0)-textContent ?? ;2.3 微信正文里的JS动态渲染问题还有一个容易踩的坑部分微信文章正文里的内容是通过JavaScript动态渲染出来的直接抓HTML拿不到完整内容。遇到这种情况要么用无头浏览器渲染后再抓取要么观察接口返回的JSON里是否已经包含了完整的文章数据。我通常优先用后一种在页面源码里搜一下data-content或者window.__msg_info这样的全局变量里面一般藏着完整的数据解析出来反而更干净。只有极少数情况下才会引入无头浏览器毕竟那玩意儿吃内存、跑得慢小项目里尽量不碰。提示抓下来的正文HTML一定要做基础清洗比如移除script、style标签过滤掉空段落和多余的class属性不然存到数据库里占空间输出到页面上还会样式错乱。3. 图片与附件资源本地化3.1 为什么必须做图片本地化文章正文里通常有大量图片这些图片的域名大多指向mmbiz.qpic.cn。微信对图片域名做了防盗链限制别人网站直接引用的请求会被拒绝返回一个默认的防盗链提示图。所以文章采集下来之后图片必须下载到你自己的服务器上再把正文里的引用地址替换成本地路径。另外还有个非常现实的原因长期来看微信可能会清理历史图片资源特别是某些被投诉或长期不活跃的公众号。如果你把别人文章的图片直接留在原文链接上一两年前的文章配图大概率会裂。做本地化本质上是在做数据资产保全。3.2 图片下载与替换的PHP实现图片下载我用cURL因为比起file_get_contentscURL能更好地控制请求头、超时时间也方便处理SSL证书校验。最关键的是微信图片服务器对请求头里的Referer敏感必须加上Referer为https://mp.weixin.qq.com的请求头否则很大概率下载失败或拿到错误图片。function downloadImage($url, $savePath) { $ch curl_init($url); $fp fopen($savePath, wb); curl_setopt($ch, CURLOPT_FILE, $fp); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_REFERER, https://mp.weixin.qq.com/); curl_setopt($ch, CURLOPT_USERAGENT, Mozilla/5.0 (Windows NT 10.0; Win64; x64)); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); curl_setopt($ch, CURLOPT_TIMEOUT, 30); curl_exec($ch); $status curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); fclose($fp); return $status 200; }下载完成后要做的就是把正文HTML里的图片链接替换成本地地址。需要注意微信图片有两种写法一种是直接写在src属性里另一种是懒加载场景下写在data-src属性里页面加载时再用JS把data-src赋给src。替换的时候两种属性都得处理否则文章在前端展示时图片一样起不来。3.3 存储目录规划图片存储目录我习惯按文章ID分目录每个文章一个文件夹结构是uploads/wechat/{article_id}/。这样后面要清理垃圾文件、做备份、按文章归档都方便。如果文章量特别大、单台服务器扛不住也可以把图片传到OSS或COS对象存储上再从正文里替换成对应的CDN地址思路完全一致。我在实际项目里还加了一个小功能下载图片之前先检查目标文件是否存在且大小大于1KB如果满足条件就跳过下载直接复用现有文件。这个逻辑在断点续采或重复采集时能省下大量时间和带宽。4. 接口访问限制与合规采集实践4.1 微信对采集的限制到底在哪一层很多新人以为采集微信文章跟爬普通网站一样只要速度控制好就没问题。实际上微信的限制是分层的要弄清楚每一层是什么才能对症下药。第一层是公众号后台接口层。微信开放平台对素材管理、用户管理、消息管理等接口有严格的调用频率限制比如接口每天的调用上限、每分钟的QPS限制。如果采集程序直接对接官方接口批量拉取文章超出限额就会被拒绝访问。第二层是网页访问层。虽然微信没有公开声明封禁IP的策略但从实际经验来看如果某个IP在短时间内对mp.weixin.qq.com发起大量请求会触发风控机制返回验证码或者直接断连。第三层是内容版权层。未经授权就把别人公众号的文章全文爬下来商用是违反微信平台规则和著作权法的。这一层不是技术能解决的必须在业务逻辑里主动规避。4.2 合规采集的几种可行方案针对上面的三层限制我总结了三种合规的采集路径。第一种采集自己公众号的文章。在公众号后台有接口权限的前提下可以通过官方接口拉取素材列表这是最合规、最最稳定的方式。缺点是你只能拿到自己账号下的文章适合做内容备份和数据分析。第二种通过用户主动分享获得的链接进行单篇采集。比如用户在你们的小程序或H5页面上粘贴了一篇微信文章的链接你抓取这篇文章的公开信息用于预览、存档。这种场景用户有明确的授权意图只要采集后不要二次传播、不篡改内容一般没问题。第三种针对明确授权的内容合作方进行批量采集。比如对方书面授权你把他公众号的文章同步到你的平台上这种场景下你按技术方案处理就好但建议在采集程序里保留来源链接、作者署名、发布时间等元信息展示端也建议标注出处。我在程序里专门加了一个白名单机制只有被授权的公众号链接才允许批量采集其他链接一律走单篇手动流程。这个设计不是为了麻烦而是为了避免业务在版权问题上翻车。4.3 采集节奏控制与重试机制即使走的是合规路径也不能完全不管访问频率。我在程序里用了一个很简单的策略相邻两次请求之间随机休眠2到5秒模拟人工阅读的节奏。不要小看这个随机休眠它能有效降低触发风控的概率。$sleepTime rand(2, 5); sleep($sleepTime);重试机制也很重要。第一次请求失败后先停10秒再重试一次第二次还失败就记录日志把这条链接标记为异常等下一轮任务再处理。连续重试三次都失败的链接自动进入人工复核队列。注意采集程序一定要做频率限制。不要仗着自己有代理池就疯狂并发抓取一是容易触发微信风控导致IP段被封二是给微信服务器造成不必要的压力这对谁都没好处。合规第一效率其次。5. 实战踩坑记录与优化心得5.1 高频问题排查清单在实际开发和使用这套采集程序的过程中我遇到过不少问题整理成一个速查表你以后遇到了可以直接对着排查。问题现象可能原因解决方法抓到的内容全是乱码DOMDocument加载前未做编码转换用mb_convert_encoding转成HTML实体后再解析图片下载后无法打开缺少Referer请求头或SSL证书校验失败加上微信域名的Referer关闭SSL验证采集几个链接后请求超时触发微信风控或网络超时增加随机休眠时间使用支持重试的cURL配置正文里只剩文字没有图片只替换了src没替换data-src或懒加载图片未处理同时处理两个属性并检查图片URL是否被反斜杠转义数据库里出现重复文章去重键设计不合理用__bizmididx生成唯一索引入库前先查重页面在手机上展示样式错乱正文CSS被过度清洗保留必要的内联样式只移除script、style、iframe等标签5.2 超时与内存问题的处理技巧采集程序跑起来后最常遇到的两个性能问题是超时和内存溢出。PHP默认的max_execution_time是30秒采集一批文章时大概率超时所以在入口脚本里要显式设置时间限制同时每次循环里也单独设置一次防止单个请求卡死整个任务。内存溢出主要发生在解析超大HTML或者一次性把整个页面读进内存的时候。我的习惯是先用file_get_contents或cURL把页面拿下来再及时释放变量每处理完一篇文章就unset一次给下一篇文章腾出内存。如果采集量特别大建议分批跑比如每批处理50篇处理完歇几秒再跑下一批。5.3 小程序端与Obsidian的扩展玩法采集程序跑起来之后积累的文章数据可以有很多衍生的玩法。我把采集到的文章数据存入MySQL然后在配套的微信小程序后台做了一个文章列表的展示页面用户可以在小程序里直接阅读采集过来的文章相当于一个私人的内容聚合阅读器。小程序后台通过API接口读取文章列表和详情接口层做了简单的权限校验和防止SQL注入处理。另外我最近在折腾Obsidian发现把微信文章转换成Markdown格式后可以直接导入Obsidian库做知识管理。思路是在采集程序里加一个导出模块把正文HTML转成Markdown图片链接替换成相对路径再配合Obsidian的附件目录规范就能把公众号文章变成自己笔记库的一部分。这个对整个知识管理流程很有价值算是采集程序的一个延伸应用。5.4 关于采集边界的一点个人体会最后聊几句我自己做采集项目这些年攒下的体会。采集这件事技术本身是中性的但用的人要有边界感。我见过有人把采集程序做成批量搬运工具把别人公众号的文章改成自己的名字发布出去这种操作迟早出事而且吃官司的案例已经不少了。我的处理原则是采集到的文章只用于内部存档、学习研究、数据分析或者在有明确授权的情况下做内容展示所有文章保留原始链接和作者信息不篡改内容展示端一律标注来源。程序代码里我也加了对应的注释提醒后来接手的人注意版权边界。采集程序做到能稳定运行、数据不丢、不惹麻烦就算成功了。至于功能多花哨那是锦上添花的事。以后要是遇到更大的采集需求可以考虑引入消息队列做异步处理或者把下载任务拆到多个进程里并行跑不过这些都是后话了。先把基础打好你的采集程序才能真正派上用场。本文还有配套的精品资源点击获取