应修改 phpenv\versions\{版本号}\etc\php\php.ini 文件，该路径下配置文件才是 php-fpm 或 cli 实际读取的运行时配置，而非 phpenv\root\php\php.ini 模板文件。
phpEnv里改max_input_vars要动哪个配置文件
不是改php.ini主文件，而是改 phpEnv 自带的「运行时覆盖配置」——它默认把max_input_vars锁死在 1000，哪怕你改了全局php.ini也没用。
实际生效的是：phpEnv\versions\{版本号}\etc\php\php.ini（比如 phpEnv\versions\8.1.27\etc\php\php.ini），这个路径下的文件才是 phpEnv 启动 PHP-FPM 或 CLI 时真正读取的配置。
- 别去改
phpEnv\root\php\php.ini，那是模板，不参与运行 - 如果用的是 Apache 模式，还要确认
httpd.conf里加载的是对应版本的libphp.so，否则改了也白改 - 改完必须重启服务：右键托盘图标 →「Restart All」，只重启 Apache/Nginx 不够，PHP-FPM 进程得重载
为什么改了max_input_vars还是报错
常见原因是表单字段超限但错误没打在页面上，而是静默截断，导致逻辑出错（比如 POST 数组少了一半键值）。更隐蔽的是：某些框架（如 Laravel）会提前校验并抛出413 Request Entity Too Large，这其实是 Nginx/Apache 层的限制，和max_input_vars无关。
-
max_input_vars控制的是 PHP 解析 POST/GET/COOKIE 时最多接受多少个变量，不是数据大小 - 如果表单含大量复选框、动态字段或嵌套数组（如
items[0][name]、items[0][price]），每个键都算一个变量，很容易突破默认 1000 - 检查是否同时触发了
post_max_size或memory_limit—— 它们会比max_input_vars更早拦截请求
怎么验证max_input_vars已生效
别信 phpinfo() 页面里显示的值，phpEnv 的 phpinfo() 有时缓存旧配置。最可靠的方式是直接测行为：
<?php var_dump(ini_get('max_input_vars'));
// 输出应为 5000（如果你设成了这个值）
?>
再写个简单测试页，提交 1500 个隐藏字段，看是否还能完整收到：
- 如果输出是 1500，说明改成功了
- 如果卡在 1000，说明配置没 reload，或者被其他 ini 文件覆盖（比如 .user.ini）
- 注意：CLI 模式下该值无效，只对 Web SAPI 生效
Windows 下 phpEnv 修改后不生效的典型坑
phpEnv 在 Windows 上常因权限和路径问题导致配置未加载。重点排查这三点：
- 用记事本保存
php.ini后可能变成 ANSI 编码，必须用 UTF-8 无 BOM 保存（推荐 VS Code 或 Notepad++） - 确认你修改的是当前启用版本的配置，右键托盘图标 →「PHP Version」看清楚勾选的是哪个，别改错目录
- 某些杀毒软件（尤其是 360、腾讯电脑管家）会拦截 phpEnv 对 ini 文件的读写，临时关闭试试
复杂点在于：phpEnv 把 PHP 配置拆成多层（全局模板 + 版本专属 + 运行时覆盖），而max_input_vars这种安全敏感项默认被硬编码进启动参数里，所以光改 ini 不够，还得确认没有在 php-fpm.conf 或启动脚本里用 -d max_input_vars=1000 强制覆盖。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
