C语言性能瓶颈场景下复制两个相邻字节的最快方法咨询
Hey Hank，刚好之前在性能敏感的嵌入式代码里折腾过类似的字节复制问题，咱们来逐个拆解你提到的三种方法，最后给你性能瓶颈场景下的最优选择：
1. memcpy 写法
memcpy(Ptr, (const char[]){'a', 'b'}, 2);
你担心的编译器优化问题完全在理！虽然像GCC这种主流编译器会把2字节的memcpy直接优化成 inline 的赋值操作，但如果是移植到一些小众、老旧的编译器上，它真的会调用完整的memcpy函数——那可是要做栈帧、跳转、长度判断这些额外操作的，在性能瓶颈场景下绝对是拖后腿的。所以这个方法不推荐在性能敏感代码里用，除非你能100%锁定编译器会帮你优化掉函数调用。
2. 逐字节赋值
Ptr[0] = 'a'; Ptr[1] = 'b';
这个方法最大的优点就是稳——没有任何库依赖，语义直白到谁都能看懂，任何编译器都能正确处理。虽然是两条赋值指令，但现代CPU的指令并行执行能力很强，这两条指令大概率会被同时处理，开销其实小到可以忽略。唯一的“缺点”就是看起来不够“酷”，但在性能瓶颈下，稳比酷重要得多，而且它完全没有未定义行为的风险。
3. 原始类型双关写法
*(uint16_t*)Ptr = *(uint16_t*)(unsigned char[]){'a', 'b'};
这个写法看似是用一条16位赋值指令完成操作，效率拉满，但其实藏着两个致命坑：
- 字节序炸弹：如果你的目标平台是大端序，
'a'（0x61）和'b'（0x62）会被拼成0x6162还是0x6261？不同平台字节序不一样，直接这么写会导致复制结果在跨平台时完全错乱。 - 违反严格别名规则：C标准里有个“严格别名”的规矩——不能用非char类型的指针去访问另一种类型的对象。你把char强制转成uint16_t去赋值，属于踩了这个规矩的红线，编译器可能会给你生成奇奇怪怪的代码（比如直接优化掉这个操作），甚至触发内存访问异常，完全是未定义行为，绝对不能碰。
那有没有既高效又安全、还能兼顾可移植性的方法？当然有，分几种情况给你推荐：
情况1：允许用编译器内置函数（优先选这个）
很多主流编译器（比如GCC、Clang）都提供了__builtin_memcpy这种内置函数，它会被强制优化成 inline 的指令，不会调用库函数，同时还能帮你处理字节序和对齐问题：
__builtin_memcpy(Ptr, (const char[]){'a', 'b'}, 2);
这个方法兼顾了语义清晰、性能拉满和可移植性，完全不用你操心编译器优化的问题，是性能敏感场景下的首选。
情况2：必须严格遵循标准C，且要跨平台
那就选逐字节赋值Ptr[0]='a'; Ptr[1]='b';——别小看这两条指令，现代CPU的执行效率极高，指令并行会把它们的开销降到几乎可以忽略，而且绝对安全，没有任何坑。如果是在高频循环里，编译器甚至可能把这两条指令合并成更高效的操作，完全不用你担心。
情况3：针对特定平台，且内存地址对齐
如果你的代码只跑在特定平台（比如x86小端序），而且Ptr的地址是uint16_t的对齐地址（比如2字节对齐），那可以用字节序适配后的常量直接赋值，同时用union来避免严格别名问题：
#include <stdint.h> // 针对小端序平台定义常量 #define AB_VALUE ((uint16_t)('a' | ('b' << 8))) // 用union做安全的类型双关 union { char bytes[2]; uint16_t word; } u = {.word = AB_VALUE}; Ptr[0] = u.bytes[0]; Ptr[1] = u.bytes[1]; // 如果Ptr是对齐的uint16_t*，可以直接这么写（仅特定平台） // *(uint16_t*)Ptr = AB_VALUE;
这个方法能做到单指令赋值，但前提是你要确保平台字节序和内存对齐都没问题，否则还是会踩坑。
- 优先用编译器内置函数
__builtin_memcpy，兼顾性能、安全和可移植性； - 严格标准C就选逐字节赋值，稳得一批，开销几乎可以忽略；
- 特定平台且对齐没问题的话，再考虑字节序适配后的单指令赋值；
- 绝对不要用原始的类型双关写法，坑太多！
内容的提问来源于stack exchange，提问作者user14020710
