最稳做法是修改PHP实际加载的php.ini文件并重启Apache；需用phpinfo()确认“Loaded Configuration File”路径，再编辑memory_limit等参数，否则修改无效。
直接改 php.ini 是最稳、最推荐的做法，但必须重启 Apache 才生效；临时加 ini_set() 看似方便，却常因位置不对、被禁用或已超限而失效。
怎么找到并修改 XAMPP 里真正生效的 php.ini
很多人改了错的 php.ini 文件，结果重启 Apache 后 memory_limit 还是老样子。关键不是“哪个文件夹里有 php.ini”，而是“PHP 实际加载的是哪一个”。
- 新建一个
info.php文件，内容只有一行：<?php phpinfo(); ?> - 把文件放到
htdocs目录下，浏览器访问http://localhost/info.php - 搜索 “Loaded Configuration File”，它显示的路径才是当前 Web 模式下 PHP 真正读取的
php.ini - 这个路径通常是
C:\xampp\php\php.ini（Windows）或/opt/lampp/etc/php.ini（Linux），但不能假设，必须查证
找到后，用记事本或 VS Code 打开，搜索 memory_limit =，把它改成你需要的值，比如：memory_limit = 512M。别漏掉单位 M，写成 512 或 512mb 都无效。
ini_set('memory_limit', ...) 为什么有时不生效
这个函数在脚本里写，看起来最灵活，但限制极多——不是所有环境都允许它起作用。
立即学习“PHP免费学习笔记（深入）”；
- 必须放在脚本最开头，任何
echo、header()、HTML 输出之前，否则报错或静默失败 - 如果
php.ini里设置了disable_functions = ini_set，那这行代码直接被忽略 - 如果脚本运行到这一行时，内存已经快耗尽（比如前面加载了大数组），
ini_set()自身申请内存失败，也会崩 - CLI 模式下可用，但 Web 模式下受 SAPI 类型影响：Apache mod_php 支持，PHP-FPM 默认禁用该函数修改
memory_limit
所以，别指望靠它“兜底”。它适合你明确知道只跑一次、且能控制入口的脚本，比如导出报表的 CLI 命令，而不是整个网站。
修改后 Apache 不重启，设置就白改
XAMPP 的 Apache 启动时会把 php.ini 加载进内存，之后所有请求都复用这个配置。改完文件不重启，等于没改。
- 在 XAMPP 控制面板里，先点
StopApache，再点Start—— 不要只点Restart，偶尔卡住不会真正重载配置 - 改完后，立刻用
info.php刷新页面，确认 “memory_limit” 行显示的是你新设的值 - 如果还是旧值，说明你改错了文件，或者 Apache 没真正重启成功（检查控制面板里 Apache 状态是否为绿色 Running）
另外注意：XAMPP 的 CLI（命令行）和 Web 模式可能用不同的 php.ini。用 php -i | grep "Loaded Configuration" 查 CLI 加载的是哪个，别和 Web 的搞混。
设太高反而容易出问题
把 memory_limit 设成 -1 或 2G 并不等于“更安全”，它只是把崩溃时机往后推，掩盖了真正的内存泄漏或低效逻辑。
- 如果脚本反复
array_merge()大数组、或PDO::fetchAll()读取上万行数据，内存迟早爆，只是时间问题 - Windows 下 PHP 进程单个实例通常撑不过 2GB（32 位模式），设太高反而触发系统级 OOM 终止
- 建议先用
memory_get_peak_usage(true)在关键步骤打点，确认哪段代码吃内存最多，再针对性优化，比如改用流式读取或分页查询
真正难的从来不是调高数字，而是定位那个悄悄涨上去、最后压垮进程的变量引用。
