您认为在PHP中使用@运算符来抑制错误/警告是否有效，而您可能正在处理该错误？
如果是这样，您将在什么情况下使用它？
欢迎使用代码示例。
编辑：答复者注意。我不想关闭错误报告功能，但是，例如，通常的做法是使用
@fopen($file);
然后再检查...但是您可以通过执行以下操作来消除@
if (file_exists($file))
{
fopen($file);
}
else
{
die('File not found');
}
或类似。
我想问题是-是否有@HAS可以用来阻止错误，并且不能以其他任何方式处理？
Answers:
我将抑制该错误并进行处理。否则，您可能会遇到TOCTOU问题（检查时间，使用时间。例如，在file_exists返回true之后但在fopen之前，文件可能会被删除）。
但是我不会仅仅抑制错误以使它们消失。这些更好地可见。
注意：首先，我意识到99％的PHP开发人员都使用错误抑制运算符（我曾经是其中的一个），所以我希望看到这一点的所有PHP开发人员都不同意。
您认为在PHP中使用@运算符来抑制错误/警告是否有效，而您可能正在处理该错误？
简短的回答：
不！
更长一点的正确答案：
我不知道，因为我不了解所有事情，但是到目前为止，我还没有遇到过一个很好的解决方案。
不好的原因：
在我认为使用PHP大约7年的时间里，我已经看到由错误抑制运算符引起的无尽调试痛苦，并且从未遇到过不可避免的情况。
问题是您正在抑制错误的代码段当前可能仅导致您看到的错误；但是，当您更改被禁止的行所依赖的代码或运行它的环境时，该行很有可能会尝试输出与您尝试忽略的错误完全不同的错误。那么，如何找到未输出的错误呢？欢迎调试地狱！
我花了很多年的时间才意识到由于被抑制的错误，我每两个月浪费了多少时间。多数情况下（但非排他性地），这是在安装了第三方脚本/应用程序/库之后，该脚本在开发人员环境中没有错误，但是由于php或服务器配置的差异或缺少依赖关系（通常会立即输出错误）而无法获取提醒问题出在哪里，但当开发人员添加魔术@时则不会。
备选方案（取决于情况和预期结果）：
处理您所知道的实际错误，因此，如果一段代码要引起某个错误，则该代码不会在特定情况下运行。但是我认为您已经掌握了这一部分，您只是担心最终用户会看到错误，这就是我现在要解决的问题。
对于常规错误，您可以设置错误处理程序，以便在查看页面时以所需的方式输出错误，但对最终用户隐藏并记录下来，以便您知道用户触发了哪些错误。
对于display_errors在php.ini中将致命错误设置为关闭（错误处理程序仍被触发）的情况，并启用错误日志记录。如果您同时具有开发服务器和实时服务器（建议使用），则在开发服务器上无需执行此步骤，因此您仍然可以调试这些致命错误，而不必诉诸于错误日志文件。使用关闭功能甚至还可以技巧性地向您的错误处理程序发送大量致命错误。
综上所述：
请避免。可能有一个很好的理由，但是我还没有看到一个理由，所以直到那一天，我认为（@）错误抑制运算符是有害的。
如果需要更多信息，可以在PHP手册的“错误控制运算符”页面上阅读我的评论。
-1模仿一个愚蠢的“是邪恶的”模因。避开内置的语言功能，而对实际用例无视，这是对货物崇拜编程的主要定义。-特别是这位大佬没有提到抑制的错误实际上并没有消失。自定义错误处理程序仍然可以使它们恢复活力（set_error_handler("var_dump");这与scream扩展的懒惰等效）。而且，这种过分的咨询导致了普通的isset()通知抑制语法变通方法，该变通方法实际上会阻碍调试（因为调试通知将被不可恢复地抑制）。
是的，压制是有道理的。
例如，如果无法打开文件，该fopen()命令将返回FALSE。很好，但是它还会产生一条PHP警告消息。通常您不想要警告-您会检查FALSE自己。
实际上，PHP手册特别建议在这种情况下使用@！
如果在使用fopen（）之类的函数时不希望发出警告，则可以抑制该错误，但可以使用异常：
try {
if (($fp = @fopen($filename, "r")) == false) {
throw new Exception;
} else {
do_file_stuff();
}
} catch (Exception $e) {
handle_exception();
}
else，公正do_file_stuff()。
我绝不允许自己使用'@'...句点。
当我在代码中发现“ @”的用法时，无论是在使用时还是在使用它的函数周围的文档块中，都添加了注释，以使其清晰可见。由于这种错误抑制，我也被“追赶幽灵”调试所困扰，我希望通过在找到它时突出显示它的用法来使下一个人更轻松。
如果我想让自己的代码在本机PHP函数遇到错误时抛出异常，并且'@'似乎是最简单的处理方法，那么我反而选择执行其他操作以获得相同的结果，但是（再次）在代码中显而易见：
$orig = error_reporting(); // capture original error level
error_reporting(0); // suppress all errors
$result = native_func(); // native_func() is expected to return FALSE when it errors
error_reporting($orig); // restore error reporting to its original level
if (false === $result) { throw new Exception('native_func() failed'); }
只需编写更多代码：
$result = @native_func();
但是我宁愿让我的压制变得非常明显，因为跟在我后面的调试精神很差。
除非您知道可以处理所有情况，否则应避免错误抑制。
这可能比起初看起来要难得多。
您真正应该做的是依靠php的“ error_log”作为报告方法，因为您不能依靠用户查看页面来报告错误。（并且您还应该禁用php以免显示这些错误）
然后至少您将获得有关系统中所有错误的全面报告。
如果确实必须处理错误，则可以创建一个自定义错误处理程序
http://php.net/set-error-handler
然后，您可以发送异常（可以处理），并做任何需要向管理部门报告奇怪错误的事情。
大多数人不理解错误消息的含义。
别开玩笑了 大多数。
他们认为错误消息都是一样的，并说“出问题了！”
他们不会打扰阅读它。
虽然它是错误消息的最重要部分-不仅是事实已被提出，而且是含义。它可以告诉您出了什么问题。错误消息是帮助，而不是让您“如何隐藏它？”困扰。问题。这是新手Web编程世界中最大的误解之一。
因此，除了阅读错误消息外，还应该阅读错误内容。它不仅具有一个“找不到文件”值。可以有上千种不同的错误：permission denied，save mode restriction，open_basedir restrictionetc.etc。每个人都需要采取适当的措施。但是，如果您插嘴，您将永远不会知道发生了什么！
OP将错误报告与错误处理搞混了，但有很大的不同！
错误处理是针对用户的。在这里“发生了什么”就足够了。
尽管错误报告是针对程序员的，但他们迫切需要知道发生了什么。
因此，切勿阻塞错误消息。两者都为程序员记录下来，并为用户处理。
有没有办法抑制来自php.ini的警告和错误？在这种情况下，您只能调试仅更改标志，而不尝试发现哪个@隐藏了问题。
使用@有时会适得其反。以我的经验，您应该始终在php.ini中关闭错误报告或致电
error_reporting(0);
在生产现场。这样，当您在开发中时，只需注释掉该行，并使错误可见即可进行调试。
ini_set('display_errors',0);或更好，直接修改ini文件以包含该文件。
我真正需要使用的唯一地方是eval函数。eval的问题在于，当由于语法错误而无法解析字符串时，eval不会返回false，而是引发错误，就像在常规脚本中出现解析错误一样。为了检查存储在字符串中的脚本是否可解析，您可以使用类似以下的命令：
$script_ok = @eval('return true; '.$script);
AFAIK，这是最优雅的方法。
PHP中的某些函数会发出一个E_NOTICE（例如，反序列化函数）。
捕获该错误的一种可能方法（对于PHP 7+版本）是将所有已发布的错误转换为异常，而不是让其发布E_NOTICE。我们可以如下更改异常错误处理程序：
function exception_error_handler($severity, $message, $file, $line) {
throw new ErrorException($message, 0, $severity, $file, $line);
}
set_error_handler('exception_error_handler');
try {
unserialize('foo');
} catch(\Exception $e) {
// ... will throw the exception here
}
您不想抑制所有操作，因为它会使脚本运行缓慢。
是的，在php.ini和脚本中都有消除错误的方法（但仅当您处于实时环境中并从php记录错误时才这样做）
<?php
error_reporting(0);
?>
你可以阅读这对于关闭它的php.ini的版本。
今天，我遇到了一个问题，这是一个很好的例子，说明何时可能要至少临时使用@运算符。
长话短说，我发现登录信息（用户名和密码为纯文本）写入了错误日志跟踪。
这里有关此问题的更多信息。
登录逻辑属于其自己的一类，因为系统应该提供不同的登录机制。由于服务器迁移问题，发生了错误。该错误将整个跟踪转储到错误日志中，包括密码信息！一种方法将用户名和密码作为参数，因此trace将所有内容忠实地写入错误日志。
长期的解决方法是重构该类，而不是将用户名和密码用作2个参数，例如，使用包含这2个值的单个数组参数（在这种情况下，trace将为参数写出Array）。还有其他解决此问题的方法，但这是一个完全不同的问题。
无论如何。跟踪消息很有帮助，但在这种情况下完全有害。
当我注意到跟踪输出时，我吸取了教训：有时暂时抑制错误消息是一种有用的停止间隙措施，可避免进一步的伤害。
在我看来，我不认为这是不良类设计的情况。错误本身是由PDOException触发的（时间戳问题从MySQL 5.6移至5.7），PHP会将其默认转储为错误日志。
通常，出于其他注释中解释的所有原因，我不使用@运算符，但是在这种情况下，错误日志使我迅速采取了措施，直到问题得到正确解决。
如果您使用的是自定义错误处理功能，并且想抑制错误（可能是已知错误），请使用此方法。在这种情况下，使用'@'不是一个好主意，因为如果设置了错误处理程序，它将不会抑制错误。
编写3个函数并这样调用。
# supress error for this statement
supress_error_start();
$mail_sent = mail($EmailTo, $Subject, $message,$headers);
supress_error_end(); #Don't forgot to call this to restore error.
function supress_error_start(){
set_error_handler('nothing');
error_reporting(0);
}
function supress_error_end(){
set_error_handler('my_err_handler');
error_reporting('Set this to a value of your choice');
}
function nothing(){ #Empty function
}
function my_err_handler('arguments will come here'){
//Your own error handling routines will come here
}