C++标准库无字符串转大写三合一函数，必须分步处理；最稳妥做法是用std::transform遍历std::string，lambda中将char强转为unsigned char再调用std::toupper，仅对ASCII有效，UTF-8需ICU等库支持。
用 std::toupper 配合 std::transform 最稳妥
直接遍历修改每个字符并调用 std::toupper 是常见做法，但必须注意：该函数只接受 unsigned char 范围内的值（0–255），传入负值（如某些 locale 下的 char）会导致未定义行为。
实操建议：
- 始终将
char强转为unsigned char再传给std::toupper - 使用
std::locale参数可支持 locale-aware 转换（比如土耳其语中i→İ），但默认 C locale 已满足大多数 ASCII 场景 - 对
std::string原地转换时，确保字符串非 const（即不能对字面量或const std::string&直接操作）
std::string s = "Hello World!";
std::transform(s.begin(), s.end(), s.begin(),
[](unsigned char c) { return std::toupper(c); });
// 结果: "HELLO WORLD!"
为什么不能直接用 std::toupper(int) 不加转换？
在有符号 char 为默认类型的平台（如大多数 x86_64 Linux/gcc），字符串中若含高位为 1 的字节（例如 UTF-8 多字节序列里的后续字节），会被解释为负数。此时传给 std::toupper 会触发未定义行为 —— 可能崩溃、返回异常值，或静默出错。
典型错误现象：
立即学习“C++免费学习笔记（深入）”；
- 程序在调试模式下正常，Release 模式下某次运行突然 segfault
- 处理含中文、emoji 的 UTF-8 字符串时，部分字节被误转成控制字符（如
\x00或\xFF） - Clang/UBSan 报告
std::toupper argument is out of range
遇到非 ASCII 字符（如中文、á、ß）怎么办？
std::toupper 在 C locale 下只处理 A–Z（ASCII 65–90），其余字符原样返回。它不支持 UTF-8 解码，因此对 "café" 中的 é 或 "你好" 完全无效 —— 不报错，也不改变。
如果真需 Unicode 大写转换：
- 不要自己解析 UTF-8；用成熟库如
icu、boost::locale或 C++20 的std::text_encoding（尚未广泛支持） - 简单场景可先用
std::wstring_convert（已弃用）或手动 UTF-8 解码 + ICUu_strToUpper，但复杂度陡增 - 多数服务端逻辑其实只需 ASCII 大写（如 HTTP header、SQL identifier 规范化），此时坚持 C locale +
unsigned char转换最轻量可靠
性能和兼容性提醒
在循环内反复调用 std::toupper 本身开销极小，瓶颈通常在内存访问模式。但要注意：
- MSVC 的
/utf-8编译选项不影响std::toupper行为，它仍按 C locale 工作 - Linux 上
LC_CTYPE=en_US.UTF-8环境下，std::toupper对非 ASCII 字符仍不生效 —— 这是标准规定，不是 bug - 若字符串很长（>1MB），考虑用 SIMD 手动向量化（如 AVX2 处理 32 字节/次），但需自行判断是否值得
真正容易被忽略的是：哪怕你只处理英文，只要代码可能跑在不同 locale 环境（如容器镜像里 locale 是 C.UTF-8），也得显式指定 std::locale("C") 避免意外依赖环境变量。
