phpEnv中修改memory_limit必须直接编辑其自带的php.ini文件（如C:\phpenv\php\php.ini），将memory_limit设为512M或1G（单位大写），保存后通过phpEnv控制面板重启Apache方可生效；.htaccess和ini_set()在该环境下易失效或受限，不推荐作为主要方案。
phpEnv 是个本地开发套件（类似 XAMPP、WAMP），它默认用 Apache + PHP 模块模式运行，但本身不提供独立的“内存治理”配置界面——你得直接改底层 PHP 配置，Apache 本身不管理 PHP 内存。
phpEnv 下改 memory_limit 必须动 php.ini
phpEnv 启动的 Apache 使用的是它自带的 PHP 解释器，所有内存限制由 PHP 控制，不是 Apache。你遇到的 Allowed memory size exhausted 错误，根源永远在 PHP 的 memory_limit，不是 Apache 的 MaxRequestWorkers 或 RLimitMEM（后者在现代 Apache 中基本被忽略）。
- 先确认当前生效的
php.ini：在 phpEnv 的浏览器控制台或本地建一个info.php，写<?php phpinfo(); ?>，查 “Loaded Configuration File” 路径——通常是C:\phpenv\php\php.ini或类似位置 - 用记事本或 VS Code（以管理员身份）打开该
php.ini - 搜索
memory_limit，把它从默认的128M改成512M或1G（注意单位必须是大写M或G，512m或512会被当成 0） - 保存后，**必须点 phpEnv 控制面板里的 “Restart Apache”（不是 reload）**，否则修改不生效
为什么 .htaccess 在 phpEnv 里大概率失效
phpEnv 默认启用的是 Apache + mod_php（不是 PHP-FPM），所以 .htaccess 理论上可用，但实际常踩坑：
- phpEnv 的 Apache 配置可能默认关闭
AllowOverride，导致.htaccess被完全忽略 - 即使开了，
php_value memory_limit 384M这行也要求 Apache 加载了mod_php，且没被disable_functions拦截 - 更麻烦的是：phpEnv 多版本共存时，不同 PHP 版本可能对应不同
.htaccess生效范围，容易配错目录 - 结论：不如直接改
php.ini，一劳永逸，还避免权限和路径歧义
脚本内用 ini_set() 有时根本不起作用
在 phpEnv 环境下，ini_set('memory_limit', '768M') 看似方便，但有硬性前提：
立即学习“PHP免费学习笔记（深入）”；
- 必须放在脚本最开头，
<?php后第一行，任何echo、require、甚至 BOM 字符都会让它失效 - 如果 phpEnv 的
php.ini里设置了disable_functions = ini_set（某些安全加固版会这样），这行代码直接被跳过，连报错都没有 - 更隐蔽的问题：如果脚本已经分配了比如 127MB 内存，再调
ini_set()尝试升到 512M，PHP 可能当场触发 OOM 并崩溃——因为扩容动作本身需要额外内存空间 - 所以调试阶段可临时加，但上线前务必回归
php.ini配置
防止进程崩溃不能只靠调高 memory_limit
单纯把 memory_limit 设成 -1 或 2G，只是掩盖问题。phpEnv 作为本地环境，崩溃往往暴露真实缺陷：
- 循环读大文件？用
fopen+fgets替代file_get_contents - Laravel
artisan migrate崩溃？加--force和php -d memory_limit=1G artisan migrate双保险 - 数据库导出卡死？检查是否启用了
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = false，避免全量加载结果集 - 用
memory_get_peak_usage(true)在关键步骤打点，确认哪段代码吃掉最多内存
真正稳定的 phpEnv，是配置合理 + 代码不滥用内存。改 php.ini 是起点，不是终点。
