PHP 8.0+中hex字符串（如"ff"）在算术运算中直接转为0且无警告，必须用ctype_xdigit()校验后调用hexdec()转换，不可依赖(int)、intval()或is_numeric()。
hex2bin() 返回 false 但没报错，后续计算直接崩
PHP 8.0+ 中，hex2bin() 在输入非法时不再静默返回 false，而是抛出 E_WARNING；但更隐蔽的问题是：你若把十六进制字符串（如 "ff"）直接丢进算术上下文（比如 $val + 1），PHP 8.0 不再把它当作数字字符串解析——它会跳过转换、直接当 0 处理，且不报任何 notice。这导致业务逻辑中“看似合法的 hex 字符串”在加减乘除时突然变成 0，却查不到 warning。
- 不是所有 hex 字符串都“数值合法”：只有形如
"123"、"-45.6"这类符合 PHP 数字字符串语法的才被识别；"ff"、"a0b1"属于纯十六进制表示，不是数字字符串 - PHP 7.x 会尝试截取前导数字（如
"ff123"→0），而 PHP 8.0+ 直接拒绝，返回0且不发 warning - 典型场景：从数据库或 API 拿到字段值
"deadbeef"，误以为可直接参与金额计算或 ID 递增
用 is_numeric() 判断 hex 字符串永远返回 false
is_numeric() 对十六进制字符串（哪怕全是数字字符）一律返回 false，因为它只认十进制格式的数字字符串，不支持 0x 前缀，也不识别纯 hex 字符序列。你不能靠它来“兜底校验”。
-
is_numeric("ff")→false -
is_numeric("0xff")→false（PHP 8.0+ 已移除对0x前缀的隐式识别） -
is_numeric("255")→true，但这是十进制，和 hex 无关 - 真正该用的是
ctype_xdigit()配合长度检查，确认是否为有效 hex 字符串
正确解法：先验证再转换，别依赖隐式类型转换
十六进制字符串必须显式转为整数才能安全参与运算。PHP 8.0 要求你主动承担这个责任，不能再指望自动转换。
- 验证：用
ctype_xdigit($str)确保全为 0–9、a–f、A–F，且strlen($str) % 2 === 0（避免hex2bin()报错） - 转整数：用
hexdec($str)，它专为 hex 字符串设计，返回int或float（超大值时），且 PHP 8.0 行为稳定 - 避坑：不要用
(int)$str或intval($str)—— 它们对 hex 字符串一律返回0，无提示 - 示例修复：
$hex = "a0b1";
if (ctype_xdigit($hex) && strlen($hex) % 2 === 0) {
$num = hexdec($hex); // → 41137
$result = $num + 1; // 安全
} else {
throw new InvalidArgumentException("Invalid hex string: $hex");
}
从数据库读 hex 字段时，PDO 默认不帮你转类型
PDO 默认以字符串形式返回 BINARY/HEX 类型字段（如 MySQL 的 HEX(id) 结果），即使你期望它是数字。PHP 8.0 不会自动把它当数字字符串处理，所以 +$row['id_hex'] 得到的是 0。
立即学习“PHP免费学习笔记（深入）”；
- 解决方案一：查询时就用
CONV(HEX(id), 16, 10)或UNHEX()+CAST转成整数 - 解决方案二：PHP 层统一用
hexdec()处理，且加ctype_xdigit()校验 - 切忌设置
PDO::ATTR_STRINGIFY_FETCHES => false期望“自动变数字”——它只影响数字类型字段，对 hex 字符串无效
最常被忽略的点：hex 字符串不是数字字符串，从来都不是。PHP 8.0 只是终于不再替你“猜意图”，而要求你明确写出 hexdec()。任何绕过这一步的隐式操作，都会在上线后某个凌晨悄悄把订单金额变成 0。
