C 的指针强转“好用又危险”。它像一把瑞士军刀：紧急时刻能救你，但用错了照样会“自残”。本文不讲花哨技巧，专讲哪些转换是标准允许的、哪些会把你带进未定义行为（UB, Undefined Behavior）深坑，并配套可落地的写法与排雷清单。

一、先把地基打牢：三个关键概念

1）对象表示（object representation） 内存里只是比特位，怎么解释这些比特位由“类型”决定。转换指针，只是换了一副“解释眼镜”，并不会改变底层位模式。

2）有效类型（effective type） 对于通过 malloc 等得到的原始内存，在你第一次以某种类型写入之后，这块内存就“确立了有效类型”。之后若以不兼容的类型解读，可能触发 UB（除非符合特例，比如通过 unsigned char 访问）。

3）严格别名规则（strict aliasing） 优化器普遍假设：不同不兼容类型的指针不会指向同一对象。用“错类型”的指针别名访问，会让优化器做出错误推断，从而出现“明明看着没问题却跑飞”的诡异 bug。

二、哪些指针转换是“标准背书”的？

1. void* 与任意对象指针的互转（安全）

• 任意 T* 能无损转为 void*，void* 也能转回原始 T*。
• 这是 C 的通用“无类型指针”，配合 malloc/free 使用天经地义。
• 注意：函数指针不是对象指针，不能与 void* 安全互转（见后文）。

void *p = malloc(sizeof(double));
double *pd = p;           // OK
free(p);

2. 同类型或兼容类型之间的互转（安全）

• 典型如 int* 和通过 typedef 定义的别名类型指针。
• “兼容类型”并非“长得像就行”，它是标准语义层面的兼容；不同平台的 long 宽度可能不同，别拍脑袋。

3. char* / unsigned char* 读取任意对象表示（安全）

• 标准明确允许用 unsigned char*（或 char*、std::byte 在 C++ 中）逐字节探查/拷贝对象内容。
• 常用于序列化、哈希、内存快照。反之，将 char* 直接强转成别的类型去“带类型读写”，就涉险了。

double x = 3.14;
unsigned char *bytes = (unsigned char *)&x; // 安全地看字节
for (size_t i = 0; i < sizeof(double); ++i) printf("%02X ", bytes[i]);

4. 对齐无忧的 memcpy 型“类型双关”（安全）

• 想把 double 的位模式搬进 uint64_t 看一眼？用 memcpy，不要直接 (uint64_t*)&d 去读。
• memcpy 的语义让优化器无法“乱猜”，避开别名与有效类型陷阱。

uint64_t u;
double d = 3.14;
memcpy(&u, &d, sizeof u);   // 安全的位级重解释

三、红线与坑：这些转换高危甚至必炸

1.严格别名违规：不同不兼容类型的相互别名访问

float f = 1.0f;
int *pi = (int*)&f;
int v = *pi;   // 违反严格别名（UB），优化器可能重排/消除

规避：用 memcpy，或通过 unsigned char* 逐字节处理。

2.对齐不当（alignment）

某些类型要求更高对齐，随意把 char* 转成 double* 然后解引用，若地址不满足 _Alignof(double)，立即 UB。

char buf[16];
double *pd = (double*)(buf + 1); // 很可能未对齐
*pd = 3.14;                      // UB

规避：

• 使用 aligned_alloc（C11）、posix_memalign 或让编译器按类型对齐管理对象。
• 编译期守护：_Static_assert(alignof(MaxT) % alignof(MinT) == 0, "...");

3.抛弃限定符再写（const/volatile）

把 const int* 强转为 int* 并写入指向的是最初定义为 const 的对象时，这是 UB。

const int c = 42;
int *p = (int*)&c;
*p = 7;   // UB：对最初为 const 的对象写

只在你非常确定对象最初不是 const 且只是“路上加了 const”时，才可去除 const（例如从 void* 到 const T* 再去 const）。否则宁可复制。

4.对象指针 <-> 函数指针（禁止）

对象指针与函数指针互转是未定义的。某些平台地址空间分离，硬件层面都不通。

5.函数指针跨不兼容签名转换

不同函数类型的指针不能互调，即便实参个数与大小“看起来”一致也不行。 POSIX 的 dlsym 返回 void*，再转为目标函数指针是平台约定的做法，但属于实现定义/约定俗成，不是 ISO C 的普适保证。

6.整数 <-> 指针

只有当整数类型是 uintptr_t / intptr_t（足以无损承载指针）时，来回转换才有望可逆；否则信息可能丢失。 更隐蔽的是指针“来源”（provenance）：从无关整数构造的指针并不一定被视为“指向那个对象”，别拿它去解引用。

7.通过 union 做类型双关

C 中通过 union 读写不同成员在很多实现上“能用”，但可移植性差，常落入实现定义/未定义边界。 工程建议：不用 union 做类型双关，改用 memcpy。

四、真实的“翻车”案例

案例 A：优化器把你的“同步标志位”吃掉了

struct S { int ready; float payload; };
void work(struct S *s) {
    float *pf = (float*)&s->payload;
    if (s->ready) *pf = 1.0f;  // 与 int* / float* 别名冲突，触发严格别名
}

