尝试在实际的php文件中设置错误报告级别。或者，像其他人建议的那样，检查你的服务器设置——可能是php.ini中的一些东西，或者是关于你的主机的一些限制。不要仅仅依赖于。htaccess。此外，在排除故障时，print_r任何您认为可疑的变量。

有一个非常有用的扩展名为“xdebug”，它也会使您的报告更好。

如果错误是在PHP代码中，您可以在代码中使用error_reporting()函数来设置为报告所有。

但是，这并不能处理PHP崩溃的情况。这方面的信息只能在服务器日志中找到。也许你无法访问这些，但我合作过的许多托管提供商都有某种方式让你访问它。例如，我最喜欢的方法是在.php所在的当前目录中创建error_log文件。尝试在那里搜索或联系您的主机提供商。

这个答案是由冗余部门为您带来的。

ini_set() / php.ini / .htaccess / .user.ini The settings display_errors and error_reporting have been covered sufficiently now. But just to recap when to use which option: ini_set() and error_reporting() apply for runtime errors only. php.ini should primarily be edited for development setups. (Webserver and CLI version often have different php.ini's) .htaccess flags only work for dated setups (Find a new hoster! Well managed servers are cheaper.) .user.ini are partial php.ini's for modern setups (FCGI/FPM) And as crude alternative for runtime errors you can often use: set_error_handler("var_dump"); // ignores error_reporting and `@` suppression error_get_last() Can be used to retrieve the last runtime notice/warning/error, when error_display is disabled. $php_errormsg Is a superlocal variable, which also contains the last PHP runtime message. isset() begone! I know this will displease a lot of folks, but isset and empty should not be used by newcomers. You can add the notice suppression after you verified your code is working. But never before. A lot of the "something doesn't work" questions we get lately are the result of typos like: if(isset($_POST['sumbit'])) # ↑↑ You won't get any useful notices if your code is littered with isset/empty/array_keys_exists. It's sometimes more sensible to use @, so notices and warnings go to the logs at least. assert_options(ASSERT_ACTIVE|ASSERT_WARNING); To get warnings for assert() sections. (Pretty uncommon, but more proficient code might contain some.) PHP7 requires zend.assertions=1 in the php.ini as well. declare(strict_types=1); Bending PHP into a strictly typed language is not going to fix a whole lot of logic errors, but it's definitely an option for debugging purposes. PDO / MySQLi And @Phil already mentioned PDO/MySQLi error reporting options. Similar options exist for other database APIs of course. json_last_error() + json_last_error_msg For JSON parsing. preg_last_error() For regexen. CURLOPT_VERBOSE To debug curl requests, you need CURLOPT_VERBOSE at the very least. shell/exec() Likewise will shell command execution not yield errors on its own. You always need 2>&1 and peek at the $errno.

打开php.ini， 确保它被设置为:

display_errors = On

重新启动服务器。

如果你超级酷，你可以试试:

$test_server = $_SERVER['SERVER_NAME'] == "127.0.0.1" || $_SERVER['SERVER_NAME'] == "localhost" || substr($_SERVER['SERVER_NAME'],0,3) == "192";

ini_set('display_errors',$test_server);
error_reporting(E_ALL|E_STRICT);

这将只在本地运行时显示错误。它还提供了test_server变量，以便在其他适当的地方使用。

在脚本运行之前发生的任何错误都不会被捕获，但对于我所犯的99%的错误，这不是问题。