php中十六进制整型字面量以0x开头，如0xff→255；字符串需hexdec()转换，不可直接运算；超大数用gmp；输出推荐dechex()或sprintf()按需选择。
PHP 里怎么写十六进制整型字面量
直接用 0x 开头，后面跟十六进制数字（0-9、a-f 或 A-F），PHP 解析时自动转成十进制整数存进变量。
常见错误是漏掉 0x 前缀，比如写成 $n = abcd; 或 $n = "abcd"; —— 前者报 Parse error: syntax error，后者存的是字符串，不是数。
-
$n = 0xff;→ 十进制255 -
$n = 0x1A;→ 十进制26 -
$n = 0XDEAD;→ 大小写不敏感，0X也行 - 不能带空格：
0x ff是语法错误
hexdec() 和 base_convert() 的区别在哪
hexdec() 专用于把十六进制字符串转十进制整数，快、准、只认 0-9a-f（忽略前导空格和 0x 前缀）；base_convert() 是通用进制转换函数，但返回的是字符串，且在大数时可能丢失精度。
比如处理 "1000000000000000" 这种长十六进制串：hexdec() 可能溢出变 INF（取决于平台整型位宽），而 base_convert() 虽然不报错，但返回的字符串结果在后续数学运算中容易出错。
立即学习“PHP免费学习笔记（深入）”；
- 优先用
hexdec("ff")→ 返回int(255) - 别用
base_convert("ff", 16, 10)→ 返回"255"（字符串） -
hexdec()不接受0x前缀字符串，hexdec("0xff")会截断为0 - 超大值（如 64 位以上）建议用
gmp_init($hex, 16)配合gmp_strval()
为什么 var_dump(0x100) 显示 int(256)，但 echo "0x100" 输出字符串
因为 0x100 是整数字面量，PHP 编译期就完成了进制解析；而 "0x100" 是字符串，引号包住的内容完全按字面意思存，不会触发任何进制转换逻辑。
这个混淆点常出现在从数据库或 HTTP 请求拿到的十六进制数据上：它们几乎总是字符串格式，不能直接参与算术运算。
-
0x100 + 1→257（合法） -
"0x100" + 1→ PHP 会尝试类型转换，把"0x100"当作0（因开头不是数字），结果是1 - 从 $_GET 拿到的
$_GET['color'] = "ff0000"，必须用hexdec($_GET['color'])才能得到正确整数 - 用
filter_input(INPUT_GET, 'color', FILTER_SANITIZE_STRING)后仍需手动 hexdec，过滤器不改数值含义
十六进制输出时 sprintf("%x") 和 dechex() 哪个更稳
dechex() 更直接，输入整数，输出小写十六进制字符串；sprintf("%x") 功能更强（支持补零、大小写控制），但参数类型更敏感——传非整数可能静默转成 0 或触发警告。
例如 sprintf("%x", "255") 在某些 PHP 版本里会返回 "0"（字符串转整失败），而 dechex("255") 会先强制类型转换，结果是 "ff"，行为更可预期。
- 简单转小写：用
dechex(255)→"ff" - 需要补零（如颜色值）：
sprintf("%06x", 65280)→"00ff00" - 要大写：用
sprintf("%X", 65280)，dechex()没有大写选项 - 输入不确定是否为整数时，先
(int)$val再传给sprintf，避免隐式转换陷阱
十六进制和十进制之间的转换本身不难，真正卡人的永远是数据来源的类型混杂——字符串还是整数、带前缀还是不带、长度是否超出 int 范围。盯住变量的真实类型，比记住函数名重要得多。
