MySQL原生INET_ATON()和INET_NTOA()已足够，无需自定义函数；其返回-1或0主因是类型错配（BIGINT SIGNED解释无符号IPv4）或非法输入静默返回0，须配合TRIM、正则校验、CAST(AS UNSIGNED)及INT UNSIGNED字段类型确保安全。
INET_ATON() 和 INET_NTOA() 已经足够，别写自定义函数。MySQL 原生函数在语义、性能和兼容性上都远超手写逻辑，自己实现反而引入溢出、字节序、校验缺失等风险。
INET_ATON() 返回 -1 或 0 是怎么回事
INET_ATON() 返回类型是 BIGINT SIGNED，但 IPv4 地址本质是 32 位无符号数：
-
'255.255.255.255'→ 数值是 4294967295 - 在有符号
BIGINT上显示为 -1（补码解释），不是错误，是类型错配的表象
更危险的是非法输入：
-
INET_ATON('192.168.1')、INET_ATON(' 192.168.1.1 ')、INET_ATON('010.0.0.1')都静默返回 0 - 0 是合法整数，可能被误存进字段，后续查不到数据却无报错
所以关键不是“怎么转”，而是“怎么避免转出错”：
- 插入前用
TRIM()清空格 - 用正则粗筛格式：
ip_str REGEXP '^([0-9]{1,3}\.){3}[0-9]{1,3}$' - 再对每一段做数值检查（如
CAST(SUBSTRING_INDEX(ip_str, '.', 1) AS UNSIGNED) BETWEEN 0 AND 255） - 最终存储必须配合
CAST(... AS UNSIGNED)强制无符号语义
存 INT UNSIGNED 字段时为什么不能直接写 INET_ATON('...')
因为字段类型和函数返回类型不匹配：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
INET_ATON('255.255.255.255')在 SELECT 中可能显示为 -1 - 往
INT UNSIGNED字段 INSERT 这个 -1，会触发截断或报错（取决于 SQL 模式）
正确写法是显式转换：
-
INSERT INTO logs (ip) VALUES (CAST(INET_ATON('192.168.1.1') AS UNSIGNED)); - 字段定义必须是
INT UNSIGNED，否则 CAST 无效 - 查询还原时也建议加 CAST：
SELECT INET_NTOA(CAST(ip AS UNSIGNED)) FROM logs;，防字段被意外建成INT
INET_NTOA() 突然全返回 NULL 怎么排查
这不是函数坏了，是输入不合法：
- 输入为负数（比如字段建成了
INT而非UNSIGNED）→INET_NTOA(-1)返回NULL - 输入超过 4294967295（如误存了 IPv6 的二进制长度值）→
NULL - 输入是
NULL或非数字字符串 →NULL
调试时不要只看原始字段：
-
SELECT ip, ip + 0, INET_NTOA(CAST(ip AS UNSIGNED)) FROM logs LIMIT 5; -
ip + 0可暴露隐式转换问题（比如字符串'192.168.1.1'被当作文本存进 INT 字段导致全 0） - 真正麻烦的永远不是转换逻辑本身，而是字段类型、插入路径、校验缺位这三处松动
