直接用会崩，因为std::toupper要求输入为unsigned char范围内的值，而char在某些平台默认有符号，传入负数会导致未定义行为；正确做法是用lambda封装unsigned char转换。
std::transform + std::toupper 为什么直接用会崩？
直接写 std::transform(s.begin(), s.end(), s.begin(), std::toupper) 很可能触发未定义行为——std::toupper 的 int 版本要求输入必须是 unsigned char 范围内的值（0–255），而 char 在某些平台默认是有符号的，遇到像 'é' 或高位字节（如 UTF-8 多字节中的非首字节）就会传入负数，导致越界查表。
常见现象：程序在某些字符串上崩溃、输出乱码、或静默出错（尤其在开启优化后）。
- 必须把每个
char显式转成unsigned char再喂给std::toupper - 只适用于单字节编码（如 ASCII、ISO-8859-1），不支持 UTF-8 中文、emoji 等多字节字符
- 若字符串含非字母字符（数字、标点、空格），
std::toupper会原样返回，这点是安全的
正确写法：lambda 封装 unsigned char 转换
最稳妥的做法是用 lambda 包一层转换逻辑，避免依赖全局命名空间重载歧义，也绕过 C 头文件函数签名陷阱：
std::string s = "Hello, 世界!";
std::transform(s.begin(), s.end(), s.begin(),
[](unsigned char c) { return std::toupper(c); });
// 结果: "HELLO, 世界!"（注意：中文不变，因为 toupper 对非 ASCII 字符无效果）
- lambda 参数类型必须是
unsigned char，不能是char或int - 不要用
static_cast<unsigned char></unsigned>在调用外强转——那会截断，应在 lambda 参数声明时就定死类型 - 如果用
<locale>和 facet（比如std::use_facet<std::ctype<char>>(loc).toupper(...)），能支持 locale-aware 转换（如土耳其语），但开销大，且仍不解决 UTF-8
遇到 UTF-8 字符串怎么办？别硬刚 toupper
标准库没有 UTF-8 感知的大小写转换。强行对 UTF-8 字节流调用 std::toupper 会导致部分字节被错误修改，破坏编码结构，后续解析直接失败。
立即学习“C++免费学习笔记（深入）”；
- 确认你的字符串确实是 UTF-8 编码（而不是系统 locale 默认编码）
- 需要真正处理 Unicode 大小写，得用专业库：
icu（重量）、utf8cpp（轻量但需手动拆分码点）、或boost::locale - 简单场景可先用
std::isalpha+std::toupper判断是否为 ASCII 字母再处理，跳过所有非 ASCII 字节（即保持中文、日文等原样）
性能与可读性权衡：for 循环有时更清楚
当逻辑不复杂、且团队里有人不熟悉 STL 算法时，显式循环反而更易排查问题：
for (char& c : s) {
if (c >= 'a' && c <= 'z') {
c -= 'a' - 'A'; // 比 toupper 更快，且无符号问题
}
}
- ASCII 范围内，减法比函数调用快，也完全规避
unsigned char转换问题 - 但失去 locale 支持（比如德语 ß 不会转为 SS），也不处理带重音的拉丁字母（如 à → À）
- 如果项目明确只跑英文环境、追求极致简单，这个写法更直白可靠
实际用哪一种，取决于你字符串的真实编码、是否要支持国际化、以及团队对可维护性的偏好。最危险的不是不会写，而是忘了 char 有符号性这回事。
