INET_ATON 返回 0 是因为输入不符合严格 IPv4 格式要求，如含空格、前导零、非法字符或段值超范围；它不报错，仅返回 0，需配合 TRIM 和正则预处理。
INET_ATON 为什么返回 0？
不是所有字符串都能转成有效 IP 数字，INET_ATON 对输入极其严格：只接受标准 IPv4 格式（如 "192.168.1.1"），遇到空格、多余点、非数字字符、超范围段（如 "256"）直接返回 0，不报错也不提示。
- 常见错误现象：
SELECT INET_ATON(' 192.168.1.1 ')→0（首尾空格）；INET_ATON('192.168.01.1')→0（带前导零，MySQL 不识别八进制写法） - 使用场景：入库前校验 IP 字符串合法性，比正则快，但不能替代应用层清洗
- 实操建议：入库前先用
TRIM()去空格，再用REGEXP '^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$'粗筛，最后调INET_ATON
存储 IP 用 INT 还是 VARCHAR？
用 INT UNSIGNED 存 INET_ATON 结果，比 VARCHAR(15) 节省空间、索引更快、范围查询更直接——这是 MySQL 官方推荐做法，但前提是只处理 IPv4。
- 参数差异：
INET_ATON返回的是 32 位无符号整数，必须用INT UNSIGNED接收，用普通INT会导致高位溢出变负数 - 性能影响：等值查询（如
WHERE ip_int = INET_ATON('10.0.0.1')）走索引毫无压力；而VARCHAR上做LIKE '10.%'或函数索引支持差得多 - 容易踩的坑：迁移旧数据时没加
UNSIGNED，导致部分 IP（如192.168.x.x）存成负数，后续INET_NTOA反解失败
INADDR_ANY 和 INET_ATON('0.0.0.0') 是一回事吗？
在 MySQL 里，INET_ATON('0.0.0.0') 就是数值 0，和 C 里的 INADDR_ANY 概念上一致（表示任意本地地址），但 MySQL 本身不参与网络绑定，它只是个数值转换函数。
- 使用场景：记录监听地址为“不限”时，可存
0；查询时用INET_NTOA(ip_int) IS NULL OR INET_NTOA(ip_int) = '0.0.0.0'判断 - 注意：
INET_ATON(NULL)返回NULL，不是0；INET_ATON('0.0.0.0')才是0，二者语义不同，别混用 - 兼容性影响：老版本 MySQL（0.0.0.0 解析稳定，但某些中间件或 ORM 会把
0当空值处理，读取时需显式判断
IPv6 怎么办？INET_ATON 不支持
INET_ATON 只认 IPv4，传入 IPv6（如 "::1" 或 "2001:db8::1"）一律返回 0。MySQL 5.6.3+ 提供了 INET6_ATON 和 INET6_NTOA，但类型必须是 VARBINARY(16)，不能用 INT。
- 常见错误现象：
SELECT INET_ATON('::1')→0，看着像成功，实则是静默失败 - 实操建议：业务要支持双栈，字段设计就得区分，比如
ip_v4 INT UNSIGNED+ip_v6 VARBINARY(16)，查时用COALESCE(INET6_NTOA(ip_v6), INET_NTOA(ip_v4)) - 容易被忽略的点：
INET6_ATON对 IPv4-mapped IPv6（如::ffff:192.168.1.1）能转，但反解INET6_NTOA默认输出 IPv6 格式，得自己截断或判断
