phpenv 不管理 php 内存限制，需手动修改对应环境的 php.ini 中 memory_limit = 1g（单位大写），并重启 web 服务；cli 无需重启，但须验证实际生效值，同时排查 xdebug、fpm 覆盖、扩展占用等干扰项。
phpEnv 本身不管理 PHP 内存限制，它只是 PHP 版本切换工具；真正要改的是你当前正在用的那个 PHP 版本的 php.ini 文件。
确认你实际在用哪个 php.ini
phpEnv 切换版本后，CLI 和 Web 环境仍可能加载不同配置。先搞清你在调哪个环境：
- 终端里运行
php --ini→ 查 CLI 加载的php.ini路径（比如/home/username/.phpenv/versions/8.2.12/etc/php.ini） - Web 请求中访问
<?php phpinfo(); ?>→ 找 “Loaded Configuration File” 行，看 Web SAPI（如 FPM 或 Apache 模块）用的是哪个文件 - 两者路径通常不同，
memory_limit必须分别检查、分别修改
修改对应 php.ini 的 memory_limit = 1G
找到正确的 php.ini 后，编辑它：
- 搜索
memory_limit，把原值（如128M或512M）改成memory_limit = 1G - 单位必须是大写
G（1g或1000M会被 PHP 解析为 0，导致实际限制失效） - 保存后：CLI 环境无需重启；Web 环境需重启对应服务（如
php-fpm或nginx） - 验证是否生效：
php -r "echo ini_get('memory_limit');"应输出1073741824或1G
为什么改了 php.ini 还报 Allowed memory size exhausted
常见干扰项比配置错误更常出现：
- Xdebug 开着：它会让内存占用翻倍以上，临时关掉再试（
phpenv config-rm xdebug.ini或注释掉zend_extension=xdebug.so） - Composer 或 Artisan 命令被 phpEnv 封装过：某些 phpEnv 插件会强制重置
memory_limit，直接绕过它用原生命令：~/.phpenv/versions/8.2.12/bin/php -d memory_limit=1G composer install - 脚本里早期就触发了 OOM：比如
require了某个大框架 autoload 文件后才调ini_set()，这时已来不及 ——ini_set()必须放在第一行，且不能依赖任何外部逻辑 - PHP-FPM 池配置覆盖了 php.ini：
php_admin_value[memory_limit]在www.conf里优先级更高，得同步检查
大内存应用别只靠调高 limit
设成 1G 是快捷解法，但掩盖不了代码问题：
- 用
memory_get_peak_usage(true)在关键节点打点，确认是不是真需要 1G，还是某处循环没 break、数组没 unset - 流式处理代替
file_get_contents()，用PDO::FETCH_ASSOC+while ($row = $stmt->fetch())替代fetchAll() - OPcache 开启且配置合理（
opcache.memory_consumption=256），能显著降低重复脚本解析开销 - phpEnv 切换版本时，记得检查新版本是否默认启用了更多扩展（如
intl、gd），它们也会悄悄吃内存
最易忽略的一点：phpEnv 切换版本后，php --ini 显示的路径可能指向一个“干净模板”，而你实际运行时加载的是另一个被项目脚本或 shell hook 动过手脚的 php.ini。务必用 php -r 直接读值验证，别只信路径。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
