PHP 8.3配置变严格，assert.*等断言配置已废弃，max_input_vars默认1000，disable_functions含chmod会导致WordPress更新失败；必须分别用php -i和phpinfo()确认CLI与Web实际加载的php.ini路径，且修改后需重启对应服务（如php8.3-fpm）。
PHP 8.3 的配置要求变严格了，不是“配错了”，而是很多旧配置现在会直接失效或报错——比如 assert.active 已废弃、max_input_vars 被默认限制为 1000、disable_functions 里留着 chmod 就会让 WordPress 更新失败。排查必须从「谁在读配置」和「哪层配置生效」切入，不能只改一个文件就以为完事。
确认当前生效的 php.ini 路径和加载顺序
命令行和 Web 请求用的可能是两套配置，php -i | grep "Loaded Configuration File" 和 Web 页面里的 phpinfo() 必须分别查，二者路径不同是常态。
- 若
php -i显示/etc/php/8.3/cli/php.ini，而phpinfo()显示/etc/php/8.3/fpm/php.ini，说明 CLI 和 FPM 各自独立配置，改错地方就白忙 - Apache 模块模式下，
phpinfo()中的Additional .ini files parsed列表才是最终生效项，/etc/php/8.3/mods-available/下的 ini 文件是否被 symlink 到enabled目录里，决定扩展是否加载 - 使用 Docker 或 MAMP/XAMPP 时，
php.ini往往在容器内或应用私有目录（如/Applications/MAMP/bin/php/php8.3.13/conf/php.ini），系统级路径无效
检查被 PHP 8.3 明确废弃或行为变更的配置项
PHP 8.3 移除了整批断言相关配置，且对 error_reporting 和 disable_functions 的校验更硬性——写进去但不生效，也不会警告，只会静默跳过。
-
assert.active、assert.bail、assert.warning、assert.callback、assert.exception全部废弃，出现在php.ini中会被忽略；应改用zend.assertions = -1（禁用）或1（启用）替代 -
max_input_vars默认值仍为 1000，WordPress 后台保存失败时，错误提示明确指向它；但必须在对应 SAPI 的 ini 文件中改（CLI 不影响 Web） -
disable_functions若含chmod、file_put_contents等函数，WordPress 插件更新会直接报Fatal error: Uncaught Error: Call to undefined function chmod()；需编辑php.ini删除该函数名，重启 FPM 或 Apache
验证配置是否真被读取且无语法错误
PHP 8.3 对 ini 文件语法更敏感，空格、分号、未闭合引号会导致整段配置失效，但不会报错，只默默跳过。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php --ini确认加载路径，再用php -c /path/to/php.ini -m测试该配置下能否列出扩展——如果扩展没出现，说明 ini 有语法问题或路径不对 - 检查
disable_functions是否有多余空格：disable_functions = exec , system中的空格会让 PHP 解析失败，应写成disable_functions = exec,system - 修改后必须重启对应服务：CLI 不需要重启，但 FPM 需
sudo systemctl restart php8.3-fpm，Apache 需sudo systemctl restart apache2
区分环境层级：命令行 / Web / Composer / Docker 各自的 PHP 版本和配置
你以为改了全局配置，其实只有某一层能感知到。比如 Composer 报 “requires PHP ^8.3” 却提示版本是 7.4，根本不是配置问题，而是 Composer 启动时调用的 php 命令路径不对。
- 执行
which php和composer diagnose对比 PHP 路径，不一致就用php8.3 /path/to/composer.phar install强制指定解释器 - Docker 中，
FROM php:8.3-cli是镜像基础，但构建时若用了缓存，RUN docker-php-ext-install可能没执行；进容器后运行php -m | grep pdo_mysql才算真实验证 - Windows 上用 phpEnv（大写 E）图形工具时，其内置的 Apache/Nginx 用的是私有
php.ini，改系统 PATH 下的 ini 文件完全无效
最常被忽略的是：PHP 8.3 的配置生效依赖于「SAPI 类型 + 加载时机 + ini 文件位置」三重匹配。改完一个文件，不验证实际加载路径、不重启对应服务、不区分 CLI/FPM/Web 场景，90% 的“配置异常”其实根本没生效。
