最平衡的选择是 std::transform 配合 std::toupper；需将 char 转为 unsigned char 避免 UB；str.data() 是安全获取缓冲区的唯一标准方式；查表法仅适用于纯 ASCII 高频场景；UTF-8 和 locale 特殊字符需专用库处理。
直接用 std::transform 配合 std::toupper 是最平衡的选择：安全、可读、标准兼容，且在绝大多数场景下性能足够。真正需要“极致速度”或“原生字节缓冲区直写”的，只出现在高频网络/加密/多媒体处理等 hot path 中——此时才值得引入查表法或 AVX2。
为什么不能直接用 std::toupper(c) 传 char？
因为 char 在多数平台（如 x86_64 Linux）默认是有符号类型，非 ASCII 字节（比如高位为 1 的字节）会被解释为负数，而 std::toupper 要求参数是 unsigned char 范围内的值（0–255）或 EOF。传入负值会触发未定义行为（UB），可能崩溃、静默出错或产生随机结果。
- 错误写法：
[](char c) { return std::toupper(c); } - 正确写法：
[](unsigned char c) { return std::toupper(c); }或static_cast<char>(std::toupper(static_cast<unsigned char>(c)))</unsigned></char> - 即使字符串只含 ASCII，也建议统一加
static_cast<unsigned char></unsigned>—— 编译器不会帮你防平台差异
str.data() vs &str[0]：获取原生缓冲区的唯一安全方式
str.data() 是唯一能安全拿到底层字节缓冲区指针的标准方法；&str[0] 在空字符串时是未定义行为，哪怕当前编译器没报错，也不能依赖。
-
str.data()在 C++11 起保证返回合法指针（空串也返回有效地址），零开销 -
str.c_str()保证末尾有'\0'，但可能触发内部 null 插入（极少数实现），不适用于纯字节流场景 - 若你需要可写缓冲区（比如填充 recv() 数据），
std::string默认不提供；const_cast<char>(str.data())</char>仅在确认无 COW、无共享 const 引用、且已调用str.resize(n)确保容量足够时才勉强可用 - 更稳妥的做法：改用
std::vector<char></char>，它天然支持vec.data()可写视图
查表法提速：什么时候值得自己写 kToUpperMap？
查表法（constexpr unsigned char kToUpperMap[256]）比 std::toupper 快 3–5×，但只对纯 ASCII 字符有效，且牺牲了 locale 感知能力。它适合明确知道输入不含非 ASCII 字符、且吞吐量敏感的场景（如 HTTP header 解析、日志预处理）。
立即学习“C++免费学习笔记（深入）”；
- 表必须覆盖全部 256 个
unsigned char值，非小写字母字节保持原值（例如0x80–0xFF不变），否则查表越界就是 UB - 遍历必须用
unsigned char索引：buf[i] = kToUpperMap[(unsigned char)buf[i]] - 超 4KB 缓冲区可启用 AVX2 向量化，但需检查对齐、处理尾部字节，且丧失可移植性（ARM、Apple Silicon 不支持）
- 别为了“看起来快”而盲目上查表——90% 的业务代码里，
std::transform已经够快，且更易维护
UTF-8 和 locale 特殊字符根本不在标准库处理范围内
std::toupper、查表法、std::ctype::toupper 全部按字节操作，对 UTF-8 多字节序列（如 "café"、"İstanbul"）完全无效。它们会把 UTF-8 编码的每个字节单独转大写，结果是乱码。
- 德语
ß→"SS"、土耳其语'i'→'İ'这类映射，必须通过std::locale+std::ctypefacet，但代价是虚函数调用开销，且仍不解析 UTF-8 - C++ 标准库至今（C++20）没有 UTF-8 安全的大小写转换设施
- 真实国际化需求，请用 ICU、Boost.Text 或 utf8cpp；临时 workaround 是先转
std::u32string再用std::towupper，但std::wstring_convert已被弃用 - 如果输入来源可控（如只来自 ASCII 协议字段），就别碰 locale 和 UTF-8 —— 越简单越可靠
真正容易被忽略的点不是“怎么写”，而是“边界在哪”：空字符串、非 ASCII 字节、可写性假设、UTF-8 误判、locale 切换副作用……这些地方一松懈，就从“快速安全”滑向“偶发崩溃”或“线上乱码”。
