使用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.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 3Script 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的命令行世界里，更加游刃游刃有余。
以上就是PHP命令怎样用-d参数临时开启display_errors PHP命令临时显示错误的设置教程的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1291307.html
微信扫一扫 
支付宝扫一扫 
