最直接有效的方式是修改 php.ini 中的 memory_limit；默认常为 128M 或 256M，批量处理大文件或数据时易不足，需确认当前值、编辑 php.ini 或 PHP-FPM pool 配置、重启服务并验证，同时警惕内存泄漏与低效代码。
php.ini 里修改 memory_limit 是最直接有效的方式
PHP 脚本执行时超出内存限制会报错 Fatal error: Allowed memory size of XXX bytes exhausted，根本原因通常是 memory_limit 设置过小。这个值默认常为 128M 或 256M，但批量处理图片、解析大 JSON、读取整张 CSV 表时很容易不够用。
修改前先确认当前值：
php -r "echo ini_get('memory_limit');"
修改步骤如下：
- 找到正在使用的
php.ini文件：php --ini输出的 “Loaded Configuration File” 路径 - 编辑该文件，搜索
memory_limit，将其改为需要的值，例如：memory_limit = 512M - 保存后重启 Web 服务器（
apache2或php-fpm），否则修改不生效 - 验证是否生效：
php -r "var_dump(ini_get('memory_limit'));"
运行时用 ini_set() 临时调整只对当前脚本有效
某些场景下（比如共享主机无法改 php.ini，或只想给某个耗内存任务提限），可用 ini_set('memory_limit', '512M') 动态设置。但它必须在脚本开头尽早调用，且不能高于 php.ini 中设定的 memory_limit 上限（如果该上限被设为 -1 则无限制）。
立即学习“PHP免费学习笔记（深入）”；
注意以下几点：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
ini_set()在safe_mode开启时无效（PHP 5.4+ 已移除，基本不用考虑） - CLI 模式下可用，但 Web 模式下受服务器配置影响（如某些 Nginx + PHP-FPM 组合会忽略它）
- 若已触发内存耗尽错误，
ini_set()就来不及执行了 —— 它不是“兜底机制”，而是“提前申请”
PHP-FPM 场景下需检查 pool 配置里的 php_admin_value[memory_limit]
用 PHP-FPM 时，即使改了全局 php.ini，也可能被 pool 级配置覆盖。检查 /etc/php/*/fpm/pool.d/www.conf（路径依版本而异）中是否存在类似行：
php_admin_value[memory_limit] = 128M
这类配置优先级高于 php.ini，且 php_admin_value 不允许运行时用 ini_set() 修改。如果存在，必须手动改这里并重启 php-fpm。
常见误操作：
- 只改了
php.ini却忘了 pool 配置，导致修改无效 - 把
php_admin_value错写成php_value，后者可被ini_set()覆盖，安全性低，生产环境不推荐 - 重启了 Apache 却没重启
php-fpm，配置依然不生效
内存限制不是万能解药，要警惕隐性泄漏和低效写法
把 memory_limit 从 128M 改到 2G 并不能解决所有问题。很多“内存爆掉”的真实原因是代码缺陷：
- 循环中不断
$arr[] = $item累积大量数据却未分批处理 - 使用
file_get_contents()读取几百 MB 的文件，而不是fopen()+ 流式读取 - ORM 查询未加
->chunk()或->cursor()，一次性加载全部结果集 - 递归调用过深或闭包引用未释放，导致 GC 无法回收
真正需要关注的，是哪段代码占了最多内存 —— 可用 memory_get_usage(true) 和 xdebug 的 trace 功能定位，而不是无脑调高限制。
