C++高性能服务器框架Address模块设计：统一IPv4/IPv6与Unix地址抽象

1. 从“连IP都写不好”到统一地址抽象

先聊个真实场景。你写一个网络服务，监听端口用0.0.0.0:8080，客户端连的时候要用127.0.0.1:8080，到了线上又变成192.168.1.100:8080。短连接还好，一旦涉及IPv4、IPv6、域名解析、Unix套接字，代码里就会塞满struct sockaddr_in、struct sockaddr_in6、struct sockaddr_un，每种结构体的字段还不一样，初始化方式也完全不一样。

我用过好几个项目，底层网络模块里全是这类结构体满天飞。改一个协议族，牵扯出一大片代码，而且还得小心翼翼处理字节序、地址长度、类型转换。这就是为什么C++高性能服务器框架里一定会单拆一个Address模块——它把所有地址类型收敛到一个统一抽象之下，让你在业务代码里根本不用关心底层是IPv4还是IPv6，只需要拿到一个Address::ptr，调用toString()就知道地址是什么，调用create()就能把字符串地址直接转成可用的地址对象。

这个模块适合谁？适合正在写网络库、RPC框架、网关服务、代理服务，或者单纯想把网络代码写得干净一点的人。就算你只是自己折腾一个高并发服务器练手，把Address模块设计好了，后面做连接管理、协议解析、负载均衡都会顺畅很多。

2. Address模块在整个服务器框架里的定位

高性能服务器框架通常分层长这样：最底层是事件驱动（epoll/kqueue），往上是线程模型和任务调度，再往上是网络收发和协议解析，最上层才是业务逻辑。Address模块属于网络层的基础设施，它服务的是“把人和机器能读的地址，变成机器能用的结构体，再让上层用统一方式操作”。

不夸张地说，没有这个模块，后面的Socket封装、TcpServer、HttpServer全都得裸写getaddrinfo和sockaddr，代码会迅速腐化。

2.1 解决三个长期痛点

第一，结构体不统一。IPv4的sockaddr_in、IPv6的sockaddr_in6、Unix Domain Socket的sockaddr_un，三者字段不同、长度不同、初始化方式不同。业务层如果要同时支持多种地址类型，就得写大量判断逻辑。

第二，字符串和结构体互转繁琐。inet_pton、inet_ntop这类函数在不同平台上细节不一致，还要处理错误码，很容易踩坑。

第三，地址生命周期管理混乱。裸指针传递sockaddr*时，你必须知道它背后到底是个多大的结构体，否则就会出现缓冲区越界读取。Address模块用智能指针统一管理，从根上解决这个问题。

2.2 模块设计的分工逻辑

去看几个主流C++服务器框架的源码，你会发现Address模块几乎都是这几个类：Address（抽象基类）、IPAddress（IP地址抽象）、IPv4Address、IPv6Address、UnixAddress，再加上一个负责解析的静态工具类。这个分层非常经典，抽象基类定义统一接口，派生类实现具体协议族的逻辑，工具类负责字符串解析和系统查询。

我对这种设计一个很深的体会是：不要为了面向对象而面向对象，但地址模块确实需要这个继承体系，因为不同协议族的操作差异是客观存在的，你要抹平它，只能抽象接口。关键在于，抽象接口的粒度要刚好合适，不能把每个协议族的特性都塞进去，否则基类接口会越来越臃肿。

3. 核心类设计与关键接口解析

这一节直接上干货，我把每个类的职责、关键接口、实现时要避开的坑都讲清楚。没有源码讲解的模块分析都是耍流氓，但光贴源码也学不到东西，我按“接口长什么样 - 为什么这么设计 - 实现时注意什么”的顺序来拆。

3.1 Address基类：统一之门

