直接用 std::transform 配 ::toupper 或 std::toupper 会因 char 符号性导致未定义行为，正确做法是用 lambda 显式转换为 unsigned char 再调用 std::toupper。
直接用 std::transform 配 ::toupper 或 std::toupper 是可行的，但不加类型保护会出未定义行为——尤其在含非 ASCII 字符或不同平台编译时，字符串可能乱码、崩溃或结果不一致。
为什么 std::transform(s.begin(), s.end(), s.begin(), ::toupper) 有时会崩
因为 ::toupper 的 C 风格重载只接受 int 值，且语义上仅对 unsigned char 范围（0–255）及 EOF 有定义。而 char 在多数 x86_64 Linux/macOS 编译器下默认是 signed char；一旦字符串里出现字节值 >127（比如 UTF-8 中文、é、ñ 的某个字节），char 转 int 就变成负数，传给 ::toupper 就触发未定义行为。
- 现象：程序在本地跑正常，CI 上 segfault；或输出中部分字符变空/乱码
- 根本原因不是
transform错，而是参数类型没兜住 - 正确写法必须显式把每个
char当作unsigned char处理
std::transform + lambda 强制 unsigned char 是最稳写法
用 lambda 显式声明参数为 unsigned char，再调 std::toupper，可彻底避开符号扩展陷阱：
std::string s = "Hello, 世界!";
std::transform(s.begin(), s.end(), s.begin(), [](unsigned char c) {
return std::toupper(c);
});
- 必须写
[](unsigned char c)，不能写[](char c)或在外面static_cast - 头文件要全：
<algorithm>、<string>、<cctype> - 该方式仍只按字节处理，对 UTF-8 多字节字符无效（如“世界”不会变大写，因为 UTF-8 中文没有大小写概念）
- 若需真正 Unicode 支持，得换
std::toupper模板重载 +std::locale，或上 ICU/Boost.Locale
就地转换 vs 新建字符串：两种常见需求怎么选
原地改还是生成新串，取决于是否要保留原始值。两者性能差异极小，但语义和安全性不同：
立即学习“C++免费学习笔记（深入）”；
- 就地转换（推荐用于临时处理）：
std::transform(s.begin(), s.end(), s.begin(), [](unsigned char c){return std::toupper(c);}); - 新建字符串（推荐用于 API 输入、不可变逻辑）：
std::string upper; upper.reserve(s.size()); std::transform(s.begin(), s.end(), std::back_inserter(upper), [](unsigned char c){return std::toupper(c);}); - 别用
upper.resize(s.size())+upper.begin()，除非你确定s非空；空串时resize(0)后begin() == end()，transform行为未定义
ASCII 场景下，for 循环反而更直白可靠
如果明确只处理纯 ASCII（比如环境变量名、HTTP header、路径片段），手动循环比 transform 更易读、无 locale 依赖、也避免任何隐式转换风险：
for (char& c : s) {
if (c >= 'a' && c <= 'z') c -= 32;
}
- 不依赖
<cctype>，不关心当前 locale 设置 - 编译器对这种简单分支+算术优化极好，实测性能不低于
transform - 缺点：硬编码了 ASCII 规则，遇到
é、ñ等带重音字母完全不管——这反而是优点：你清楚知道它只动 a–z
最容易被忽略的其实是 char 的符号性——它不随代码写得“看起来没问题”而自动消失；只要涉及字节级操作，就得主动把它当作 unsigned char 来对待，否则跨平台、跨编译器就是定时炸弹。
