PHP 8.3接口参数验证失败主因是类型强制转换变更、动态属性限制收紧及旧校验函数失效；需通过error_log+var_dump对比输入源，用filter_var/is_string显式校验，补全类型声明并检查动态属性报错。
PHP 8.3 网站接口参数验证失败时，常表现为返回空响应、400错误、字段缺失或校验逻辑静默跳过，根本原因多是类型强制转换行为变更、动态属性限制收紧、或旧校验函数在严格模式下失效，不能只靠var_dump看值就断定参数“传进来了”。
确认请求数据真实到达PHP层
在接口入口第一行插入：error_log("RAW: " . file_get_contents('php://input'), 3, '/tmp/php-input.log'); → 同时执行 var_dump($_GET, $_POST, $_REQUEST); → 对比三者内容是否一致。
若 $_POST 为空但 php://input 有JSON内容，说明前端发送的是 application/json，不能依赖 $_POST 取值；若三者全空，检查Nginx/Apache是否拦截了非表单类型的请求体（如未配置 client_max_body_size 或缺少 fastcgi_param PHP_VALUE "always_populate_raw_post_data=-1";）。
检查PHP 8.3对基础校验函数的兼容性
方法一：用 filter_var() 替代手写正则校验邮箱/URL
立即学习“PHP免费学习笔记（深入）”；
filter_var($email, FILTER_VALIDATE_EMAIL) 在PHP 8.3中仍可靠；但自定义正则如 preg_match('/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i', $email) 若未加 === 1 判断返回值，可能把 false 当 true 处理——PHP 8.3对隐式类型转换更敏感，if (preg_match(...)) 在匹配失败时返回 false，而 false == 0 成立，但 false === 0 不成立。
方法二：用 is_string() 【必须显式判断，不能省略】 替代 isset() 做类型兜底
isset($_POST['name']) 只确认键存在且非null，但若前端传了数字 123，$_POST['name'] 是 int 类型，is_string($_POST['name']) 直接返回 false —— PHP 8.3默认不自动转字符串，旧代码里“先isset再直接拼SQL”会出致命漏洞。
定位DI容器对无类型参数的反射异常
第一步：在控制器中添加临时测试动作
public function actionDebug($id, string $name) { return ['id_type' => gettype($id), 'id_value' => $id, 'name' => $name]; }
第二步：用curl访问 curl "http://localhost/index.php?r=site/debug&id=abc&name=test"
第三步：观察返回。若报 Fatal error: Uncaught TypeError: Argument 1 passed to ... must be of the type int|string, null given，说明框架DI容器在PHP 8.3下无法跳过无类型提示参数的校验 —— 此时必须为 $id 补上 mixed 类型声明，或降级到支持该行为的框架版本（如Yii 2.0.51+）。
注意：此错误不会出现在日志里，而是直接中断响应，导致前端收不到任何JSON，仅看到空白或500。
验证动态属性赋值是否被拦截
新建测试文件 test-dynamic.php 放入Web根目录：
<?php $obj = new stdClass(); $obj->mobile = '13800138000'; echo 'OK'; ?>
浏览器访问该文件。若页面报 Fatal error: Uncaught ValueError: Creation of dynamic property stdClass::$mobile is not allowed，说明PHP 8.3已启用严格动态属性管控 —— 所有使用 $model->xxx = $val 赋值的模型类，必须提前声明属性，或在类顶部加 #[AllowDynamicProperties] 特性。
这会导致接口中常见的“组装返回数组”逻辑崩溃，例如 $data = new \stdClass(); $data->code = 200; 直接中断执行。
