char 的符号性由编译器决定：GCC/Clang/MSVC 默认有符号，但 -funsigned-char 或嵌入式平台可能使其无符号；使用时需注意位运算、序列化及标准库函数（如 std::isdigit）的未定义行为风险。
char 是有符号还是无符号？取决于编译器
这问题没有统一答案：char 在 C++ 标准里是独立类型，既不是 signed char 也不是 unsigned char，但它的底层表示和默认符号性由编译器决定。GCC 和 Clang 默认把 char 当作有符号（signed char），MSVC 默认也是有符号；但某些嵌入式平台或加了 -funsigned-char 时，它就变成无符号。
容易踩的坑：
- 用
char当整数做位运算或比较时，比如if (c > 0x80)，在有符号环境下会触发符号扩展，结果出人意料 - 序列化二进制数据时，
char*和unsigned char*混用可能让memcmp或memcpy行为正常，但调试打印时printf("%x", c)会因符号性打出ffffff80这种补码形式 - 标准库函数如
std::isdigit要求参数是unsigned char或 EOF，直接传char可能导致未定义行为（尤其当值为负时）
wchar_t 大小不固定，别硬编码 2 或 4
wchar_t 的大小完全由实现定义：Windows 上是 16 位（对应 UTF-16），Linux/macOS 通常是 32 位（对应 UCS-4）。这意味着 sizeof(wchar_t) 可能是 2 或 4，不能假设。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 跨平台代码里写
std::wstring s(100, L'x')然后用memcpy(buf, s.c_str(), 200)—— 在 Linux 上实际拷了 400 字节，溢出 - 用
wchar_t[256]存路径，再调CreateFileW（Windows）没问题，但换到 Linux 调openat(AT_FDCWD, ...)时，宽字符路径根本不可用 - 误以为
wchar_t天然支持 UTF-8 或 UTF-16：它只是“宽字符”，编码语义由你和 API 共同约定，标准库几乎不提供编码转换
char8_t / char16_t / char32_t 是真正的 UTF 定长类型
C++20 引入这三个类型，明确绑定 Unicode 编码宽度：char8_t 是 8 位（用于 UTF-8 字节），char16_t 是 16 位（UTF-16 code unit），char32_t 是 32 位（UTF-32 code point）。它们和 uint8_t、uint16_t 等价，但语义上专用于文本。
使用场景与注意事项：
- 读文件后想明确按 UTF-8 解析？用
std::u8string（即std::basic_string<char8_t></char8_t>），而不是std::string+ 注释“这是 UTF-8” - 和 Windows API 交互需 UTF-16？优先用
std::u16string+std::wstring_convert<:codecvt_utf16>></:codecvt_utf16>（注意：C++20 废弃了codecvt，得用第三方如 ICU 或手写转换） -
char32_t能完整表示任意 Unicode 字符（U+0000–U+10FFFF），但一个char32_t不等于“一个用户感知的字符”（比如带 emoji modifier 的 ?? 是多个 code point） - 不要混用：
u8"abc"是const char8_t[4]，而"abc"是const char[4]，类型不同，不能隐式转换
实际项目中怎么选？看输入源和目标 API
没有银弹，选型取决于你对接什么。磁盘文件、网络协议、JSON 文本基本都用 UTF-8，那 std::string + char8_t（C++20）最自然；GUI 框架或系统 API 要求宽字符串，就得按平台走：std::wstring（Windows）、std::u32string（Linux GUI 库如 Qt 有时倾向 UTF-32）。
关键提醒：
- 别为了“国际化”盲目全切
wchar_t：Linux 下它没带来便利，反而增加转换开销和兼容性问题 -
std::string不是“ASCII 专用”，只要内容是合法 UTF-8 字节序列，它就是合格的 Unicode 容器（Python 3 的str也是类似思路） - 所有转换（UTF-8 ↔ UTF-16 ↔ UTF-32）都不是零成本操作，频繁转换比用错类型更伤性能
最常被忽略的一点：字符类型只是容器，真正决定文本行为的是你用的编码库、正则引擎、排序规则（locale）——类型选对了，这些环节没跟上，照样乱码或崩掉。
