可以，通过在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系统上，路径分隔符通常是分号（
;
登录后复制），而在Linux/macOS上是冒号（
:
登录后复制），这点也得留意。
-
并非所有配置都可覆盖： 绝大多数配置项都可以通过
-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流程中，这种做法是标配。
以上就是PHP命令如何设置多个-d参数修改不同配置项 PHP命令多配置修改的实用方法的详细内容，更多请关注php中文网其它相关文章！