根本原因是mysql int有符号范围为-2147483648~2147483647，超限值被静默截断为边界值；php传入字符串或null时mysql隐式转为0；大数需用bigint unsigned，php入库前须校验类型并确保整型。
PHP整型存进MySQL时，为什么int字段会变成0或2147483647
根本原因不是PHP类型错了，而是MySQL的int有符号范围是-2147483648到2147483647，而PHP在32位环境里int最大值也是2147483647。一旦你传入超限值（比如3000000000），MySQL会静默截断为2147483647（有符号上限）或0（溢出后归零，取决于SQL模式）。
更常见的是：PHP把字符串"123"或null直接塞进int字段，MySQL自动转成0——这不是PHP错，是MySQL隐式转换在“帮忙”。
- 检查你的PHP变量是否真为整型：
var_dump($id);看是不是string(3) "123"而不是int(123) - 用
filter_var($input, FILTER_VALIDATE_INT)校验并强制转换，别信(int)强转——它对"123abc"也返回123 - 如果业务需要存大于
2147483647的数（比如订单号、雪花ID），MySQL必须用BIGINT UNSIGNED，对应PHP保持string或int（64位PHP下）
PHP用mysqli或PDO写int字段时，绑定参数类型怎么选
用预处理语句时，mysqli_stmt::bind_param()和PDOStatement::bindValue()的类型标识直接影响MySQL怎么解释数据。选错会导致隐式转换或截断。
-
mysqli中bind_param("i", $val)的"i"只认PHPint类型；如果$val是string，会被当作0处理 -
PDO默认PDO::PARAM_INT不强制校验，建议显式用$stmt->bindValue(':id', $id, PDO::PARAM_INT)，但前提是$id已确保是整型 - 安全起见，入库前统一做
is_int($val) && $val >= -2147483648 && $val 判断，超限走<code>BIGINT逻辑
从MySQL读int字段回来，PHP里是int还是string
取决于驱动配置和MySQL版本。老版本mysqlnd默认把所有数字当string返回，新版本可开启mysqli.options(MYSQLI_OPT_INT_AND_FLOAT_NATIVE, true)或PDO的PDO::ATTR_STRINGIFY_FETCHES => false。
立即学习“PHP免费学习笔记（深入）”；
- 不设原生类型时，
SELECT id FROM users返回的$row['id']是string，哪怕值是"123"——这会导致===比较失败、JSON编码多出引号 - 设了原生类型后，小整数变
int，但超限的BIGINT（如9223372036854775807）在32位PHP里仍会变成float或string，因为PHP无法精确表示 - 稳妥做法：读出来后用
filter_var($row['id'], FILTER_VALIDATE_INT) !== false判断是否可安全转整，否则保留string
MySQL的TINYINT(1)被PHP当成布尔，怎么避免误判
TINYINT(1)只是显示宽度，不是布尔类型。但很多ORM或框架（包括PDO某些配置）会把它映射成true/false，导致1变true、0变false、2变true（非零即真），完全丢失原始值。
- 查数据库时显式转类型：
SELECT CAST(status AS SIGNED) AS status FROM table，避免驱动自动映射 - PDO连接时加
array(PDO::ATTR_EMULATE_PREPARES => true)能绕过部分自动类型推断，但代价是性能略降 - 最可靠的是：永远别用
TINYINT(1)存状态码；用TINYINT（无(1)）或ENUM，并在PHP层用常量映射，比如const STATUS_ACTIVE = 1;
真正麻烦的从来不是存或取，而是团队里有人改了MySQL字段类型没同步改PHP校验逻辑，或者测试数据刚好都在32位整型范围内，上线后某天突然冒出2147483647——这时候再查就晚了。
