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>(.*?)/i</title> 这类“贪心+无边界”的表达式。它在遇到换行、注释、嵌套标签（如 <script>document.write('<title>...')</script>）时极易误匹配或漏匹配。
更稳妥的做法是：
- 加上
s修饰符让.匹配换行符：/<title>(.*?)/is</title> - 用非贪婪 + 明确字符集替代
.*?，例如提取 href：/href=["\']([^"\'>\s]+)["\']/i - 避免匹配跨多行的复杂结构（如整个
<table>），正则不是 HTML 解析器 <h3>为什么不用 DOMDocument 而坚持用正则</h3> <p>不是不能用，而是场景不同。如果你只是从格式稳定、结构扁平的页面中提取几个固定字段（比如某天气页的温度数字、某 RSS 源的 <code><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 生成的内容），这类页面源码里根本没你想要的数据，再调什么上下文、修饰符都没用。
- 用
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
