PHP 8.0+ 中 is_scalar(null) 返回 true，而 PHP 7.x 返回 false；需用 is_scalar($v) && $v !== null 确保排除 null 的标量判断。
PHP 怎么判断一个变量是不是标量
直接用 is_scalar() ——但它在 PHP 8.0+ 里行为变了，老代码可能突然出问题。
这个函数本意是检查变量是否为 string、int、float、bool、null 以外的“原始值”，但注意：null 在 PHP 7.x 返回 false，到了 PHP 8.0+ 却返回 true。这不是 bug，是官方把定义改了（null 被纳入标量范畴）。如果你的项目横跨多个 PHP 版本，光靠它会误判。
- PHP 7.4 及更早：
is_scalar(null)→false - PHP 8.0+：
is_scalar(null)→true - 如果业务逻辑里明确要排除
null（比如参数非空校验），就不能只信is_scalar()
想排除 null，又确认是标量，该怎么写
组合判断最稳：先确认是标量，再单独排除 null。别试图用 filter_var($v, FILTER_VALIDATE_SCALAR) ——这函数根本不存在，是常见误解。
推荐写法：
立即学习“PHP免费学习笔记（深入）”；
if (is_scalar($v) && !is_null($v)) {
// $v 是 string/int/float/bool 之一
}
或者封装成小工具函数，避免重复写：
function is_non_null_scalar($v) {
return is_scalar($v) && $v !== null;
}
-
is_scalar()对 resource、array、object、callable 都返回false，没问题 -
$v !== null比!is_null($v)略快，且类型严格，不会被0、''干扰 - 不要用
isset($v)替代$v !== null，因为isset()对0、false、''都返回false，会误杀合法标量
为什么不用 gettype() 或 var_dump() 做判断
gettype() 返回字符串，看似灵活，但容易漏 case：比如你写 in_array(gettype($v), ['string', 'integer', 'double', 'boolean'])，就漏掉了 NULL（PHP 8+ 下该算标量）和 double 在某些系统里叫 float 的兼容性问题。
更麻烦的是性能：每次调用 gettype() 都触发类型探测，比原生类型检查慢一截；而 is_scalar() 是语言内建，C 层直接判断，无额外开销。
-
var_dump()/print_r()是调试用的，不能用于逻辑分支判断 - 有人用正则匹配
var_export()结果来“识别类型”，属于高风险操作，绝对不要在生产逻辑里这么干 -
gettype()对未定义变量会报 Notice，而is_scalar()安全接受未定义变量（返回false）
实际用在哪种场景下最容易翻车
接口参数校验、配置项类型断言、序列化前预处理 —— 这些地方一旦标量判断出错，后续 json_encode() 可能静默丢数据，或 printf() 报 warning。
典型翻车点：
- 从
$_GET拿到的值默认是 string，但前端传了?id=（空值），$_GET['id']是''，is_scalar('')是true，但业务可能期望它是 int - 数据库查出来字段为 NULL，PDO 默认映射为
null，PHP 8+ 下is_scalar()放行，但下游函数如strlen(null)会告警 - 用
is_scalar()判断后直接拼 SQL，没做intval()或mysqli_real_escape_string()，有注入风险
标量只是“类型安全”的第一层，不是“业务安全”的终点。值的内容、范围、上下文语义，都得另外验证。
