直接用 std::toupper 会出错，因为其 C 风格重载只接受 unsigned char 范围值，而 signed char 转 int 可能为负，导致未定义行为；正确做法是用 lambda 将参数声明为 unsigned char 再调用。
为什么直接用 std::toupper 会出错？
常见错误是写成 std::transform(s.begin(), s.end(), s.begin(), std::toupper)，然后程序崩溃或输出乱码。这是因为 std::toupper 有多个重载版本：C 风格的 int toupper(int)（只接受 unsigned char 范围内的值），而 std::string 的 char 可能是 signed 类型——当遇到像 'é' 或 ASCII 大于 127 的字节时，char 转成 int 会变成负数，传给 std::toupper 就触发未定义行为。
正确写法：强制转成 unsigned char 再调用 std::toupper
必须包裹一层 lambda 或函数对象，确保每个 char 先提升为 unsigned char，再传给 C 版本的 std::toupper：
std::transform(s.begin(), s.end(), s.begin(),
[](unsigned char c) { return std::toupper(c); });
关键点：
-
[](unsigned char c)显式声明参数类型，避免char符号问题 - 不要用
static_cast在 lambda 外做转换——lambda 参数类型本身就要是(c) unsigned char - 该方式只处理单字节字符（如 ASCII），对 UTF-8 多字节字符无效
如果字符串含非 ASCII 字符（比如中文、é、ñ），怎么办？
std::toupper 不支持 Unicode，它只按 locale 查表，且默认 "C" locale 下仅对 a–z 有效。实际项目中：
立即学习“C++免费学习笔记（深入）”；
- 若需真正国际化，别用
std::toupper—— 改用 ICU、Boost.Locale 或 C++20 的std::toupper模板重载（需配合std::locale） - 若只是临时处理英文路径/标识符，用上面的 lambda 安全又足够
- 注意：Linux/macOS 默认 locale 通常是
"en_US.UTF-8"，但std::toupper在 UTF-8 下仍不识别多字节，只会逐字节处理，结果不可靠
性能和可读性权衡：for 循环有时更清晰
对简单场景，显式循环反而不易出错，也更容易加条件判断（比如跳过数字或符号）：
for (char& c : s) {
if (c >= 'a' && c <= 'z') c -= 32;
}
优点：
- 无 locale 依赖，无符号转换陷阱
- 编译器通常能很好优化，性能不输
std::transform - 逻辑一目了然，改起来快
不过要注意：这种写法只适用于 ASCII 小写字母，不能替代通用大小写转换。
真正麻烦的不是怎么写，而是忘了 char 有符号性这回事——很多 bug 表现为在某些机器上正常，在另一些机器上乱码，根源就在这里。
