php cli下错误不显示需先确认display_errors是否生效：cli使用独立php.ini（如php-cli.ini或[cli]节），须用php --ini定位配置文件并在[cli]段设display_errors=on，再用php -i | grep验证；脚本中还需error_reporting(e_all)配合ini_set('display_errors','1')，但解析错误等需用php -d参数或日志输出。
CLI下错误不显示？先确认display_errors是否生效
PHP CLI模式默认关闭display_errors，哪怕你在php.ini里设为On，CLI用的其实是独立配置文件（通常是php-cli.ini或php.ini中[cli]节）。直接改错配置文件就白忙。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php --ini看CLI实际加载哪个php.ini路径 - 检查该文件中是否存在
[cli]段落，里面是否有display_errors = On - 如果没有
[cli]段，加一行display_errors = On在文件末尾也无效——必须在对应段落下 - 改完后用
php -i | grep display_errors验证是否生效
脚本里临时开启错误显示：别只靠ini_set()
ini_set('display_errors', '1')在CLI里能起作用，但有个硬限制：如果error_reporting是0，还是看不到任何错误。很多人只改display_errors，忘了报错级别本身被关了。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在脚本开头加上
error_reporting(E_ALL); ini_set('display_errors', '1'); - 注意
ini_set()对某些错误类型（如解析错误Parse error）完全无效——这类只能靠配置文件或命令行参数 - 如果用
php -d display_errors=1 script.php方式运行，-d参数优先级高于脚本内ini_set()，更可靠
致命错误（Fatal Error）没输出？检查log_errors和error_log
CLI下Fatal error有时连display_errors = On都救不了，尤其当脚本在register_shutdown_function里做了清理、或用了ob_start()但没刷出缓冲区时，错误可能被吞掉。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 强制把错误写进日志：
php -d log_errors=On -d error_log=/tmp/php-cli-errors.log script.php - 检查
/tmp/php-cli-errors.log内容，比终端输出更全 - 避免在
shutdown函数里调用ob_end_clean()之类操作，容易掩盖原始错误堆栈 -
error_log路径必须有写入权限，否则错误会静默丢弃
Composer脚本或Phar包里错误消失？绕过display_errors限制
Composer执行scripts或运行Phar包时，PHP可能以极简环境启动，display_errors常被重置为Off，且你没法改它的php.ini。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在Composer脚本命令前加
php -d display_errors=1 -d error_reporting=-1（-1等价于E_ALL） - Phar打包时，在入口脚本第一行写
<?php error_reporting(E_ALL); ini_set('display_errors', '1'); ?>，别依赖外部配置 - 不要用
ini_set('html_errors', '1')——CLI下这个没意义，反而可能干扰纯文本输出
最常被忽略的是：CLI和Web服务器用的不是同一份php.ini，连php --ini都不看就去改/etc/php/8.2/apache2/php.ini，等于在修隔壁家的水管。
