PHP超全局变量值恒为字符串，须依来源选择filter_var等安全转换方式，JSON请求需手动解析，转换后仍需业务校验与参数绑定。

PHP 接收的参数类型不对，不是靠“强制转换”就能一劳永逸解决的——关键得先确认来源、再决定转换策略，否则可能掩盖逻辑错误或引发安全问题。

$_GET、$_POST 里的值永远是字符串

无论前端传的是数字、布尔还是空数组，$_GET['id'] 和 $_POST['limit'] 拿到的都是字符串。比如传了 id=123，实际值是 "123"，不是整数 123；传了 active=false，拿到的是字符串 "false"，不是布尔 false。

常见错误现象：

• 用 === 判断 $_GET['page'] === 1 永远为 false
• if ($_POST['enabled']) 对 "0" 或 "false" 误判为真（因为非空字符串在 PHP 中为真）
• 传入数据库查询时，WHERE id = ? 绑定字符串 "123" 虽然能查出结果，但若字段是 INT，MySQL 可能无法走索引（尤其在严格模式下）

用 (int)、(bool)、filter_var() 还是 settype()？

直接类型转换符号（如 (int)）最常用，但有陷阱；filter_var() 更安全，适合验证+转换一体；settype() 会修改原变量，一般不推荐用于超全局数组。

实操建议：

• 转整数：优先用 filter_var($_GET['id'], FILTER_VALIDATE_INT)，失败返回 false，可配合默认值和范围检查
• 转布尔：别用 (bool)——"0"、"false"、"off" 都会变成 true；改用 filter_var($_POST['publish'], FILTER_VALIDATE_BOOLEAN)，它识别 "1"/"true"/"on" 为 true，"0"/"false"/"off"/"no" 为 false
• 转浮点：filter_var($_GET['price'], FILTER_VALIDATE_FLOAT) 比 (float) 更可靠，能拒绝 "12.34abc" 这类脏数据
• 避免直接 (int)"12.9" → 得到 12（截断），而 intval("12.9", 10) 行为相同，但语义更清晰

JSON 请求体（application/json）要先 json_decode()

当前端用 fetch() 或 axios 发送 JSON 数据时，$_POST 是空的——PHP 不自动解析 JSON 请求体。必须手动读取原始输入并解码。

实操步骤：

• 检查 $_SERVER['CONTENT_TYPE'] 是否含 "application/json"
• 用 $raw = file_get_contents('php://input') 获取原始 body
• 用 $data = json_decode($raw, true) 解析成关联数组
• 此时 $data['count'] 才可能是整数或布尔，而非字符串

示例：

$raw = file_get_contents('php://input');
if (!empty($raw)) {
    $json = json_decode($raw, true);
    if (json_last_error() !== JSON_ERROR_NONE) {
        http_response_code(400);
        exit('Invalid JSON');
    }
    $id = filter_var($json['id'] ?? null, FILTER_VALIDATE_INT);
}

别跳过验证，转换 ≠ 安全

类型转换只是第一步，不能替代业务校验。比如把 $_GET['page'] 强转成 int，不代表它就合法——还可能为负数、超出分页范围、或被用于 SQL 注入（如果拼接进查询）。

容易被忽略的地方：

• filter_var() 默认不处理 null 或缺失键，记得用 ?? 提供默认或显式判断键是否存在
• 数据库写入前，仍需用 PDO 参数绑定或 filter_var() 二次确认，不能只信“我已经转过了”
• API 返回给前端的数据，也要注意类型一致性——PHP 数组里 0 和 "0" 在 JSON 中序列化结果不同（前者是数字，后者是字符串）