使用php -d参数可临时开启display_errors以在命令行中即时查看错误信息，而无需修改全局php.ini配置。1. 通过php -d display_errors=on script.php命令可临时显示错误；2. 可结合error_reporting=e_all来显示所有错误级别；3. 可用于调试cli脚本、测试代码路径、ci/cd流程或无权限修改php.ini的环境；4. 还可临时调整memory_limit、max_execution_time、include_path和date.timezone等配置项；5. -d参数的优势在于其临时性、无副作用且不影响其他php进程，是高效安全的调试手段。
当你想在命令行（CLI）下运行PHP脚本，同时又需要立即看到脚本可能抛出的错误，但又不希望去改动服务器上全局的
php.ini
配置时，
php -d
参数就是你的救星。简单来说，它允许你为单次PHP命令执行临时开启或修改任何PHP配置项，比如我们今天要聊的
display_errors
。你只需要在运行PHP命令时加上
-d display_errors=On
，就能让错误信息直接打印到你的终端上。
要临时开启
display_errors
，你可以在执行PHP脚本时，在
php
命令后面加上
-d display_errors=On
。
例如，如果你有一个名为
test.php
的脚本，里面故意写了一个错误：
立即学习“PHP免费学习笔记（深入）”；
<?php // test.php echo $undefinedVariable; // 故意引用一个未定义的变量 echo "Script finished.n"; ?>
正常情况下，如果你的
php.ini
里
display_errors
是
Off
，直接运行
php test.php
可能什么错误都不会显示，或者只会显示一个空白。但如果你这样运行：
php -d display_errors=On test.php
你就会在终端看到类似这样的输出：
PHP Notice: Undefined variable: undefinedVariable in /path/to/test.php on line 3 Script finished.
这正是我们想要的，临时性地让错误信息显现出来，方便你快速定位问题。你也可以用
-d display_errors=stderr
让错误输出到标准错误流。
display_errors
display_errors
到底是什么，以及它为什么重要？
display_errors
，从字面上看，就是控制PHP错误是否被“显示”出来。它是个布尔值（
On
或
Off
），或者可以设置为
stderr
（输出到标准错误流）。在PHP的世界里，错误管理是门大学问，而
display_errors
就是这扇窗户。它决定了当你的代码跑起来遇到问题时，这些问题是以什么形式、在哪里呈现。
为什么它重要？想象一下，你写了一段PHP代码，在本地测试好好的，一上线却“白屏”了。你完全不知道发生了什么。这时候，如果
display_errors
是
Off
，你可能就得去翻服务器日志，或者猜测半天。但如果它临时是
On
，哪怕只是一个Notice或者Warning，也能立刻告诉你问题出在哪里，比如某个变量未定义，或者某个文件找不到了。它就像一个即时反馈系统，是调试初期最直接的“对话”方式。
当然，在生产环境，我们通常会把
display_errors
设为
Off
，因为把错误信息直接暴露给最终用户不仅不专业，还可能泄露敏感信息，给攻击者提供线索。所以，理解它在开发和生产环境中的不同角色，至关重要。
什么时候应该用
-d
-d
参数，而不是直接改
php.ini
？
这其实是个很经典的场景选择题。什么时候我们应该灵活地用
-d
，而不是去动那个“神圣”的
php.ini
文件？我的经验是，当你需要“一次性”、“临时性”或“不影响他人”的配置调整时，
-d
参数就显得无比优雅。
举几个例子：
- 快速调试某个CLI脚本： 你可能在本地写了一个定时任务脚本，或者一个数据处理脚本，它在跑的时候总是不按预期执行。你不想为了它去改动整个开发环境的
php.ini
，这时直接在命令行加上
-d display_errors=On
，跑一下，错误信息就出来了，调试效率瞬间提升。
- 测试特定代码路径： 有时候你只想看看某个特定函数在某种参数下会不会报错，或者某个新的库集成进来有没有兼容性问题。你不需要全局开启错误显示，只需要针对这次测试。
- CI/CD环境： 在自动化测试或部署流程中，你可能希望在某个特定阶段，如果PHP脚本有任何错误或警告，都能立即中断流程并显示出来，而不是默默失败。在CI脚本里加上
-d
参数，既能保证自动化流程的健壮性，又不会影响到实际部署环境的配置。
- 没有权限修改
php.ini
：
在一些共享主机或者受限的开发环境中，你可能根本没有权限去修改php.ini
。这时候，
-d
参数就成了你唯一的“救命稻草”，让你能够临时调整一些关键配置。
- 避免副作用： 修改
php.ini
通常意味着重启PHP-FPM或Apache/Nginx，这会中断服务，或者至少影响到所有正在运行的PHP应用。而
-d
参数只影响当前这条命令的执行，完全没有副作用。
总而言之，
-d
参数是那种“用完即走”的配置方式，它提供了一种轻量级、无侵入的调试和测试手段。
除了
display_errors
display_errors
，还有哪些PHP配置可以用
-d
临时修改？
-d
参数的强大之处在于，它几乎可以临时修改任何PHP配置项，只要那个配置项不是PHP编译时就固定死的。这为我们的调试和测试提供了巨大的灵活性。除了
display_errors
，我个人经常会用它来调整以下几个配置：
-
error_reporting
：
这是和display_errors
紧密相关的配置。
display_errors
决定是否显示错误，而
error_reporting
则决定显示哪些级别的错误（例如，只显示致命错误，还是所有Notice、Warning都显示）。在调试时，我可能会这样组合使用：
php -d display_errors=On -d error_reporting=E_ALL test.php
，确保所有可能的错误和警告都无所遁形。
-
memory_limit
：
跑一些大型数据处理脚本时，经常会遇到“Allowed memory size of X bytes exhausted”的错误。如果不想修改php.ini
，我就会临时调高内存限制：
php -d memory_limit=512M my_heavy_script.php
。
-
max_execution_time
：
类似内存限制，长时间运行的脚本可能会因为执行时间过长而被终止。这时可以临时延长执行时间：php -d max_execution_time=300 my_long_script.php
（单位是秒）。
-
include_path
：
当你的脚本依赖于某个不在标准include_path
中的库或文件时，你可以临时添加路径：
php -d include_path=".:/path/to/my/library" my_script.php
。这在测试新库或者非标准项目结构时非常有用。
-
date.timezone
：
虽然这通常在php.ini
中设定，但如果你在调试一个对时区敏感的脚本，或者想模拟不同时区下的行为，
-d date.timezone=Asia/Shanghai
或者
UTC
就可以派上用场。
记住，
-d
参数的灵活性在于它能让你在不触碰全局配置的前提下，为每一次的CLI执行“定制”一个临时的PHP环境。这对于快速迭代、问题排查，或者在受限环境中工作，都是一个极其宝贵的工具。善用它，能让你在PHP的命令行世界里，更加游刃游刃有余。
评论（已关闭）
评论已关闭