PHP 调试实战：filesize 缓存、编码匹配与 CURL 地址差异三大坑

前言

PHP 开发中看似简单的操作往往藏着深坑。本文记录作者在调试采集脚本时遇到的三个经典问题，剖析根因并给出解决方案，助你避开新手常犯的低级错误。

问题一：filesize() 返回错误值

现象

用 cURL 下载页面保存为临时文件 tmpHtml.txt，调用 filesize('./tmpHtml.txt') 获取大小供 fread() 读取，但返回值与实际文件大小不符。

根因

PHP 会缓存文件状态函数（filesize、filemtime 等）的返回结果以提升性能。同一脚本多次检查同一文件且文件在脚本执行期间被修改时，缓存导致读取到旧数据。

解决

clearstatcache(); // 清除文件状态缓存
$size = filesize('./tmpHtml.txt');

或在 PHP 5.3+ 使用 clearstatcache(true, $filename) 针对特定文件清理。

问题二：UTF-8 脚本匹配 GBK 中文内容失败

现象

需在 GBK 编码的页面内容中匹配“苹果”二字。先将正则转为 GBK 再匹配原内容失败；后改为先将内容 iconv('GB2312', 'UTF-8', $contents) 转编码再用 UTF-8 正则匹配成功。

真相

“第二种方法成功”是因为此时已修复问题一（文件大小正确，内容完整读取）。第一种方法失败实为读取内容不全导致，非编码转换逻辑问题。教训：排查问题要从数据源头验证，别被表象误导。

问题三：浏览器“审查元素”获取的图片地址与 CURL 抓取的不同

现象

目标图片下载链接含 aid 参数，形如 attachment.php?aid=Mzk3MTB8YTg5ZTYyNTJ8MTMyNjcyNDEwMXw5NWYydC9aOUE0a05EVm9ydlErSFBRamZJNWJQL1NHdWJLK3ZraU9GTDZYdnBUdw%3D%3D。浏览器中可直接下载，CURL 请求却失败。

根因

aid 很可能是与 Session 绑定的加密 token，具有时效性和上下文关联性。浏览器自动携带 Cookie/Referer 等上下文，CURL 默认不发送。

解决

• 分析页面生成逻辑，寻找静态可预测的下载路径（如直接文件链接）。
• 若必须用动态链接，需完整模拟浏览器环境：Cookie Jar、User-Agent、Referer、Header 等。

总结反思

1. 缓存陷阱：文件系统函数需配合 clearstatcache() 使用。
2. 编码迷思：匹配前确保“字符串内容完整、编码一致”，优先统一转为 UTF-8 再处理。
3. 上下文缺失：CURL 非浏览器，需手动补全请求上下文；优先寻找无状态的静态资源链接。

“以上三个故事包含两个悲剧，这就是 PHP 初学者必犯的低级错误。” —— 保持敬畏，多查手册，多打日志，少猜疑。