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 的文件缓存封装，不依赖外部扩展：
立即学习“PHP免费学习笔记（深入）”；
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，不是缓存问题
缓存本身不难加，难的是判断什么时候该用、用哪种、以及怎么不让它变成新的单点故障或一致性黑洞。
