调高 memory_limit 能缓解内存耗尽错误，但需优先修改 php.ini（如 memory_limit = 512m），重启服务后验证；.htaccess 和 ini_set() 仅限特定场景辅助使用；根本解决须配合流式处理、资源释放与 xdebug 禁用。
调高 memory_limit 能缓解“Allowed memory size exhausted”错误，但关键不在盲目加码，而在匹配场景、选对方式、避开常见失效陷阱。
优先改 php.ini —— 最稳最通用的方案
所有 PHP 环境（phpEnv、宝塔、XAMPP、CLI）都依赖这个文件生效，它是唯一真正全局可控的入口。
- 先用
<?php phpinfo(); ?>查清“Loaded Configuration File”路径，别凭经验乱改错版本 - 打开对应
php.ini，搜索memory_limit，改成带大写单位的值，例如：memory_limit = 512M（不能写成 512m、512MB 或 512） - 保存后必须重启服务：phpEnv 点「Restart Apache」；宝塔点「重载配置」；CLI 用户需关掉终端再重开
- 生产环境不建议设为
-1，512M 是多数中型项目较安全的起点
按需补充：.htaccess 和 ini_set() 的适用边界
它们不是替代方案，而是特定条件下的辅助手段，用错就等于没设。
-
.htaccess仅在 Apache + mod_php 下有效，且要求服务器开启AllowOverride Options；写法必须是php_value memory_limit 384M（无空格、单位大写） -
ini_set('memory_limit', '512M')必须放在脚本最开头（<?php后第一行），且不能高于 php.ini 中的硬限制；若已禁用ini_set或脚本内存快满时调用，会直接失败 - CLI 场景可用命令行参数覆盖：
php -d memory_limit=1G script.php，适合临时跑批处理
不只是调数字：配合代码优化才治本
把 memory_limit 从 128M 拉到 1G，解决不了循环引用、全量查库、整文件加载这类根本问题。
- 大数据处理改用流式：用
fopen() + fgets()逐行读文件，用yield写生成器，分页查数据库（LIMIT 1000+ 游标） - 及时释放资源：PDO 查询后调
$stmt->closeCursor()，大数组处理完立刻unset($data) - 上线前禁用 xdebug，它会让内存占用翻倍；用
memory_get_peak_usage()定位峰值点，再留 30% 缓冲设限
验证是否真生效：别只信自己改了
改完不验证，等于白干。三步确认：
- 访问
phpinfo()页面，核对memory_limit行显示的值和单位 - 写个测试脚本：
<?php echo ini_get('memory_limit'); ?>，看输出是否匹配 - 运行原报错脚本，观察是否仍崩溃——若还崩，说明不是内存问题，该查算法或扩展冲突了
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
