char 既不是有符号也不是无符号，而是独立类型，其符号性由编译器实现定义；GCC/Clang 默认 signed，部分嵌入式工具链默认 unsigned，导致同一代码行为不一致。
char 到底是有符号还是无符号？取决于编译器
标准 C++ 没有规定 char 必须是有符号或无符号，它是个独立类型，可等价于 signed char 或 unsigned char，由实现决定。GCC/Clang 默认把 char 当作 signed char（最高位当符号位），而 MSVC 也是 signed，但某些嵌入式工具链（如 ARM GCC 的 -funsigned-char）会把它当作 unsigned char。
这意味着同一段代码在不同平台或编译选项下，char c = 0xFF; 可能是 -1，也可能是 255 —— 不是 bug，是标准允许的“实现定义行为”。
- 用
char存纯字符（如'A'、'\n'）基本没问题，因为 ASCII 范围（0–127）在 signed/unsigned 下都一致 - 一旦做数值计算（比如位移、比较、算术运算），结果就可能因符号扩展出问题
- 跨平台库（尤其是网络协议、二进制序列化）里，别依赖
char的符号性；该用int8_t或uint8_t就明确用
signed char 和 unsigned char 的底层存储完全一样，但解释方式不同
三者都是 1 字节（sizeof(char) == sizeof(signed char) == sizeof(unsigned char) == 1），内存比特完全一致，区别只在“怎么读”。比如内存里存着 0b10000000：
-
signed char解释为 -128（补码） -
unsigned char解释为 128 -
char解释为什么，看编译器——你没法从源码一眼判断
这种差异在强制转换时特别明显：(int)(signed char)0xFF 是 -1，而 (int)(unsigned char)0xFF 是 255。很多越界读写 bug（比如 memcpy 后 memcmp 失败）就源于这里隐式转换时的符号扩展。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
什么时候必须显式选 signed char 或 unsigned char？
当你需要确定的数值范围、避免符号扩展、或对接外部二进制数据时，就不能靠 char 碰运气。
- 处理原始字节流（如文件头、网络包）：用
unsigned char*，避免负值干扰位操作和比较 - 做小整数运算且需负数（如音频采样偏移）：用
signed char，语义清晰 - 声明数组索引或计数器（0–255）：用
unsigned char，避免和int混合运算时意外触发符号扩展 - 调用 C 函数如
memcmp、memcpy：它们参数是const void*，但传入char*时，若原数据本意是无符号字节，却用char*指针，后续再转成unsigned char*就可能触发未定义行为（严格别名规则）
一个容易被忽略的坑：char 数组初始化与 memset
写 char buf[1024] = {0}; 看似安全，但如果后续用 memset(buf, 0xFF, sizeof(buf))，再拿 buf[0] 当数值用，它的值到底是 -1 还是 255，又回到第一个问题——取决于 char 的符号性。
更隐蔽的是：有些调试器或内存查看工具默认按 unsigned char 显示内存，而你的代码逻辑按 signed char 判断，结果对不上。
- 初始化字节数组建议统一用
std::array<unsigned char n></unsigned>或uint8_t buf[N] - 用
std::vector<uint8_t></uint8_t>替代std::vector<char></char>处理二进制数据 - 如果必须用
char（比如兼容 C 接口），至少加注释说明：“此处 char 视为字节，不参与符号运算”
真正麻烦的不是记不住区别，而是忘了自己当初为什么选了 char —— 它既像字符，又像数字，还像内存块，但哪一种都不是完全安全的。