编译器可能认为 int 与 float 不会别名，从而把 ready 的读优化掉或重排。线上偶发故障，难以复现。 修复：把 ready 单独放到 atomic_int，或用字节序列化/memcpy。

案例 B：协议解析里的“对齐刺客”

#pragma pack(1)
struct Header { uint16_t id; uint32_t len; };
#pragma pack()  // 真实项目里经常 pack 成 1 字节对齐

void parse(const unsigned char *buf) {
    const struct Header *h = (const struct Header*)buf; // 可能未对齐
    // 在某些架构上直接解引用就崩溃
}

修复：从 buf 里按字节 memcpy 到对齐良好的本地 struct Header 再读；或用显式字节序读写。

五、哪些“看着危险，实则合规”的姿势？

1. container_of 模式（Linux 常用） 用 offsetof 计算成员偏移，从成员指针减回到外层结构体指针，配合 char* 做地址算术，这在 C 里是定义良好的“指针同一对象内加减”玩法，前提是该成员确实属于那个对象实例。

#define container_of(ptr, type, member) \
    ((type*)((char*)(ptr) - offsetof(type, member)))

2. void* 流转 + 最终回转原类型 设计接口时以 void* 承载不透明句柄，模块内再还原成具体 T*，只要保持同一生命周期与真实类型一致，就可移植且高效。
3. 字节层面的 hash/序列化 用 unsigned char* 或 memcpy 读取对象表示是可取的通路，但要明确字节序、填充字节（padding）与跨平台差异。

六、工程级安全策略（带示例）

策略 1：用 memcpy 代替指针重解释

float f;
uint32_t bits;
memcpy(&bits, &f, sizeof bits); // OK
// 反过来
memcpy(&f, &bits, sizeof f);    // OK

策略 2：对齐到位，写下断言

void *p = aligned_alloc(alignof(double), 1024);
assert(((uintptr_t)p % alignof(double)) == 0);
double *pd = p;   // 放心使用

策略 3：接口边界统一走 void* 或封装句柄

• 模块内部把真实类型“关起来”，导出只暴露 void* 句柄 + 明确的创建/销毁函数。
• 调用端不做“私自强转”。

策略 4：避免触发严格别名（或显式关闭，但不推荐）

• 编译选项 -fno-strict-aliasing 能“摆烂式”兜底，但牺牲优化且不可移植。
• 更好的办法是从源头按规则写。

策略 5：不要抛弃 const 去写

• 如果一定要写，确保对象最初不是以 const 定义的，且仅是中途加了限定符。

策略 6：函数指针要“签名对齐”

typedef int (*Handler)(const char*);
Handler h = (Handler)dlsym(handle, "foo"); // 依赖平台约定；签名必须匹配

七、最容易混淆的 10 条判断题（含答案）

1. double* <-> void* 互转并回转再解引用？——可以。
2. int* 强转 float* 去读之前写的 int？——不行（别名违规）。
3. char* 读取任意对象字节？——可以。
4. 任意地址转 double* 解引用？——看对齐，未对齐就是 UB。
5. 把 const int* 去 const 后写入源自 const 对象？——UB。
6. 对象指针 <-> 函数指针？——不行。
7. union 成员 A 写、成员 B 读做类型双关？——别用，风险大（实现相关）。
8. uintptr_t 保存指针再转回？——通常可以，但别滥用指针来源。
9. struct 成员指针做 container_of？——可以（同一对象内指针算术）。
10. void* 指向的真实类型与强转类型不一致也能读？——UB（除非只做字节访问）。

八、把规则固化成“工具箱宏/函数”

1）类型安全的读取（按位解释）

#define BIT_CAST(dst_type, src) \
    ({ dst_type _d; memcpy(&_d, &(src), sizeof(_d)); _d; })

uint64_t u = BIT_CAST(uint64_t, (double){3.14});

2）安全地从字节构造目标类型（含对齐断言）

bool load_double_aligned(const void *p, double *out) {
    if (((uintptr_t)p % alignof(double)) != 0) return false;
    memcpy(out, p, sizeof *out);
    return true;
}

3）封装的句柄 API

typedef struct DB DB;
DB* db_open(const char *path);   // 返回 DB*，外部仅以 void*/不透明句柄持有
void db_close(DB*);

九、结语：写给未来的你（和你的编译器）

指针强转本质上在和编译器的优化模型“博弈”。今天能跑、明天也许就会被优化“聪明反被聪明误”。把“位级重解释”交给 memcpy，把“地址运算”交给对齐良好的对象，把“接口边界”交给 void* 与清晰的创建/销毁语义——这些不是保守，而是与现代编译器和平共处的正确打开方式。

最后附上一张极简清单，贴在代码评审里当“指针转换门禁”：

• [ ] 这是 void* 与对象指针的互转吗？
• [ ] 会不会违反严格别名？若有疑虑→用 memcpy。
• [ ] 对齐满足 _Alignof(T) 吗？若不确定→改用复制。
• [ ] 是否抛弃了 const/volatile 再写？源对象最初是 const 吗？
• [ ] 有效类型是否匹配？是否首次写入就定型了？
• [ ] 函数指针签名完全一致吗？
• [ ] 是否涉及对象<->函数指针、或跨地址空间的假设？
• [ ] 代码能否用容器-of/字节访问/句柄封装替代？

守住这些边界，你的 C 指针世界会清爽很多。