mysql整型范围取决于有/无符号，如int默认有符号上限2147483647；postgresql integer溢出回绕、bigint严格报错；python struct可查c类型字节大小；js number精度上限为2^53-1，超限失真。
mysql 中 int、bigint 等整型的实际取值范围怎么看
直接看文档容易漏掉有符号/无符号的关键区别，实际建表时超限会静默截断或报错，取决于 sql mode。最稳妥的方式是查 information_schema 或用内置函数验证。
-
SELECT MIN(<code>INT), MAX(INT) 不合法 —— MySQL 没有这种类型字面量函数，得靠常量推算 - 记住口诀：带符号整型上限 =
2^(n-1)-1，无符号 =2^n-1，其中n是 bit 数（如INT默认 32 bit） - 建表时显式写
INT UNSIGNED才能用到 0～4294967295；否则默认有符号，上限是 2147483647 - 用
SHOW COLUMNS FROM table_name LIKE 'col_name'能看到字段定义里的int(11)—— 这个11是显示宽度，和存储范围完全无关，别被它误导
PostgreSQL 的 integer 和 bigint 在 psql 里怎么快速确认边界
PostgreSQL 把类型范围写死在系统视图里，但更常用的是直接查 pg_type 或用 pg_size_bytes 辅助理解，不过最直觉的还是用 SQL 表达式试出来。
- 执行
SELECT 2147483647::integer + 1，结果是-2147483648（溢出回绕），说明已到上限 -
SELECT 9223372036854775807::bigint + 1会报错ERROR: bigint out of range，因为 PG 对 bigint 溢出是严格报错 -
\dT+在 psql 里能列出所有类型及其内部长度（typlen），比如integer是 4，bigint是 8 —— 这个数字就是字节数，可换算为 bit - 注意：PG 的
smallint是 2 字节，但范围是 -32768～32767，不是 0～65535，除非你显式声明smallint UNSIGNED（不支持！PG 没有无符号整型）
Python 用 struct 查看 C 类型映射的存储字节数
Python 的 struct 模块本质是按 C ABI 打包数据，它的格式符直接对应底层存储大小，比查文档更快更准，尤其适合和二进制协议或数据库驱动打交道时核对。
-
struct.calcsize('i')返回 4 → 对应 C 的int，通常是 32 位（但平台相关） -
struct.calcsize('q')返回 8 → 对应 C 的long long，即 64 位整数 - 别用
'l'（小写 L）想当然代表 long —— 在 Windows 上它是 4 字节，在 Linux x86_64 上是 8 字节，不可移植 - 如果要确保跨平台一致，优先用
'i'、'q'、'I'（无符号 int）这类明确位宽的格式符，而不是依赖系统定义的'l'或'L'
前端 JS 里 Number.MAX_SAFE_INTEGER 为什么不是存储上限而是精度上限
JavaScript 所有数字都是 Number 类型（IEEE 754 双精度浮点），它能表示远大于 9007199254740991 的整数，但超出后就无法保证精确性 —— 这和数据库里“存不下就报错”完全不同。
-
Number.MAX_SAFE_INTEGER是2^53 - 1，即 9007199254740991；再加 1，9007199254740992 === 9007199254740993返回true - 用
BigInt可以突破这个限制，但必须显式写成9007199254740992n，且不能和普通Number混合运算 - 和后端交互时，如果 ID 是 64 位整数（比如
BIGINT），JSON 序列化后传到前端可能被自动转成Number导致精度丢失 —— 必须后端转字符串，前端再用BigInt解析 - Chrome 控制台输
999999999999999999回车，显示的是1000000000000000000，这就是典型浮点舍入，不是 UI 显示问题，是值本身已失真
事情说清了就结束。真正容易被忽略的，是不同系统对“超限”的响应方式：有的截断，有的回绕，有的报错，有的静默转浮点 —— 别只信文档写的范围，一定在你的运行环境里亲手试一试溢出行为。
