cURL 和 File- 函数使用起来不安全

与许多其他 PHP 函数一样，处理错误时应格外小心。
这是许多 PHP 开发人员不太擅长的事情；而我们这些确实处理错误的人仍然偶尔会忽略一些事情。
简单地执行以下操作是不安全的：

$content = file_get_contents('https://onitroad.com/api/user-agent');

因为如果请求没有完成怎么办？
好吧，我们可以检查 file_get_contents 是否失败：

if (false === ($content = file_get_contents('https://onitroad.com/api/user-agent'))) {
   throw new Exception("Unable to Download web page.");
}

这是一种改进，但仍不足以保证数据完整性。
现在我们还需要验证服务器响应代码，如果可能的话，在我们使用它之前，响应正文的格式是否正确。
这不是库 会帮我们做的事情，所以我们应该做功课！

依赖我们自己控制之外的 API 服务器是一个潜在的错误等待发生，因为即使请求本身成功，我们仍然不能相信响应的格式是正确的。

另一个例子是当只使用文件函数访问本地文件系统时，这也是不安全的。
我在这里讨论了一些与文件系统访问相关的问题：PHP 的文件函数有多安全？
在执行 HTTP 请求时，我们还应该非常小心并验证请求是否成功，以及潜在的响应正文格式是否正确。

我注意到在从 PHP 脚本执行 HTTP 请求时是否应该使用 cURL 或者 file_get_contents 存在一些混淆。
事实是，我们使用什么并不重要。
根据我的经验，两者都具有同等能力。
他们的表现似乎也一样。
但这也是我不会考虑性能来决定的情况之一，因为服务器响应时间对性能的影响远大于请求的执行方式。

PHP 发送 HTTP 请求的方式其实有很多种，file_get_contents 和 cURL 只是其中的几种。
也可以将 fopen 与 stream_get_contents 结合使用。
我想我们可以将 file_get_contents 视为一种通用的简写，用于读取本地文件和执行 HTTP 请求。

然而，有这么多不同的方法来做同样的事情会让不熟悉 PHP 的人感到困惑，有时，奇怪的语法。
例如，文件函数也可以执行 HTTP 请求这一事实很奇怪且不直观——新用户可能只希望它们处理本地文件！

File_get_contents vs cURL vs Guzzle

我已经使用过许多这样的方法，并且还在 onitroad 上记录了它们的使用，而且我还没有真正偏爱一种特定的方法。
我知道还有一些库可以让事情变得更容易，比如 PHP 的 guzzle——如果我必须选择，那么我可能会使用这些库中的一个，因为如果 cURL 或者文件函数不可用，它也可能工作，并且它们提供了原本不属于普通 PHP 的另外功能。

大多数情况下，我只是尝试坚持使用内置的 PHP 功能。
当涉及到简单的 HTTP 请求时，我并没有真正需要在我的代码中引入外部依赖项。
但是，如果我们使用框架，那么我们可能希望坚持使用框架提供的任何内置机制。

使用 Guzzle 的一个好处是它允许我们执行异步和并发请求，这对于普通的 PHP 来说是非常困难的（尽管将来可能会改变）。