17370845950

file_get_contents() 不自动缓存，因其底层为HTTP流封装器，无内置缓存机制，忽略Cache-Control/ETag等响应头；需手动实现文件、cURL或Redis缓存。

直接用 file_get_contents() 远程访问 URL（比如 http://example.com/data.json）默认不走本地缓存，每次都是真实 HTTP 请求——这不是“缓存没生效”，而是它压根没设计缓存机制。

为什么 file_get_contents() 不会自动缓存？

它本质是 PHP 的流封装器（http:// wrapper）调用，底层走的是 fopen() + fread()，

没有内置缓存层。HTTP 响应头里的 Cache-Control 或 ETag 不会被自动识别或复用。

• 即使目标服务器返回了 Cache-Control: public, max-age=3600，file_get_contents() 也完全无视
• 重复调用同一 URL，就是重复发起 TCP 连接、发送请求、等待响应
• 没有连接复用（keep-alive 默认关闭）、无重定向自动跟随控制、无超时精细管理

绕过缓存限制的三种实操方案

不能靠改函数参数“打开缓存开关”，得自己加一层逻辑。按轻重和适用场景分：

• 简单时效性要求低的场景：用文件级本地缓存 + 时间戳判断
  — 把内容写入 /tmp/myapi_abc123.cache，读前检查 filemtime() 是否超时
• 需要 HTTP 协议级缓存语义（如 ETag / 304）：换用 cURL，手动处理请求头与响应状态
  — 设置 CURLOPT_HEADER 拿响应头，用 CURLOPT_HTTPHEADER 发送 If-None-Match
• 高频、多服务共享缓存：接入 Redis 或 APCu
  — 键名建议用 http_cache: + md5($url . $options)，避免特殊字符污染

file_get_contents() 加缓存的最小可行代码示例

以下是一个带 5 分钟 TTL 的文件缓存封装，不依赖外部扩展：

function cached_file_get_contents($url, $ttl = 300) {
    $cache_key = '/tmp/' . 'fgc_' . md5($url) . '.cache';
    if (file_exists($cache_key) && (time() - filemtime($cache_key) < $ttl)) {
        return file_get_contents($cache_key);
    }
    $content = file_get_contents($url);
    if ($content !== false) {
        file_put_contents($cache_key, $content);
    }
    return $content;
}
// 使用
$data = cached_file_get_contents('https://api.example.com/v1/status');

注意：file_put_contents() 要确保 /tmp 可写；高并发下可能有竞态（多个进程同时写），生产环境建议加 flock() 或切到 Redis。

容易被忽略的坑

很多人试了缓存还是慢，问题常出在这些地方：

• allow_url_fopen 关闭时，file_get_contents() 直接报错，不是缓存失效——先确认 ini_get('allow_url_fopen')
• 远程 URL 含动态参数（如 ?t=1712345678）会导致缓存键爆炸，要提前 parse_url() 并过滤掉时间戳类参数
• 没设超时，file_get_contents() 默认阻塞直到连接失败（可能长达数分钟），必须配合 stream_context_create() 设 timeout 和 ignore_errors
• HTTPS 请求在旧 PHP 版本（如 5.6）可能因 CA 证书路径不对而失败，错误信息是 SSL operation failed，不是缓存问题

缓存本身不难加，难的是判断什么时候该用、用哪种、以及怎么不让它变成新的单点故障或一致性黑洞。