为何`sockaddr`系列结构体用法类似union却未采用显式union设计？

你观察到的现象很准确：sockaddr_in（IPv4）、sockaddr_in6（IPv6）这类结构体的使用方式确实和union类似——通过指针类型转换传递给接收struct sockaddr*的API函数，实现类似多态的效果。但API没有采用显式union，主要有以下几个核心原因：

1. 历史兼容性与API演进 #

BSD套接字API最早诞生于1980年代，设计时的核心目标是最小化对现有代码的破坏。最初只有面向IPv4的sockaddr_in和通用的sockaddr，后来扩展IPv6时，如果改用union封装，就需要修改所有API的参数类型（从struct sockaddr*改成union sockaddr_union*），这会导致大量旧代码直接失效。而通过指针强转+开头的sa_family字段识别类型的方式，完全不需要改动现有函数签名，既能兼容旧代码，又能无缝支持新地址类型。

2. 更灵活的扩展性 #

显式union的成员是固定的，一旦定义就很难添加新的地址类型（比如Unix域套接字的sockaddr_un、蓝牙地址结构体等）。而用指针强转的方式，只要新的地址结构体开头第一个字段是sa_family_t类型的地址族标识，就能直接接入现有API。这种设计让套接字API可以轻松扩展到各种非IP地址类型，无需修改核心函数定义。

3. 精确的内存长度控制 #

套接字API的核心函数（比如bind()、connect()）都需要额外参数指定地址结构体的实际长度。如果用union，union的大小是其最大成员的大小，无法准确传递不同地址结构体的真实长度，可能导致内存读写错误。而手动传递长度+指针强转的方式，能让函数精确处理不同大小的结构体，避免内存浪费或越界。

4. 手动“标签联合”的实用性 #

C语言的union本身只是内存复用，没有内置类型识别能力，仍需额外的标签字段判断当前使用的成员。套接字结构体的设计本质是手动实现的标签联合：通过开头的sa_family字段作为标签，API函数内部根据这个值判断指针实际指向的结构体类型，进而做对应处理。这种方式和union的效果一致，但更灵活，且在当时各种编译器上的兼容性更好。

举个直观的对比例子：
用IPv4地址调用bind的常规写法：

struct sockaddr_in ipv4_addr;
// 初始化ipv4_addr的sin_family、sin_port、sin_addr等字段
bind(sockfd, (struct sockaddr*)&ipv4_addr, sizeof(ipv4_addr));

如果用union实现，代码会变成：

union {
    struct sockaddr sa;
    struct sockaddr_in sa_in;
    struct sockaddr_in6 sa_in6;
} addr;
addr.sa_in.sin_family = AF_INET;
// 其他初始化操作
bind(sockfd, &addr.sa, sizeof(addr.sa_in));

本质上还是依赖标签字段，且union方式限制了可扩展的地址类型，还会带来不必要的内存占用（若某个地址结构体特别大，union的大小会被它撑大）。

内容的提问来源于stack exchange，提问作者user2138149