宝塔面板php7.4的memory_limit不生效，需先用phpinfo()确认实际加载的php.ini路径，检查是否被php-fpm.d/www.conf或运行时ini_set覆盖，修改后必须完整重启php-fpm-74服务并清理opcache。
宝塔面板里改 PHP7.4 的 memory_limit 不生效？先确认改的是哪个配置文件
宝塔面板可能同时存在多个 php.ini 文件，改错位置是常见失效原因。PHP 实际加载的配置文件路径，必须用 phpinfo() 确认，不能凭面板界面或文件路径猜测。
- 在网站根目录新建
info.php，内容为<?php phpinfo(); ?>，通过浏览器访问它，找到 “Loaded Configuration File” 行，记下完整路径（例如/www/server/php/74/etc/php.ini） - 宝塔后台「软件管理 → PHP7.4 → 配置修改」打开的确实是这个文件，但部分用户手动编辑过其他位置（如
/www/server/php/74/etc/php-fpm.d/www.conf中的php_admin_value[memory_limit]），会覆盖php.ini设置 - CLI 模式（命令行执行 PHP）和 FPM 模式（网站运行）可能读取不同配置，
php -i | grep "Loaded Configuration File"查 CLI 路径，phpinfo()查 Web 路径
直接改 memory_limit 后仍报“Allowed memory size exhausted”？检查是否被运行时覆盖
即使 php.ini 里设了 memory_limit = 512M，PHP 脚本仍可能在运行中被强制调低，尤其是 WordPress、Laravel 等框架或某些插件会主动调用 ini_set('memory_limit', ...)。
- 搜索项目代码中是否有
ini_set('memory_limit'或wp_raise_memory_limit()（WordPress）等调用，它们优先级高于php.ini - 在报错页面的
phpinfo()输出中，查看 “memory_limit” 行右侧的 “Local Value” 和 “Master Value”：如果两者不一致，说明被运行时修改过 - 若需彻底锁定，可在
php-fpm.d/www.conf中添加php_admin_value[memory_limit] = 512M（注意是admin_value，不可被脚本覆盖）
改完重启什么服务才真正生效？别只点“重载配置”
修改 php.ini 后，仅在宝塔面板点「重载配置」或「重启 PHP」并不总能刷新全部进程，尤其当有长连接、OPcache 缓存或子进程残留时。
- 必须执行完整重启：
service php-fpm-74 restart（或在宝塔后台「软件管理 → PHP7.4 → 停止 → 启动」） - 如果用了 OPcache，还需在宝塔 PHP 管理页点「清理 OPcache」，否则旧内存限制可能缓存生效
- 某些情况下 Nginx/Apache 也会缓存 PHP 进程，可顺带重启 Web 服务（但通常非必须）
- 验证是否生效：执行
php -r "echo ini_get('memory_limit').PHP_EOL;"（CLI）和访问info.php（Web）双端比对
设太高反而出问题？注意系统资源与 PHP 版本兼容性
memory_limit 不是越大越好，PHP7.4 在低内存环境（如 1G 内存小鸡）设成 2G 可能导致 OOM Killer 杀死进程，或引发 FPM 子进程反复崩溃。
- 建议值参考：普通网站 256M–512M；WordPress + 多插件 512M–1G；命令行脚本（如 Composer 更新）可临时设为
-1（不限制），但切勿长期设为-1上生产 - PHP7.4 对
memory_limit为-1的处理比 8.x 更敏感，某些扩展（如imagick）在无限制下易触发系统级内存溢出 - 如果频繁出现
Out of memory (allocated XXXX)错误，优先排查内存泄漏（如未释放的大数组、循环引用），而非一味加限
最常被忽略的一点：改完 php.ini 后没确认 FPM 子进程是否真正加载新配置——哪怕 phpinfo() 显示正确，也可能因 master 进程未完全退出而沿用旧值，强制杀掉所有 php-fpm-74 进程再启更稳妥。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
