先用memory_get_usage(true)和memory_get_peak_usage(true)在关键位置打点确认是否真溢出，再排查var_dump调试、xdebug启用、超时误判等假性问题；若峰值逼近memory_limit且错误明确指向file_get_contents()等函数，才是真溢出。
怎么确认是真内存溢出，不是误判？
别一见 Allowed memory size of XXX bytes exhausted 就改配置。先用 memory_get_usage(true) 和 memory_get_peak_usage(true) 在关键位置打点：数据库查询后、大数组生成前、循环体内外、JSON解析前后。如果峰值只比 memory_limit 低几十MB，且错误堆栈明确指向某行（比如 file_get_contents() 或 json_decode()），那才是真溢出。
常见假性溢出包括：
-
var_dump($huge_data)没删，调试完就忘——删掉立刻恢复 - 脚本卡住几秒后报错，其实是
max_execution_time超时被 PHP 错误归类为 OOM - 启用了
xdebug.mode=debug，单步调试本身吃内存；关掉再试：php -d zend_extension= -f script.php -
get_included_files()返回上百个路径，说明自动加载失控或重复require
CLI 和 Web 下改 memory_limit 的生效优先级
改错地方等于白改。CLI 最可靠方式是启动时加参数：php -d memory_limit=1G script.php，不依赖任何配置文件，也不需重启服务。
Web 环境优先级固定为：php.ini → .user.ini（需 user_ini.filename 启用）→ .htaccess（仅 Apache mod_php 有效）→ ini_set()（仅对后续内存分配生效）。
注意：ini_set('memory_limit', '512M') 必须放在脚本最开头，且不能晚于第一个可能触发分配的操作（比如 new PDO() 或 file_get_contents()）。
PHP-FPM 环境下必须用 php_admin_value[memory_limit]
在 Nginx + PHP-FPM 架构中，ini_set() 和 .htaccess 全部失效。必须编辑 FPM 池配置，例如 /etc/php/8.1/fpm/pool.d/www.conf，添加：
php_admin_value[memory_limit] = 512M
然后重启服务：sudo systemctl restart php8.1-fpm。这里不能用 php_value，否则会报错 Unknown entry type；也不能写成 php_flag，因为 memory_limit 是值型指令，不是布尔开关。
多个站点需要不同限制？建独立 pool，每个 pool 单独配 php_admin_value[memory_limit]，避免互相干扰。
调大 memory_limit 后仍持续增长，问题在哪？
直接设 memory_limit = -1 或 2G 只能绕过报错，无法阻止内存持续上涨。真正吃内存的通常是：
- 数据库查百万行用
fetchAll()全量加载——改用fetch()迭代处理 - 大文件用
file_get_contents()一次性读入——换fopen() + fgets()流式读取 - JSON 解析超大响应体——加
JSON_INVALID_UTF8_IGNORE参数减少校验开销，或换json_decode_stream类库 - 对象间存在循环引用（如 ORM 中父子关系未设
__sleep或未用WeakReference）——手动unset()或用gc_collect_cycles()强制回收
最易被忽略的是：memory_limit 调高后，脚本没报错但变慢了，其实是 GC 压力剧增导致 CPU 飙升。这时候要查 memory_get_peak_usage() 是否稳定，而不是只盯着不崩溃。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
