phpenv管理的php.ini位于当前激活版本目录下，如~/.phpenv/versions/8.1.26/etc/php.ini；需用php --ini确认路径，并同步修改upload_max_filesize和post_max_size，且重启对应服务。
phpenv 下的 php.ini 在哪找
phpenv 管理的 PHP 版本，其 php.ini 文件**不在全局 /etc/ 或 /usr/local/etc/**，而是按版本隔离在 phpenv 的 shims 目录下。你必须先确认当前 shell 使用的是哪个 PHP 版本：php -v，再用 php --ini 查看 “Loaded Configuration File” 路径——它通常长这样：/Users/xxx/.phpenv/versions/8.1.26/etc/php.ini（macOS）或 /home/xxx/.phpenv/versions/8.2.10/etc/php.ini（Linux）。别改错版本，phpenv 可能同时装了 7.4、8.1、8.2，改了 8.1 的配置但 php -v 显示的是 8.2，那就白忙。
只改 upload_max_filesize 会失败
必须同步改两个值，且满足大小关系：
-
upload_max_filesize = 128M（单个文件上限） -
post_max_size = 136M（整个 POST 请求体总大小，含所有字段+文件，必须 ≥ upload_max_filesize） - 单位只能是
M或K，写成128MB或128都无效，PHP 解析为 0 - 别设
0或unlimited，PHP 不支持，配置会加载失败
改完不重启没用：phpenv 本身不托管服务进程，但如果你用的是 php -S 内置服务器，得手动 Ctrl+C 停掉再重起；如果跑在 Nginx/Apache 下，还得顺带检查并重启对应 Web 服务。
Nginx 或 Apache 还会拦一次
即使 php.ini 改对了，Web 服务器层可能先截断请求：
立即学习“PHP免费学习笔记（深入）”；
- Nginx 用户必须检查
client_max_body_size，它得 ≥post_max_size，例如加在server块里：client_max_body_size 136M; - Apache 用户若启用了
mod_php，可临时用.htaccess覆盖：php_value upload_max_filesize 128M和php_value post_max_size 136M；但若用 PHP-FPM，.htaccess无效，只能靠 php-fpm.conf 的php_admin_value或直接改php.ini - Docker 环境下，
php.ini可能被 volume 挂载覆盖，或被php-fpm.conf中的php_admin_value upload_max_filesize强制锁定，优先级更高
验证是否真生效
别信“改完就 OK”，很多问题出在验证方式错：
- 用
php --ini确认路径对不对，再用php -i | grep -E 'upload_max_filesize|post_max_size'看输出值 - 别只跑
phpinfo()页面——如果该页面不是用当前 CLI 版本执行的（比如浏览器访问的是 Apache 模块下的 PHP），看到的可能是另一个配置 - 上传测试时，观察 HTTP 状态码：
413 Request Entity Too Large是 Nginx 拦的；500或静默失败，大概率是post_max_size < upload_max_filesize或内存不足 - 记得检查
memory_limit，它至少要比post_max_size大 1.5 倍，否则大文件一进内存就崩
最常被跳过的动作：改完 php.ini 后忘记重启 php -S 或对应的 Web 服务进程，或者压根没确认当前生效的是哪个 php.ini —— 这俩点卡住的人最多。
