file_get_contents 能抓取网页内容，但需目标网站允许且 PHP 启用 allow_url_fopen；若被禁用则必须改用 cURL；正则提取 HTML 时应加 s 修饰符、避免贪心匹配，优先用于结构简单场景，动态渲染页面需换方案。
file_get_contents 能否直接抓取网页内容
能，但有前提：目标网站允许被访问，且 PHP 配置启用了 allow_url_fopen（默认开启，但部分共享主机已禁用）。如果返回空或警告 Warning: file_get_contents(): failed to open stream: no suitable wrapper，说明已被禁用，此时必须改用 cURL —— file_get_contents 在这种情况下完全不可用。
实际使用时建议先检测：
if (!ini_get('allow_url_fopen')) {
die('file_get_contents 无法用于远程 URL');
}
正则匹配 HTML 标签的常见翻车点
用 preg_match 提取标题、链接等字段时，最常犯的错误是写 /<title>(.*?)<\/title>/i 这类“贪心+无边界”的表达式。它在遇到换行、注释、嵌套标签（如 <script>document.write('<title>...')）时极易误匹配或漏匹配。
更稳妥的做法是：
立即学习“PHP免费学习笔记（深入）”；
- 加上
s修饰符让.匹配换行符：/<title>(.*?)<\/title>/is - 用非贪婪 + 明确字符集替代
.*?，例如提取 href：/href=["\']([^"\'>\s]+)["\']/i - 避免匹配跨多行的复杂结构（如整个
<table>），正则不是 HTML 解析器
为什么不用 DOMDocument 而坚持用正则
不是不能用，而是场景不同。如果你只是从格式稳定、结构扁平的页面中提取几个固定字段（比如某天气页的温度数字、某 RSS 源的 <link> 值），file_get_contents + preg_match 组合启动快、依赖少、代码短。而 DOMDocument 需要加载完整文档树，对 malformed HTML 容错虽好，但开销大，且容易因编码问题（如页面声明 gb2312 但内容是 utf-8）导致解析失败或乱码。
若真要用正则提链接，注意两点：
- 用
mb_convert_encoding统一转为 UTF-8 再匹配，否则中文 URL 可能截断 - 匹配后对结果调用
urldecode和filter_var($url, FILTER_VALIDATE_URL)做基础校验
简单爬虫必须加的防护措施
哪怕只是本地调试，不加限制的 file_get_contents 请求也容易触发目标站的反爬机制或造成自身 IP 被封。最小可行防护包括：
- 设置请求头模拟浏览器：
stream_context_create(['http' => ['header' => "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36\n"]]) - 加延迟：
sleep(1)，别连续请求 - 限定最大响应体大小，防止下载整站：
'max_redirects' => 3, 'timeout' => 10, 'ignore_errors' => true - 始终检查返回值是否为
false，而非只看长度——网络中断时可能返回空字符串，但不是错误
真正要注意的是：正则永远无法可靠处理动态渲染页面（如 React/Vue 生成的内容），这类页面源码里根本没你想要的数据，再调什么上下文、修饰符都没用。
