可以，通过在php命令后添加多个-d参数可临时修改PHP配置，如php -d memory_limit=512M -d max_execution_time=300 script.php，每个-d后接key=value，优先级高于php.ini，仅对当前执行生效，适用于高资源需求或调试场景。
PHP命令确实可以同时设置多个
-d
参数来修改不同的配置项。这是一种非常实用且灵活的方式，能让你在不触碰全局
php.ini
文件的情况下，为特定的PHP脚本执行定制化环境。
解决方案
直接在
php
命令后跟上多个
-d
参数即可，每个
-d
参数后面紧跟一个
key=value
对。PHP解释器在执行脚本前，会优先应用这些命令行传入的配置。
例如，如果你想同时提高脚本的内存限制和执行时间限制，可以这样操作：
php -d memory_limit=512M -d max_execution_time=300 your_script.php
这里，
memory_limit
被设置为512MB，而
max_execution_time
则延长到300秒。你可以根据需要添加任意数量的
-d
参数。这种方法尤其适用于那些资源消耗较大的脚本，或者在调试时需要临时调整某些行为的场景。它只对当前这次命令执行有效，不会影响系统上其他PHP进程或后续的PHP命令。
为什么我们需要在命令行临时修改PHP配置？
在我看来，临时修改PHP配置项的需求，往往源于我们日常开发和运维中的一些“痛点”。你想啊，全局的
php.ini
文件通常是为整个服务器环境服务的，它设定了一个基线。但很多时候，我们跑一个特定的脚本，比如一个数据导入工具，或者一个复杂的报告生成器，它可能需要远超常规的内存或更长的执行时间。这时候去改全局配置，不仅可能影响到其他应用，还可能需要重启PHP-FPM或Web服务器，这在生产环境简直是不可接受的。
立即学习“PHP免费学习笔记（深入）”；
所以，命令行参数就成了救星。它提供了一种“一次性”的解决方案：你只为当前这个特定的任务，暂时性地放宽限制。比如，我有一个定时任务，每天凌晨会处理大量日志，这个任务就可能需要
memory_limit=1G
，但我的网站应用平时只需要
128M
。用
-d
参数，我可以让定时任务跑得顺畅，又不用担心网站被不必要的资源占用拖慢。这就像是给特定的工具配备了专属的“燃料”，而不是把整个油箱都换掉。
-d
-d
参数的工作原理与常见陷阱
理解
-d
参数的工作原理，其实很简单。当你在命令行输入
php -d key=value script.php
时，PHP解释器在启动并加载完所有INI文件（包括主
php.ini
以及其他额外的INI文件）之后，会处理这些命令行参数。这些
-d
参数的优先级是最高的，它们会覆盖之前加载的任何同名配置项。说白了，它们就是“最终的决定”。
不过，使用起来也有一些小坑需要注意：
- 语法严格：
key=value
之间不能有空格。比如
php -d memory_limit = 512M
是错的，必须是
php -d memory_limit=512M
。
- 值的类型： 对于布尔值，通常用
1
或
On
表示真，
0
或
Off
表示假。例如
php -d display_errors=1
。
- 路径与引号： 如果配置项的值包含空格或特殊字符（比如
include_path
），通常需要用引号包起来，以防Shell误解析。例如：
php -d include_path=".:/usr/local/php/pear"
。在windows系统上，路径分隔符通常是分号（
;
:
），这点也得留意。
- 并非所有配置都可覆盖： 绝大多数配置项都可以通过
-d
覆盖，但极少数在PHP编译时就固定的核心设置可能无法修改。不过，这在日常使用中很少遇到。
- Shell转义： 有时候，如果你在
-d
参数的值中使用了Shell的特殊字符（比如
$
或
!
），可能需要对它们进行额外的转义，或者使用单引号（
'
）来包裹整个值，确保Shell不会提前解释它们。
记住，
-d
参数的修改是瞬时的，它只作用于当前这次
php
命令的执行。命令结束后，这些临时的配置就失效了。
结合脚本与自动化：提升开发效率
仅仅知道
-d
参数怎么用还不够，真正让它发挥价值的是把它融入到你的工作流和自动化脚本中。这方面，我个人觉得composer脚本和shell脚本是两个非常好的搭档。
1. Shell脚本封装复杂命令 对于那些需要频繁运行，并且配置项比较多的PHP命令，我会写一个小小的Shell脚本来封装它。比如，我有一个导入大量数据的PHP脚本，它不仅需要高内存，还需要禁用一些错误显示，并且可能要设置特定的时区：
#!/bin/bash # run_data_import.sh php -d memory_limit=2G -d max_execution_time=0 -d display_errors=Off -d error_reporting=E_ALL&~E_NOTICE -d date.timezone=Asia/Shanghai /path/to/your/import_script.php "$@"
然后我只需要运行
./run_data_import.sh
，就能以预设的配置来执行脚本了。
"$@"
参数还能让我把额外的参数传递给
import_script.php
，这让脚本变得非常灵活。
2. Composer脚本集成开发流程 如果你在使用Composer管理项目，那
composer.json
里的
scripts
字段简直是为这种场景量身定制的。你可以定义一些自定义的命令，在这些命令里嵌入
-d
参数。
{ "name": "my/project", "scripts": { "test:heavy": "php -d memory_limit=1G vendor/bin/phpunit --coverage-html build/coverage", "cron:daily": "php -d max_execution_time=0 -d error_reporting=E_ERROR public/index.php cron:run-daily", "db:migrate": "php -d memory_limit=512M bin/console doctrine:migrations:migrate" } }
这样一来，团队成员只需要运行
composer test:heavy
、
composer cron:daily
或
composer db:migrate
，就能以正确的、针对性的PHP配置来执行这些任务，大大减少了因环境配置差异导致的问题，也避免了大家手动输入一长串参数的麻烦。这不仅提高了效率，也保证了执行环境的一致性，特别是在CI/CD流程中，这种做法是标配。