class Address { public: using ptr = std::shared_ptr<Address>; virtual ~Address() {} // 获取sockaddr指针和长度，用于系统调用 virtual const sockaddr* getAddr() const = 0; virtual socklen_t getAddrLen() const = 0; // 转成可读字符串，如 "192.168.1.100:8080" virtual std::string toString() const = 0; // 协议族，AF_INET / AF_INET6 / AF_UNIX virtual int getFamily() const = 0; // 从字符串创建对应类型的地址 static Address::ptr Create(const sockaddr* addr, socklen_t addrlen); static Address::ptr LookupAny(const std::string& host, int family = AF_UNSPEC); static Address::ptr LookupAnyIPAddress(const std::string& host); static bool Lookup(std::vector<Address::ptr>& result, const std::string& host, int family = AF_UNSPEC, int type = 0, int protocol = 0); };

getAddr()返回const sockaddr*，这是为了让上层能直接把它传给bind、connect、sendto这些系统调用。你可能觉得返回裸指针不优雅，但系统调用要求的就是sockaddr*，你这么设计反而最直接。

Create是静态工厂方法，根据传入的sockaddr的sa_family字段判断类型，然后构造对应的派生类对象。这个设计解决了一个核心问题：你从accept拿到一个sockaddr_storage后，想把它封装成Address对象，却不知道该实例化哪个类，交给工厂方法就行。

LookupAny和Lookup内部封装了getaddrinfo。Lookup会尝试解析出所有匹配的地址，LookupAny只取第一个可用的。域名解析那部分我再单独展开。

3.2 IPAddress：带上端口再说话

sockaddr_in和sockaddr_in6都包含地址和端口，而且字节序都得转成网络序。IPAddress把这两个能力提升成接口：

class IPAddress : public Address { public: // 获取/设置端口，主机字节序 virtual uint16_t getPort() const = 0; virtual void setPort(uint16_t v) = 0; // 获取/设置网段地址，返回IPAddress，mask是CIDR前缀长度 virtual IPAddress::ptr getNetworkAddress(uint32_t prefix_len) = 0; virtual IPAddress::ptr getBroadcastAddress(uint32_t prefix_len) = 0; virtual IPAddress::ptr getSubnetMask(uint32_t prefix_len) = 0; };

getNetworkAddress和getBroadcastAddress是为了网络规划而设计的。比如你想算出192.168.1.55/24这个网段的网络地址是192.168.1.0，广播地址是192.168.1.255，直接调方法传前缀长度即可。

端口为什么要单独封装？因为从sockaddr_in里取端口，你得先ntohs(addr->sin_port)，这行代码写多了容易忘，忘了就出现端口反了的问题。模块直接帮你处理好，业务代码永远操作主机字节序。

3.3 IPv4Address：最常用的那个

IPv4地址的解析和格式化核心函数是inet_pton和inet_ntop，但用的时候有几个细节要注意。

bool IPv4Address::parse(const std::string& addr) { // 先按 ':' 分割出IP和端口 size_t pos = addr.rfind(':'); if (pos == std::string::npos) return false; std::string ip_part = addr.substr(0, pos); std::string port_part = addr.substr(pos + 1); // 端口必须是纯数字 for (char c : port_part) { if (!isdigit(c)) return false; } uint16_t port = atoi(port_part.c_str()); // inet_pton 返回 1 成功，0 输入不合法，-1 协议族不支持 if (inet_pton(AF_INET, ip_part.c_str(), &m_addr.sin_addr) != 1) { return false; } m_addr.sin_family = AF_INET; m_addr.sin_port = htons(port); return true; }

这里有个很关键的注意点：rfind(':')找的是冒号分隔符。IPv4地址里没有冒号，所以可以放心用；但如果是IPv6地址，里面全是冒号，就不能用这么朴素的方式了。IPv6的解析要复杂得多，因为地址本身包含冒号，还有::压缩写法，用rfind(':')就废了。

换行前我再提一个字节序的点：sin_addr.s_addr在网络字节序里，你不能直接拿来和127.0.0.1的整数形式比较，必须通过inet_addr("127.0.0.1")或者htonl(INADDR_LOOPBACK)转成网络序再比，这点我见过不下五次搞错的。

3.4 IPv6Address：那些年坑过我的冒号

IPv6地址解析最大的难点是::压缩表示。::1代表回环地址，2001:db8::1中间省略了一大串0。直接用inet_pton解析字符串没问题，但你想把sockaddr_in6格式化成字符串，inet_ntop出来的结果不一定是缩写的。所以我在模块里自己实现了IPv6Address::toString()，这比想象中麻烦：你得先把16字节的地址按8组打印，然后检测是否存在连续0的段，有的话尽量用::压缩。

我给出一个简化版的格式化成缩写的策略：先完整打印出8组十六进制数，再去扫描最长连续全零段，如果长度大于等于2，就替换成::，最后还要处理端口拼接的问题。

std::string IPv6Address::toString() const { uint16_t groups[8]; for (int i = 0; i < 8; i++) { // 每两个字节一组，转为16位整数 groups[i] = (m_addr.sin6_addr.s6_addr[i * 2] << 8) | m_addr.sin6_addr.s6_addr[i * 2 + 1]; } // 找最长全零段 int max_start = -1, max_len = 0; for (int i = 0; i < 8; i++) { if (groups[i] == 0) { int j = i; while (j < 8 && groups[j] == 0) j++; if (j - i > max_len) { max_len = j - i; max_start = i; } i = j; } } std::stringstream ss; bool compressed = false; for (int i = 0; i < 8; i++) { if (max_len >= 2 && i == max_start) { ss << (compressed ? "" : "::"); if (max_start == 0) compressed = true; i = max_start + max_len - 1; continue; } if (i > 0) { // 冒号分隔，但如果当前是压缩位置之后，前面已经有 "::" } ss << std::hex << groups[i]; } // 追加端口 ss << ":" << ntohs(m_addr.sin6_port); return ss.str(); }

这段代码逻辑细节多，我讲两个易错点：

第一，::只能出现一次。所以压缩标记要记录下来，如果已经压缩过一次，后面再遇到全零段也不能压缩。

第二，端口拼接。IPv6的字符串表示里端口放在地址后面的[]中，比如[2001:db8::1]:8080。但在模块内部，我习惯把 toString 分成两个接口：一个输出纯地址，一个输出带端口的完整形式。内部记录端口时用ntohs转成主机序，拼接时再加上去。

3.5 UnixAddress：被忽略但很有用的那个

Unix Domain Socket 不需要IP和端口，它的sockaddr_un里只有一个sun_path文件路径，长度也有限制（不同系统不一样，Linux 上是108字节）。这个类的实现最简单，但有几个坑：

• sun_path不是标准字符串，它不要求以\0结尾。
• 路径长度超出sizeof(sun_path)时，bind会报EINVAL。
• 创建socket文件时要小心目录权限，而且关闭服务后，socket文件不会自动删除。

class UnixAddress : public Address { public: UnixAddress(const std::string& path) { memset(&m_addr, 0, sizeof(m_addr)); m_addr.sun_family = AF_UNIX; size_t len = path.size(); if (len >= sizeof(m_addr.sun_path)) { throw std::invalid_argument("Unix socket path too long"); } memcpy(m_addr.sun_path, path.c_str(), len); // 手动补一个 \0，保险起见 m_addr.sun_path[len] = '\0'; m_length = offsetof(sockaddr_un, sun_path) + len + 1; } private: sockaddr_un m_addr; socklen_t m_length; };

为什么我强调要设置m_length？因为sockaddr_un的实际有效长度跟路径长度有关，你把整个结构体长度传进去，虽然也能工作，但严谨的做法是用offsetof加上路径长度。这个细节影响的是抽象性：getAddrLen()返回的值必须精确，否则传给bind时可能读到未初始化的内存。

3.6 核心接口一图速览

4. 地址解析全流程：Lookup到底做了什么

这个模块里最容易被低估的是静态方法Lookup。业务方拿到一个"www.example.com:8080"或者"192.168.1.10:3000"，就指望框架帮他变成可以连接的Address对象。

4.1 从字符串到地址的内部路径

Lookup的内部逻辑大致是：

1. 用统一资源标识符解析方式，把host字符串分为“主机名”和“端口/服务名”两部分。
2. 调用getaddrinfo(host, service, &hints, &results)做系统级解析。
3. 遍历results链表，把每个addrinfo里的ai_addr通过Address::Create转成智能指针封装的Address对象，存入vector返回。

其中有几个参数会影响解析结果：

• hints.ai_family：只查IPv4就设AF_INET，只查IPv6就设AF_INET6，不限制就AF_UNSPEC。
• hints.ai_socktype：这个字段很关键，如果明确是TCP连接，设成SOCK_STREAM，就会过滤掉不支持TCP的地址记录。
• hints.ai_flags：查本机地址时设AI_PASSIVE，配合NULL主机名可以拿到通配地址。

4.2 域名解析失败与超时的处理

getaddrinfo这个函数默认是阻塞式的，DNS解析失败可能要等好几秒。在高性能网络框架里，这个问题不可忽略。

我之前遇到一个情况：服务启动的时候要连接一个数据库地址，数据库域名解析突然变得很慢，整个启动流程卡了很久。后来排查发现就是getaddrinfo阻塞导致的。这个问题的解法通常有三种：

• 把地址解析放到独立的线程池里，不让它阻塞关键路径。
• 把解析结果缓存起来，定期刷新，减少解析频率。
• 用res_ninit和res_nquery这类更底层的函数自己做带超时的DNS查询，但跨平台性变差。

我个人在实际项目中的取舍是：日常使用直接用getaddrinfo，但设计上把Lookup做成无锁可并发的接口，用Per-thread缓存缓解压力。如果真有极致低延迟的场景，再考虑脱离系统库，完全自己做DNS解析。

4.3 LookupAny和LookupAnyIPAddress有什么区别

Lookup返回所有匹配地址。比如你查localhost，可能同时拿到IPv4的127.0.0.1和IPv6的::1。业务层如果只想要一个地址，就用LookupAny，它在内部调用Lookup后取第一个。

LookupAnyIPAddress更严格，它要求返回结果必须是一个IP地址（不能是UnixDomainSocket等类型）。它先调用Lookup，然后遍历查找第一个IPAddress::ptr强转成功的结果。

你是不是觉得取第一个可能不准？比如你明明想要IPv4，结果第一个是IPv6。这就是为什么LookupAny要接收family参数。框架内部处理HTTP服务器解析监听地址时，我一般把family嵌到调用方的配置里，让用户明确指定。

5. 实操：在服务器框架里集成Address模块的关键代码

这一节我把代码实战拉通，从拿到配置字符串到真正建立监听，看看Address模块是怎么在框架里串起来的。

5.1 解析监听地址

假设你的配置文件里有这么一行：

listen = 0.0.0.0:8080

你要写一个函数，把字符串转成Address::ptr，并且后面直接交给TcpServer去bind。

Address::ptr parseListenAddress(const std::string& str) { auto addr = Address::LookupAny(str, AF_INET); if (!addr) { // 解析失败要提供足够清晰的日志 throw std::runtime_error("cannot resolve listen address: " + str); } auto ip = std::dynamic_pointer_cast<IPAddress>(addr); if (!ip) { throw std::runtime_error("listen address is not an IP address"); } return ip; }

这个过程中有个容易忽略的地方：当监听地址是0.0.0.0（即 INADDR_ANY）时，它可以匹配本机任何一块网卡的IP。你后续如果用它去比较“客户端是否来自本机”，会发现结果不符合预期，因为所有来源都算本机。要区分清楚：通配地址用于监听，实际连接时系统会自动替你选择一个具体的源地址。

5.2 从accept拿到新连接地址

服务端accept返回的是sockaddr_storage，这时用Address::Create把它包成Address对象，就可以统一格式化成日志信息。

void handleNewConnection(int client_fd, sockaddr_storage* storage, socklen_t len) { Address::ptr peer_addr = Address::Create((sockaddr*)storage, len); if (peer_addr) { // 记录客户端来源：192.168.1.100:34321 LOG_INFO << "new connection from " << peer_addr->toString(); } }

注意sockaddr_storage要足够大，能容纳任何类型的地址，这是POSIX标准特意设计用来做容器类型的结构体。你如果直接用sockaddr_in来接收IPv6连接，缓冲区不够大，数据会被截断，这是很典型的安全漏洞来源。

5.3 客户端连接：域名直连

客户端场景更常见：

Address::ptr server_addr = Address::LookupAny("api.example.com:443", AF_INET); if (!server_addr) { LOG_ERROR << "can't resolve api.example.com"; return; } int fd = socket(server_addr->getFamily(), SOCK_STREAM, 0); if (fd < 0) { LOG_ERROR << "socket create error"; return; } int rt = connect(fd, server_addr->getAddr(), server_addr->getAddrLen()); if (rt != 0) { LOG_ERROR << "connect to " << server_addr->toString() << " error"; close(fd); return; }

你不需要关心server_addr到底是IPv4还是IPv6，统一用getFamily()创建socket，用getAddr()和getAddrLen()传参。这就是抽象的价值。

但注意，域名解析出来多个IP时，LookupAny只拿了第一个，如果第一个IP连不上，后面的IP就浪费了。真实场景里应该在Lookup全量结果上做逐个连接尝试。我封装过一个connectWithRetry函数，遍历所有地址，直到socket连接成功才返回，这样容灾性更好。

5.4 网段计算实战：判断IP是否在白名单内

有了getNetworkAddress，做IP白名单验证非常方便。假设白名单里存的是192.168.1.0/24，来了一个客户端地址192.168.1.55，你只要把两个地址分别调用getNetworkAddress(24)，比较结果是否一致就行。

bool checkInNetwork(IPAddress::ptr target, IPAddress::ptr network, uint32_t prefix_len) { auto target_net = target->getNetworkAddress(prefix_len); auto network_net = network->getNetworkAddress(prefix_len); return target_net->toString() == network_net->toString(); }

注意在比较两个Address对象时，直接比较toString可能不够严谨，因为IPv6压缩格式不同可能导致同一地址不同字符串。更好的是比较它们的原始二进制内容。如果在自己模块里实现operator==，我会直接memcmp底层sockaddr的地址部分。

6. 性能优化与内存布局的思考

既然标题是高“性能”服务器框架，地址模块就不能只顾接口好用，性能上也不能拖后腿。

6.1 规避频繁的动态分配

如果你在每次新连接到达时都new一个IPv4Address，在高并发下（每秒几万连接），内存分配会成为不小的开销。解决思路有两个：

• 使用对象池，复用Address对象。
• 把Address对象设计成小对象，栈上分配为主。

Address的sizeof如果控制在几十字节以内（sockaddr_in是16字节，sockaddr_in6是28字节），那栈上分配完全没问题。但业务层需要把Address存到容器里跨函数传递时，就得用堆了。折中方案是：接收连接时栈上构造临时对象，只把最终需要存入日志或连接表的对象做堆分配。

6.2 缓存toString结果

toString()内部要做字符串拼接，频繁调用会触发字符串内存扩展。在热路径上（比如每一条访问日志都要记录客户端IP），我建议在Address对象内部加一个std::string m_cache，首次调用时计算并缓存，后续直接返回引用。前提是Address不可变——所以我把setPort设计成重新计算缓存，或者在设置完成后手动invalidateCache()。

6.3 线程安全与不可变性

Address模块建议设计成不可变对象：创建完成后，内部字段不再变化。这样做的好处是多个线程可以共享同一个Address::ptr而无需加锁。如果需要新的端口，就创建新的Address对象，而不是去修改现有对象。

频繁创建带来的性能问题，通过前面的对象池方案解决。我在实际实现里会给IPv4Address加一个静态的缓存池，存储最近用过的地址，超过N个就淘汰。不过这个优化要警惕，地址被修改后缓存会失效，所以不可变性是前提。

6.4 内存布局上的对齐问题

sockaddr_in6包含一个sin6_scope_id字段（链路本地地址的接口索引），在栈上定义时要注意对齐。C++里如果你直接用sockaddr_storage，对齐问题都帮你处理好了，所以尽量别直接分配sockaddr_in或sockaddr_in6裸变量来当容器，统一用sockaddr_storage更安全。

7. 常见问题与排查技巧实录

写到这里，我把过去几年踩过的坑系统整理一遍，这些问题在文档里很难看到，但实战里一条比一条致命。

7.1 解析 “localhost” 拿到的是IPv6，连接失败

我在本地联调时遇到过一次：服务端监听0.0.0.0:8080，客户端却写localhost:8080连接。结果客户端解析localhost优先拿到::1（IPv6回环地址），而服务器只监听了IPv4，连接直接拒绝。

这个问题的根源在于getaddrinfo返回的顺序不是你能控制的。保险的做法有两种：

• 在客户端代码里，对Lookup返回的每个地址逐个尝试连接。
• 客户端明确指定协议族，用AF_INET强制只查IPv4。

我自己的习惯是都做：遍历连接 + 可配置协议族。

7.2 IPv6 地址 toString 的输出格式不一致

前面讲过inet_ntop不一定会输出压缩格式，两台机器上的同一个IPv6地址，输出格式可能不同。这会影响日志分析、指纹识别和IP比较。

我在模块里统一实现自己的格式化逻辑，压缩策略要提前定好。这里再分享一个细节：压缩::时要优先压缩最长的连续0段，如果长度相同，压缩靠前的那段，这是RFC 5952规定的规范写法。

7.3 Unix Socket 路径长度超限

不同系统的sun_path长度不同。Linux 上一般是108字节，macOS 上是104字节。跨平台代码里如果硬编码长度，换个平台就出问题。正确做法是运行时用sizeof(sockaddr_un::sun_path)判断。

注意：路径字符串末尾的\0也要算进长度里，所以实际可用长度是sizeof(sun_path) - 1。很多初学者写满108字节路径，结果 bind 时报 File name too long 错误。

7.4 端口范围与校验

端口范围是0到65535，其中0通常表示“由系统自动分配”，某些系统上1024以下端口需要特权才能绑定。parse函数里最好加上范围检查，避免用户配置99999:8080这种明显错误的值。

7.5 字节序问题：一个小时后才发现的bug

我曾经写过一个代理服务，从配置里读到端口号传入setPort，结果所有后端连接都发到了错误的端口。最后定位是setPort里忘记调用htons转网络序。

这类问题单靠肉眼很难发现，因为部分端口值恰好转序后和原值一样（比如8080的十六进制是0x1F90，转序后是0x901F，根本不一样）。我的建议是：底层存储始终用网络字节序，外部接口始终用主机字节序，在模块内部边界统一转换，绝不越界处理。

7.6 getaddrinfo 的线程安全

getaddrinfo本身是线程安全的，但有些旧平台上的底层实现可能有隐患。我自己在Linux上跑过压测，大并发时出现偶尔的解析失败，后来发现是系统glibc版本和DNS配置问题，升级后解决。稳妥起见，可以在框架里做一次简单的并发验证，确认目标平台没这个问题。

7.7 常见问题速查表

8. Address模块的扩展方向

沿着基础地址模块继续走，有几个非常值得扩展的方向，这里一并说了，免得你搭完基础模块不知道怎么往深度发展。

8.1 支持网卡枚举和接口地址查询

高性能服务器有时候需要根据本机网卡列表动态选择监听地址，或者做健康检查。通过getifaddrs可以拿到本机所有网卡的地址列表，然后封装成std::vector<Address::ptr>返回。有了这个接口，框架可以支持类似 Nginx 的listen多地址绑定，也可以自动适配多网卡环境。

8.2 地址序列化与反序列化

分布式场景下要把Address传到另一台机器做配置同步或服务发现。这时候需要一个二进制序列化格式。我的做法是：先写一个协议族字节，再写地址二进制内容，最后写端口。反序列化时按同样的顺序解析。这个格式轻量、快速，比JSON省空间还快。

8.3 地址解析与DNS缓存的整合

getaddrinfo每次查询成本不低，尤其在高频短连接场景。可以在Address模块之上加一个DNS缓存层，用LRU策略缓存解析结果，设置TTL。但要注意过期和强制刷新机制。我之前在缓存里设置过一个坑：服务端更新IP后，客户端因为缓存了旧IP连不上，排查半天最后发现是缓存还没过期。

8.4 协议族无关的Socket封装

当你把Address模块做扎实后，下一步就是封装Socket类。这个类接收Address::ptr做参数，内部根据getFamily()决定创建哪种socket，最终实现一套代码同时支持IPv4、IPv6、UnixSocket的连接和监听。这是从“地址抽象”迈向“IO抽象”的关键一步，也是框架迈向成熟的重要分水岭。

9. 个人体会与小技巧

最后聊一点我实际操作中的体会。Address模块这种基础组件，最难的不是实现某个具体类，而是抽象粒度的把握。我在第一版设计里把getNetworkAddress、getBroadcastAddress这些网络规划接口放在IPAddress层，一开始觉得没必要，后来做IP白名单和子网划分功能时才意识到这个设计有多好用。所以说，基础模块的眼光放长远点，宁可现在多做一点，也比日后返工强。

另外一个很实用的小技巧：调试期间可以给Address::toString()做一次全量输出验证。写一个测试程序，把所有特殊地址都打印出来——0.0.0.0、255.255.255.255、::、::1、2001:db8::1、带端口和不带端口的混合场景。格式一旦错了，日志会非常误导人，这个自查习惯坚持下来，能省掉大量排查时间。

还有一点值得提醒：不要迷信网上的代码片段，尤其是sockaddr_in的手动初始化。很多博客里的代码连inet_pton的返回值都不检查，你抄过来就是在埋雷。BNF式地自己对照man 7 ip、man 7 ipv6、man 3 getaddrinfo过一遍，比东拼西凑强得多。

Address模块看起来是个不起眼的角落，但框架里每一层网络通信都依赖它。把它设计好、实现稳，相当于给整个高性能服务器框架打了一个坚实的地基。我这个版本在Linux生产环境跑了很久，最明显的变化是：再去扩展新的协议族时，几乎不用动上层代码，新增一个派生类就完事了。希望这篇拆解能让你在自己实现框架时少走点弯路，至少别在htons上栽跟头。