std::toupper和std::tolower仅作用于单个字符，需遍历string并用static_cast<unsigned char>安全转换；默认不支持locale和UTF-8，复杂场景须依赖ICU等外部库。
std::toupper 和 std::tolower 不能直接处理 std::string
它们只作用于单个 char，传入 std::string 会编译失败或静默截断——常见错误是写成 std::toupper(s)，结果只转了首字符甚至触发未定义行为。
正确做法是遍历每个字符，逐个转换。注意：这两个函数接受 int（非 char），且对负值（如带符号 char 的高位字节）行为未定义，所以必须先转成 unsigned char 再传入。
- 用
for (auto& c : s)遍历时，c必须是引用（&），否则修改的是副本 - 转换前加
static_cast<unsigned char>(c)</unsigned>，避免在某些平台（如 ARM 或老 GCC）上出错 - 别忘了包含
<cctype>，不是<ctype.h>
std::string s = "Hello123";
for (auto& c : s) {
c = std::toupper(static_cast<unsigned char>(c));
}
locale-aware 转换要用 std::use_facet<std::ctype<char>>
默认的 std::toupper 只处理 ASCII，遇到德语 ß、土耳其语 i/I 映射、或 UTF-8 多字节序列时完全失效。真要支持 locale，得走 facet 路线，但代价不小：每次调用都涉及虚函数分发，且 std::string 本身不存编码信息，UTF-8 字符串会被当单字节乱切。
- 仅当明确需要按系统 locale（如
setlocale(LC_CTYPE, "tr_TR.UTF-8")）做转换时才考虑 - 必须用
std::locale对象获取 facet，不能直接用全局 locale（std::locale()可能不是当前 C locale） - 对 UTF-8 字符串，这个方案依然无效——它只按字节操作，不解析 Unicode 码点
std::locale loc("en_US.UTF-8");
const auto& ct = std::use_facet<std::ctype<char>>(loc);
std::string s = "hello";
ct.toupper(&s[0], &s[0] + s.size());
UTF-8 字符串大小写转换没有标准库解法
C++20 没有内置 UTF-8 处理，std::toupper 和 facet 全部退化为字节级操作。想正确转换 “café” → “CAFÉ” 或 “İstanbul” → “iSTANBUL”，必须依赖外部库或手写 UTF-8 解码逻辑。
立即学习“C++免费学习笔记（深入）”；
-
std::string是字节容器，不是字符串容器；大小写转换本质是 Unicode 码点映射，不是字节映射 - ICU、Boost.Text、utf8cpp 是常见选择，但引入 ICU 会显著增加构建复杂度和二进制体积
- 简单场景可先用
std::wstring_convert<std::codecvt_utf8<char32_t>>（已弃用但尚可用）转成std::u32string，再用std::towupper，但要注意 Windows 上char32_t与 wchar_t 不兼容
性能敏感场景别在循环里反复查 locale 或 new 对象
有人把 std::use_facet 放进循环，或每次调用都构造新 std::locale，这会让吞吐量掉一个数量级。facet 查找是 map 查找，locale 构造涉及内存分配和系统 API 调用。
- 把
const auto& ct = std::use_facet<...>(loc)提到循环外，复用 facet 引用 - locale 对象本身可缓存（它是轻量的），不要每次从
std::locale("")重建 - 纯 ASCII 场景下，手写查表（256 元素数组）比
std::toupper快 3–5 倍，且无 locale 开销
std::string 和“字符串”根本不是一回事——它不携带编码，也不承诺内容合法。越早接受这点，越少在深夜对着 “İstanbul”.size() == 10 发呆。 
