php的int类型依赖平台和配置，会静默溢出或转float；需用is_int()判断、var_dump()调试，跨环境部署前须核验php_int_max。
PHP里int不是“整数”那么简单
PHP的int类型行为和你直觉里的“整数”有偏差——它依赖平台（32位/64位）、受ini配置影响，且在类型转换时会静默溢出或降级为float。新手常以为123写哪都是int，结果在数据库写入、JSON序列化或算术比较时突然出错。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
-
var_dump($x)比echo gettype($x)更可靠，因为后者可能返回integer但值已是float（比如超限后自动转） - 用
is_int($x)判断类型，别用is_numeric($x)——后者对"123"也返回true - 32位系统下
PHP_INT_MAX是2147483647，64位是9223372036854775807；跨环境部署前必须检查phpinfo()里的Architecture和PHP_INT_MAX值
什么时候int会悄悄变成float
这不是bug，是PHP的隐式类型提升机制：当整数运算结果超出PHP_INT_MAX，或参与浮点数运算时，整个表达式升为float。常见于时间戳计算、大额金额累加、分页偏移量生成。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 做乘法前先用
if ($a > PHP_INT_MAX / $b)粗略防溢出（注意除零） - 用
bcadd()或gmp_add()替代+处理大整数，但需确认扩展已启用 - JSON编码时
json_encode(999999999999999999999)会输出字符串而非数字——因为float精度丢失后JSON扩展自动fallback，不是int本身的问题
filter_var($x, FILTER_VALIDATE_INT)的坑比想象中多
这个函数看似安全，但它默认只验证是否能转成整数，不校验范围，也不阻止科学计数法（如"1e3"会被接受）。更麻烦的是，它对null、空字符串、空白符返回false，但对" 123 "却返回123（自动trim）。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 强制指定
options参数：filter_var($x, FILTER_VALIDATE_INT, ['options' => ['min_range' => 0, 'max_range' => 100]]) - 如果输入来自表单，先
trim()再验证，避免"\t123\n"绕过长度限制 - 别用它替代
is_int()做类型断言——filter_var("123", FILTER_VALIDATE_INT)返回int，但filter_var(123, FILTER_VALIDATE_INT)也返回int，无法区分原始类型
数据库字段类型和PHPint不匹配的典型症状
MySQL的TINYINT(1)常被误当成布尔，UNSIGNED BIGINT存的时间戳在PHP里读出来可能是负数（32位系统），而Laravel/Eloquent默认把所有数字列映射为int，不管实际是否溢出。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 查MySQL时用
CAST(col AS SIGNED)或CAST(col AS UNSIGNED)显式声明符号性 - PDO预处理时绑定参数用
PDO::PARAM_INT，但注意它不校验值范围，超限仍会截断 - 用
mysqli_fetch_all(MYSQLI_NUM)拿到原始数值数组，比MYSQLI_ASSOC少一层类型猜测干扰
真正难的不是记住PHP_INT_MAX是多少，而是意识到同一段代码在本地开发机（64位）和生产服务器（旧版32位容器）上，int的行为可能完全不同。调试时别急着改逻辑，先var_dump(PHP_INT_MAX, PHP_VERSION, PHP_OS)。
