php memory_limit 调整无效主因是改错配置文件位置：fpm模式需改 /www/server/php/{版本}/etc/php.ini，站点级在 user.ini，cli则用 /bin/php.ini；改后必须重启 php-fpm 服务，且需用 info.php 或命令行验证真实值。
PHP memory_limit 为什么调了没生效？
宝塔面板里改了 memory_limit 却还是报 Fatal error: Allowed memory size of xxx bytes exhausted，大概率不是没保存，而是改错了位置——PHP 有多个配置文件，而宝塔会为每个 PHP 版本、每个站点、甚至 CLI 和 FPM 模式分别加载不同配置。
- 全局生效要改
/www/server/php/{版本号}/etc/php.ini（FPM 模式主配置） - 站点单独限制在宝塔「网站 → 设置 → PHP 版本 → 配置文件」里，但那是
user.ini，仅对当前站点 Web 请求有效 - CLI 命令（如 Composer、Artisan）走的是另一个
php.ini，路径通常是/www/server/php/{版本号}/bin/php.ini - 改完必须重启对应 PHP 服务：
service php-fpm-{版本号} restart，光点宝塔「重载配置」不够
memory_limit 设多少才合理？
盲目设成 -1（无限制）或 2G 很危险：单个请求吃光内存会触发 OOM Killer，导致 PHP-FPM 进程被杀、Nginx 502，甚至整机卡死。实际值取决于应用类型和服务器总内存。
- WordPress / ThinkPHP / Laravel 普通站点：256M–512M 足够，大图站或插件多的 WordPress 可试 768M
- 运行 Composer install 或 php artisan migrate：临时提至 1G，用完立刻调回（CLI 独立配置）
- 1G 内存的轻量服务器：不建议超过 256M，否则并发稍高就 swap 爆满
- 注意单位大小写：
512M合法，512m会被当成 512 字节（PHP 解析失败，退为默认值）
如何确认当前生效的 memory_limit？
别信宝塔界面上显示的“已设置”，得看运行时真实值。最直接方式是建一个 info.php 放到网站根目录：
<?php echo ini_get('memory_limit'); ?>
或者命令行查 CLI 模式：
/www/server/php/80/bin/php -r "echo ini_get('memory_limit');"
常见陷阱：
-
ini_get()返回-1表示无限制，但不等于安全——Linux 内核仍会按可用内存做硬限制 - 某些框架（如 Laravel）在启动时主动调用
ini_set('memory_limit', '...')，会覆盖 php.ini 设置，此时需查框架启动文件 - 宝塔「PHP 扩展」页勾选的「OPcache」若开启，其共享内存（
opcache.memory_consumption）不计入memory_limit，但占物理内存
调高后依然内存溢出？该查什么
memory_limit 只是闸门，不是病因。调高后还崩，说明存在内存泄漏或低效代码。
- 用
memory_get_usage(true)在关键函数前后打点，定位哪段逻辑突增内存 - 检查是否循环中未 unset 大数组、未关闭 PDOStatement、未释放 GD 图像资源（
imagedestroy()） - Composer 加载器（ClassLoader）在开发环境可能因自动加载规则过宽导致全量扫描，可执行
composer dump-autoload --optimize - 宝塔自带的「性能监控」能看 PHP-FPM 进程 RSS 内存，若单个进程长期 >1G，基本可判定是脚本问题而非配置不足
真正难调的从来不是数字，而是某个 foreach 里忘了 unset 的 $result，或是日志里静默吞掉的异常导致连接未释放。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
