std::string::length() 返回字节数而非字符数，因UTF-8中汉字、emoji等占2~4字节；C++17起std::wstring_convert和std::codecvt_utf8已被弃用；推荐手动遍历识别UTF-8首字节模式计数。
为什么 std::string::length() 不能直接当字符数用
因为 std::string 存的是字节序列，UTF-8 中一个汉字、emoji 或某些符号占 2~4 字节，length() 返回的是总字节数，不是“人眼看到的字符个数”。比如 "??"（程序员 emoji）实际是 7 个字节，但算作 1 个 Unicode 码位（更准确说是 1 个 grapheme cluster，但多数场景按码位计就够用）。
用 std::wstring_convert + std::codecvt_utf8？别用了
这两个在 C++17 被标记为 deprecated，C++20 彻底移除。强行用会编译警告，且在 GCC/Clang 新版本上默认不启用，链接还可能失败。不是“过时但能跑”，而是“明确不推荐、不可靠”。
轻量方案：手动遍历 UTF-8 字节，识别首字节模式
UTF-8 编码有明确规则：首字节决定该字符占几个字节。只需检查每个字节的高位模式，跳过后续字节即可计数。不需要第三方库，也不依赖 locale。
- 0xxxxxxx → ASCII，1 字节
- 110xxxxx → 2 字节字符，后面 1 个 continuation byte（10xxxxxx）
- 1110xxxx → 3 字节字符，后面 2 个 continuation byte
- 11110xxx → 4 字节字符，后面 3 个 continuation byte
- 其他值（如 10xxxxxx、11111xxx）是非法 UTF-8，可按 1 字节错误处理（或跳过）
示例代码：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
int utf8_char_count(const std::string& s) {
int count = 0;
for (size_t i = 0; i < s.size(); ++i) {
unsigned char b = s[i];
if ((b & 0x80) == 0) {
count++;
} else if ((b & 0xE0) == 0xC0) {
count++;
i += 1; // skip next 1 byte
} else if ((b & 0xF0) == 0xE0) {
count++;
i += 2; // skip next 2 bytes
} else if ((b & 0xF8) == 0xF0) {
count++;
i += 3; // skip next 3 bytes
}
// 其余情况（如 0x80–0xBF、0xF8+）视为无效，不计数也不跳过（保持 i 自增）
}
return count;
}
需要精确 grapheme cluster（如带修饰符的 emoji）？得用 ICU 或 Boost.Text
上面的方法统计的是 Unicode 码位（code points）数量。但像 "??" 是由多个码位（man + zero-width joiner + laptop）组合成的单个视觉字符（grapheme cluster），普通遍历无法识别。这种需求极少出现在命令行工具或配置解析中，多见于富文本编辑器或国际化 UI。
-
ICU的BreakIterator可做 grapheme 边界分析，但体积大、编译麻烦 -
Boost.Text（C++17+）提供grapheme_iterator，更现代，但仍需额外依赖 - 绝大多数后端逻辑、日志统计、长度校验，用码位计数已足够；误判只发生在极少数带 ZWJ 或变体选择器的 emoji 组合
真正要小心的不是“选哪个库”，而是混淆 length()、size() 和“用户感知字符数”——这个边界一旦模糊，前端截断、数据库字段超长、正则匹配偏移错位就全跟着出问题。
