最稳方式是直接修改正确的php.ini文件，需用php --ini或phpinfo()确认路径，Ubuntu下Apache和Nginx+FPM配置路径不同，改后须重启对应服务；ini_set('display_errors', '1')在FPM中常失效，应配合error_reporting(E_ALL)和log_errors使用；CLI调试推荐php -d参数临时覆盖；空白页需排查BOM和headers already sent问题。
直接改 php.ini 是最稳的，但得确认改对了文件
很多人的 display_errors = On 没生效，根本原因不是写错了，而是改错了 php.ini。PHP 可能加载多个配置文件（比如 CLI 和 Web SAPI 各用一份），必须先确认当前环境读的是哪个：
运行 php --ini 查 CLI 的配置路径，phpinfo() 页面里找 “Loaded Configuration File” 看 Web 环境用的哪份。
常见坑点：
• Ubuntu/Debian 下 Apache 通常用 /etc/php/*/apache2/php.ini，Nginx + PHP-FPM 则要看 /etc/php/*/fpm/php.ini 或 pool 配置里的 php_admin_flag[display_errors]
• 改完必须重启对应服务：Apache 用 sudo systemctl restart apache2，PHP-FPM 用 sudo systemctl restart php*-fpm（版本号要匹配）
脚本开头加 ini_set() 常失效，别只信它
ini_set('display_errors', '1') 在 PHP-FPM 下大概率被忽略，因为 display_errors 属于 INI_SYSTEM 级别指令，FPM 池配置中若设了 php_admin_flag[display_errors] = off，它就完全无效。
更现实的做法是组合使用：
• 必须加 error_reporting(E_ALL) —— 这个函数调用几乎总是生效
• ini_set('log_errors', '1') 和 ini_set('error_log', '/tmp/php-debug.log') 通常有效，错误会落盘
• 不要依赖 ini_set('display_errors', '1') 做唯一手段，尤其在 Nginx + FPM 场景下
CLI 调试别硬改配置，用 -d 参数最干净
写完脚本想快速验证有没有 Notice 或 Warning？直接命令行跑，不用碰任何配置文件：php -d display_errors=1 -d error_reporting=E_ALL script.php
这个命令临时覆盖所有配置，且只对本次执行生效。
顺手还能加其他调试参数：
• -d memory_limit=512M 防止内存爆掉中断
• -d xdebug.mode=debug（如果装了 Xdebug 3+）
• 错误输出可能被终端截断？加上 2>&1 把 stderr 也重定向：php script.php 2>&1
开了 display_errors 还是空白页？先查 BOM 和提前输出
即使配置全开，页面仍空白或只显示部分 HTML，大概率是 PHP 已经发了响应头——headers already sent 错误会让 display_errors 彻底失能。
典型诱因：
• 文件开头有 UTF-8 BOM（尤其 Windows 编辑器保存时默认带），用 hexdump -C yourfile.php | head 看前几字节是不是 ef bb bf
• <?php 前有空格、换行或注释
• 脚本里提前调用了 session_start()、header() 或任何输出函数
• 输出缓冲没 flush：加 ob_end_flush(); 在出错前试试，但治标不治本，根源还是别让内容提前发出
立即学习“PHP免费学习笔记（深入）”；
实际调试时，最常卡住的地方不是“怎么开”，而是“开了为什么看不见”。BOM、FPM 管理员配置、Xdebug 强制开关、甚至 CDN 过滤 Warning 字样，都可能让错误消失得毫无痕迹。日志永远比浏览器输出更可信。
