PHP 脚本一旦触发内存不足，常见报错往往都指向 memory_limit。真正麻烦的地方通常不在“怎么改”，而在于要先判断你改的是 Apache、CLI，还是 Nginx + PHP-FPM 这一层的配置。
这篇文章把 Linux 下调整 PHP 内存限制的三种常见做法拆开说明：什么时候该改 php.ini，什么时候适合用 .htaccess，以及临时跑脚本时怎么直接带参数执行。看完之后，你可以按自己的运行环境选最省事的一种，同时避开改了却不生效的问题。
先判断该用哪种设置方式
在动手之前，先确认你要解决的是哪一类场景：
- 大多数站点或服务统一调整：优先修改
php.ini。 - 只想让某个 Apache 站点单独生效：可以使用
.htaccess。 - 只为一次命令行脚本临时放宽限制：直接使用 CLI 的
-d参数即可。
这一步很重要，因为 PHP 在不同运行方式下，读取的配置文件并不一定相同。最常见的问题就是：你改了一个 php.ini，但实际执行脚本的环境根本没加载它。
方法一：修改 php.ini，适合大多数场景
这是最直接、也最常用的做法。只要你有服务器配置权限，通常都建议优先采用这种方式。
先找到当前环境使用的 php.ini
php.ini 的位置会受到 PHP 版本和运行环境影响。文中给出的常见路径包括：
- Apache 环境：
/etc/php/{php_version}/apache2/php.ini - CLI 命令行环境：
/etc/php/{php_version}/cli/php.ini
如果你不确定当前加载的是哪一个配置文件，最稳妥的办法是直接执行：
php --ini这个命令会输出当前 PHP 加载的配置文件路径，适合先做定位再修改。
编辑配置并修改 memory_limit
确认路径后，用常用编辑器打开配置文件。例如在 Apache 环境下：
sudo nano /etc/php/{php_version}/apache2/php.ini如果要修改的是 CLI 环境，就改成对应路径：
sudo nano /etc/php/{php_version}/cli/php.ini打开后搜索 memory_limit，将其改为需要的值，例如：
memory_limit = 512M如果你只是想确认当前限制是多少，也可以直接搜索 memory_limit 查看现有配置。
保存后重启服务才会生效
编辑完成后保存退出：
nano：按Ctrl + X，再按Y，最后按Entervim：按Esc，输入:wq，再按Enter
如果你修改的是 Web 服务使用的 PHP 配置，还需要重启相关服务。
Apache：
sudo systemctl restart apache2Nginx + PHP-FPM：
sudo systemctl restart php{php_version}-fpm
sudo systemctl restart nginx这里的 {php_version} 要替换为实际 PHP 版本号。只有完成重启，新的内存限制才会被 Web 请求正式加载。
方法二：用 .htaccess 单独调整站点限制
如果你无法修改服务器级别的 php.ini，或者只想针对某一个 Apache 站点单独设置，.htaccess 会更方便。
在站点根目录加入配置
在网站根目录找到或创建 .htaccess 文件，然后加入下面这一行：
php_value memory_limit 512M保存后即可生效，通常不需要重启服务。
这种方式的适用前提
.htaccess 方式有两个明确边界：
- 只适用于 Apache。
- 服务器必须允许通过
.htaccess覆盖相关配置。
如果你的环境是 Nginx，或者主机商禁用了这类覆盖配置，那么这条方法就不会起作用。
方法三：命令行临时设置，适合一次性任务
如果你只是临时执行某个 PHP 脚本，不想改配置文件，也不想影响其他任务，可以直接在命令中追加 -d 参数：
php -d memory_limit=512M这种设置只对当前命令行会话有效。终端关闭、命令结束，或者下次重新执行脚本时，这个限制都不会被保留。
因此，它很适合以下场景：
- 临时测试脚本是否因内存限制失败
- 执行一次性数据处理任务
- 排查某个 CLI 脚本的资源占用问题
调整内存限制前，最好先看这两个风险点
不要把限制设到超过机器承受范围
设置的内存值不能超过服务器的实际物理内存。否则在高并发或多个进程同时运行时，系统可能出现进程被杀死，严重时还会拖垮整台机器。
能优化代码时，别只靠继续加内存
如果应用确实长期需要更大的内存，单纯提升 memory_limit 往往只能缓解表面问题。更值得排查的是代码逻辑本身，例如是否存在不必要的大数组、重复加载数据、循环中持续堆积对象等情况。
换句话说，内存限制的调整应该服务于实际业务需要，而不是替代性能优化。够用、稳定、可控，通常比一味调大更重要。
