找到正确的php.ini文件，通过访问phpinfo()确认加载路径；2. 修改display_errors = on和error_reporting = e_all；3. 重启web服务器（apache/nginx/iis）使配置生效；4. 确保未在服务器配置（如apache的.htaccess、nginx+php-fpm的池配置、iis的php manager）或php代码中覆盖错误显示设置；5. 检查是否开启display_startup_errors以查看启动阶段错误；6. 确认log_errors开启并将error_log指向可写路径以记录错误日志；7. 排查opcache或php-fpm缓存导致的配置未生效问题；8. 查看web服务器和php错误日志作为辅助排查手段。修改php错误显示的核心在于正确配置php.ini并确保所有相关组件同步生效，避免因配置覆盖或缓存导致问题。
搞PHP开发，看不到错误信息那简直是摸黑走路。在Windows 11上，这事儿其实不复杂，就是改几个配置文件的事儿，主要是php.ini，然后重启一下你用的Web服务器（比如Apache、Nginx或IIS）。核心就是告诉PHP，把错误大大方方地显示出来，而不是藏着掖着。
解决方案
说白了，就那么几步，但每一步都得对，不然你可能还是抓瞎。首先得找到那个神秘的php.ini文件。这玩意儿通常藏在你的PHP安装目录里，或者如果你用WAMP/XAMPP，它会在对应PHP版本的文件夹下。如果你不确定，可以创建一个info.php文件，内容是<?php phpinfo(); ?>，放到Web服务器的根目录访问一下，里面会明确告诉你Loaded Configuration File的位置。
找到php.ini后，用文本编辑器打开它，找到并修改以下两项：
立即学习“PHP免费学习笔记（深入）”；
-
display_errors: 这个是控制错误是否直接输出到浏览器页面的。- 找到
display_errors = Off(或者On) - 把它改成
display_errors = On
- 找到
-
error_reporting: 这个决定了PHP会报告哪些级别的错误。开发阶段，我个人建议你直接开到最大，这样任何潜在的问题都能被你看到。
- 找到
error_reporting = E_ALL(或者其他值，比如E_NOTICE,E_WARNING等) - 把它改成
error_reporting = E_ALL - 如果你想更细致，比如在生产环境，可能只显示致命错误，那就是
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED，但在开发环境，我们就是要“看清一切”。
- 找到
修改完php.ini之后，最关键的一步是重启你的Web服务器。Apache用户重启Apache服务，Nginx用户重启Nginx服务，IIS用户可能需要重启IIS管理器中的站点或整个IIS服务。不重启的话，配置是不会生效的。
PHP错误显示为什么不生效？常见配置误区与排查
有时候你明明改了，却发现没用，这感觉特糟心。我以前也遇到过，改完php.ini，结果发现自己改的是PHP CLI（命令行接口）用的那个，而不是Apache或Nginx实际加载的。所以，第一步永远是确认你改对文件了。phpinfo()就是个好工具，能告诉你当前Web服务器加载的是哪个php.ini。
另一个常见问题是没有重启Web服务器。这听起来很基础，但真的很容易忘。改了配置文件，服务器可不会自动读取新设置，它得重新启动加载。
再来就是display_startup_errors。如果你的PHP代码在解析阶段就出错了，比如php.ini本身有问题，或者某些扩展没加载对，那可能需要设置display_startup_errors = On才能看到这些启动错误。它默认是关闭的。
还有，别把display_errors和log_errors混淆了。display_errors是把错误显示在浏览器上，而log_errors是把错误写入到日志文件里。在开发环境，通常两者都会开启，但在生产环境，你只会开log_errors，把错误记录下来而不是直接暴露给用户。确保error_log指令指向一个可写的文件路径，这样错误才能被记录下来。
最后，一些高级的PHP安装，比如使用了OPcache，可能会缓存旧的php.ini设置。在极端情况下，清除OPcache缓存或者重启PHP-FPM进程（如果你的Web服务器是通过PHP-FPM与PHP通信的）也是一个排查方向。
深入理解error_reporting：如何设置才能看到所有关键错误？
error_reporting这东西，是个双刃剑。设置得太松，你可能错过很多潜在问题；设置得太严，又可能被一大堆不重要的通知烦死。但在开发阶段，我个人强烈建议你直接开到最大，也就是E_ALL。
E_ALL意味着报告所有错误、警告、通知、废弃特性等。这能让你及时发现代码中的潜在问题，比如使用了未定义的变量（E_NOTICE），或者调用了已废弃的函数（E_DEPRECATED）。虽然E_NOTICE有时候会很烦人，因为它会提示你一些非致命的小问题，但这些小问题往往是代码不够严谨的表现，在大型项目中积累起来可能会导致意想不到的bug。
PHP定义了多种错误级别，例如：
-
E_ERROR: 致命的运行时错误，脚本会停止执行。 -
E_WARNING: 运行时警告，脚本不会停止。 -
E_PARSE: 编译时解析错误，脚本会停止。 -
E_NOTICE: 运行时通知，可能是代码中的一个错误，也可能是故意的。 -
E_DEPRECATED: 使用了过时或即将移除的特性。 -
E_STRICT: 运行时建议，用于PHP代码的互操作性或向后兼容性。
所以，当你在php.ini里设置error_reporting = E_ALL时，你基本上是告诉PHP：“不管是什么毛病，都给我抖出来！”这对于快速定位问题、提升代码质量非常有帮助。
除了php.ini，还有哪些因素会影响PHP错误显示？
别以为改了php.ini就万事大吉了，有时候它就是不听话。我记得有次，折腾了半天，最后发现是Apache的虚拟主机配置里，有个php_value display_errors Off，直接把我的设置给覆盖了。那种感觉，真是哭笑不得。
所以，Web服务器本身的配置也是一个需要检查的地方：
-
Apache: 如果你在
.htaccess文件或者虚拟主机的配置文件（比如httpd-vhosts.conf）里使用了php_flag display_errors Off或者php_value error_reporting，这些指令会覆盖php.ini的设置。检查这些地方，确保它们没有把你的错误显示关掉。 -
Nginx + PHP-FPM: Nginx本身不处理PHP，它把请求转发给PHP-FPM。PHP-FPM也有自己的
php.ini，通常在php-fpm.d目录下会有针对不同池（pool）的配置文件，比如www.conf。确保你修改的是PHP-FPM进程实际加载的php.ini，并且重启了PHP-FPM服务。 -
IIS: 在IIS中，你可以在站点或应用程序级别的配置中覆盖PHP设置。通过IIS管理器，选择你的网站，找到“PHP Manager”或“配置编辑器”，查看
system.webServer/php相关设置，确保display_errors是开启的。
除了服务器配置，PHP应用内部的代码也可能影响错误显示。比如，如果你的应用使用了set_error_handler()函数来自定义错误处理逻辑，或者在代码中通过ini_set('display_errors', 'Off');动态地关闭了错误显示，那么即使php.ini里是开启的，你也不会在页面上看到错误。在调试时，可以暂时注释掉这些自定义错误处理的代码，或者确保它们不会抑制所有错误显示。
最后，即使错误没有显示在页面上，它们通常也会被记录在Web服务器的错误日志（如Apache的error_log，Nginx的error.log）或PHP自身的错误日志（error_log指令指定的路径）中。养成查看这些日志的习惯，是解决PHP问题的关键。很多时候，页面上啥都没有，但日志里已经把问题说得明明白白了。
