不能直接用 text 存 ip 地址做范围查询，因为字符串类型无法原生支持子网判断、网络位/主机位分离和内置子网运算，导致需依赖低效易错的正则与截取，且完全不兼容 ipv6；而 inet 类型自动校验格式、归一化显示并原生支持 cidr 运算。
为什么不能直接用 TEXT 存 IP 地址做范围查询
用 TEXT 或 VARCHAR 存 IP（比如 '192.168.1.100'），看似简单，但一到子网判断就崩：你没法直接表达“这个 IP 是否属于 192.168.1.0/24”，只能靠字符串截取 + 拼接 + 正则，性能差、易出错、IPv6 完全不兼容。
inet 类型才是正解——它原生支持网络位/主机位分离、自动校验格式、内置子网关系运算符。哪怕只存单个主机地址（如 '10.0.0.5'），PostgreSQL 也默认按 /32（IPv4）或 /128（IPv6）处理，语义清晰。
- 插入非法地址会直接报错：
ERROR: invalid input syntax for type inet: "999.1.1.1" - 自动归一化显示：
inet '192.168.001.005/24'→ 查询返回192.168.1.5/24 - IPv6 支持开箱即用：
inet '::ffff:192.168.1.10'合法，inet '::1'也是合法主机地址
inet 和 <code>inet 的真实含义与误用场景
这两个操作符常被当成“IP 是否在子网内”用，但它们**只比较网络前缀，不校验地址是否有效落在该网络中**。
例如：inet '192.168.2.5' 返回 <code>false，这没问题；但 inet '192.168.1.256' 会先报错——因为 <code>'192.168.1.256' 根本不是合法 inet 字面量，根本进不到比较阶段。
a 等价于 “a 的网络前缀是否完全落在 b 的网络范围内”，即 a 是 b 的子网或相等a 是严格子网关系（排除相等），<code>a >> b是反过来的“b 是否被 a 包含”- 真正做“IP 是否属于某子网”，应该用
ip_column ，其中左值是表中 <code>inet列，右值是目标子网 - 错误写法：
'192.168.1.5' —— 这里两个都是字面量，PostgreSQL 会尝试把前者解析为 <code>inet '192.168.1.5/32'，再比前缀，逻辑成立但可读性差；更稳妥写法是显式标注：inet '192.168.1.5'
用 host()、family() 和 inet_same_family() 避免隐式转换陷阱
当你要把 IP 地址转成字符串展示，或做跨协议判断时，别依赖隐式类型转换。PostgreSQL 在某些上下文（如拼接 ||）里会悄悄把 inet 转成文本，但结果可能带掩码（'192.168.1.5/24'），也可能不带（'192.168.1.5'），行为不稳定。
-
host(inet_column)强制剥离掩码，只返回纯 IP 字符串，适合日志、前端展示 -
family(inet_column)返回4或6，可用于分组统计 IPv4/IPv6 分布，或条件分支逻辑 -
inet_same_family(a, b)必须在做&&或inet_merge()前调用——否则 IPv4 和 IPv6 混合运算会直接报错：ERROR: cannot merge IPv4 and IPv6 networks - 常见坑：
WHERE ip_col && '10.0.0.0/8'如果ip_col里混了 IPv6 数据，这条 SQL 就会失败；应先加条件：WHERE inet_same_family(ip_col, '10.0.0.0/8') AND ip_col && '10.0.0.0/8'
子网过滤实际查询怎么写才高效且安全
子网过滤的核心是利用 B-tree 索引加速 查询，但前提是字段已建索引，且写法不破坏索引可用性。
- ✅ 推荐写法：
SELECT * FROM access_log WHERE src_ip —— 可走 <code>inet索引，毫秒级响应百万行 - ❌ 危险写法：
SELECT * FROM access_log WHERE host(src_ip) LIKE '192.168.%'—— 强制函数计算，全表扫描，IPv6 直接失效 - 复合子网判断（如封禁多个 CIDR）建议用
OR或IN（需 PostgreSQL ≥ 12）：WHERE src_ip - 注意
cidr类型和inet的区别：如果你的字段只存网络（如白名单网段），用cidr更语义准确，且cidr列对查询有更优的索引压缩率；但若字段既存主机又存子网（如日志原始 IP），必须用 <code>inet
最易被忽略的一点：inet 索引默认不支持 &&（重叠判断）的高效查询，需要用 gist 或 spgist 索引。如果业务大量依赖“两个网段是否相交”，别只建普通 B-tree 索引。
