inet_pton是最可靠方式，它调用系统底层解析器，能正确处理双冒号压缩、大小写混写、嵌入IPv4等所有RFC 4291合法变体；返回1即合法，0为格式非法，-1在标准平台几乎不出现；但调用前必须剥离空格、zone ID（如%eth0）、端口号和URL前缀，且Windows需包含Ws2tcpip.h并链接ws2_32.lib。
inet_pton 是最可靠的方式，它直接调用系统底层解析器，能正确处理双冒号压缩、大小写混写、嵌入 IPv4（如 ::ffff:192.0.2.1）等所有 RFC 4291 合法变体。只要返回 1，就说明字符串符合 IPv6 地址规范；返回 0 表示格式非法；返回 -1 在标准平台上几乎不会出现（仅当传错地址族时）。
但直接调用 inet_pton 前，必须清理输入——否则看似合法的字符串也会被误判为无效。
调用 inet_pton 前必须剥离的干扰字符
系统函数对输入极其敏感，以下情况都会导致返回 0（被当成格式错误）：
- 首尾空格、制表符、换行符或回车符 —— 必须用
s.find_first_not_of(" \t\n\r")和s.find_last_not_of(" \t\n\r")截取干净子串 - IPv6 zone ID（如
fe80::1%eth0中的%eth0）—— 需提前用s.find('%')截断，只保留%前部分 - 端口号（如
[::1]:8080）—— 若原始字符串带方括号和冒号后数字，需先去掉括号、再从右往左找最后一个:，确认右侧全为 ASCII 数字后截掉 - URL 前缀（如
http://[::1]）—— 这根本不是纯地址，必须由上层逻辑剥离
inet_pton 的平台差异与链接要求
Linux/macOS/WSL 下开箱即用，但 Windows 需额外两步：
立即学习“C++免费学习笔记（深入）”；
- 包含头文件：
#include <Ws2tcpip.h> - 链接库：
ws2_32.lib（MSVC）或-lws2_32（MinGW） - 若未调用
WSAStartup初始化 Winsock，inet_pton会静默失败（返回 0），而非崩溃 —— 容易误判为格式错误
缓冲区必须是 struct in6_addr 类型，大小严格为 16 字节；传小了会越界，传大了无意义。
为什么不用 std::regex 做最终判定
正则表达式在 IPv6 场景下极易漏判或误判，且 C++ 标准库实现存在硬伤：
- 无法可靠处理
::的语义：像a::b::c这种非法多压缩形式，正则很难拒绝 - MSVC 的
std::regex对长回溯敏感，输入"1:2:3:4:5:6:7:::"可能卡死数秒 - 不校验段长上限：正则可能接受
fffff（5 位十六进制），但 IPv6 每段最多 4 位 - 忽略大小写需显式加
std::regex_constants::icase，漏掉就判错 - 嵌入 IPv4 部分（如
::ffff:192.0.2.1）需额外分支，正则迅速失控
如果非要用正则，仅限前置粗筛（比如排除不含冒号或含空格的字符串），绝不能替代 inet_pton。
手动解析仅适用于无 libc 或嵌入式环境
当无法使用 inet_pton（如裸机、FreeRTOS）时，手动解析必须守住三条底线：
- 冒号总数只能是 2–7 个；
::最多出现一次，且不能紧邻（:::非法） - 分割后每段长度必须为 1–4，且每个字符必须是十六进制（用
isxdigit(static_cast<unsigned char>(c))</unsigned>判，避免符号扩展问题） - 遇到
::时，拆成左右两片分别计段，补零段数 =8 - left_count - right_count，结果必须 ≥ 0
注意：std::stoi(segment, nullptr, 16) 不可用——它接受 0x123 和超长串（如 00000），而 IPv6 段不允许前缀、也不允许超过 4 位。
真正难的不是写对逻辑，而是记住：IPv6 合法性由系统解析器定义，不是某份 RFC 文本的字面意思。哪怕字符串看起来“符合规则”，只要 inet_pton 返回 0，它就不算有效 IPv6 地址。
