能，std::string 可直接存储 utf-8 字符串，因其本质是字节容器；但需注意 length() 返回字节数而非码点数，遍历时不可用下标随机访问单个 unicode 字符。
std::string 能不能直接存 UTF-8 字符串
能，而且应该这么用。UTF-8 是字节序列，std::string 本质就是 std::vector<char></char>，天然适配——只要你不把它当“字符数组”去用 str[i] 随便索引。
常见错误现象：str.length() 返回的是字节数，不是 Unicode 码点数；循环遍历时用 for (int i = 0; i 取 <code>str[i]，结果切在 UTF-8 多字节中间，得到乱码或 0xC0 类非法首字节。
- 真正需要“按字符遍历”时，必须手动解析 UTF-8 字节流（查首字节高位模式，跳过后续字节）
- 用
std::u8string（C++20）可语义化表示 UTF-8 字符串，但底层仍是char8_t数组，不自动提供码点迭代 - 别把
std::string传给只接受const char*且内部做strlen或单字节扫描的 C 函数（比如老式正则库），它们会误判长度或崩溃
Windows 上 std::ofstream 写 UTF-8 文件为啥开头多出 0xEF 0xBB 0xBF
那是 BOM（Byte Order Mark），Windows 许多工具（记事本、PowerShell Get-Content）默认加的，但 C++ 标准库本身不写 BOM——是你显式写了，或者用了带 BOM 的宽字符流（比如 std::wofstream + std::codecvt_utf8）。
使用场景：纯文本日志、配置文件、跨平台数据交换。BOM 在 Linux/macOS 下反而容易被脚本误读为非法字符。
立即学习“C++免费学习笔记（深入）”；
- 确保用
std::ofstream（非wofstream），以std::ios::binary模式打开，直接写std::string原始字节 - 绝对不要用
std::codecvt_utf8<wchar_t></wchar_t>（已弃用）或std::locale绑定编码转换 facet，它在 MSVC 和 GCC 行为不一致，且可能悄悄插 BOM - 如果必须用宽字符接口（如调 Windows API），先用
std::wstring_convert<:codecvt_utf8>></:codecvt_utf8>（C++11~17）或手动 UTF-8 编码函数转成std::string再写
Linux/macOS 下 setlocale(LC_ALL, "") 对 UTF-8 有用吗
基本没用。它只影响 C 标准库的 printf、strcoll 等少数函数的区域行为，不改变 std::string 或 I/O 流的编码解释逻辑。
性能 / 兼容性影响：调用它可能触发 locale 数据加载，在容器或嵌入式环境里引发不可预知延迟；某些精简版 libc（musl）甚至忽略该调用。
std::cout 能否正确显示，取决于终端是否设为 UTF-8（<code>locale命令输出含UTF-8），和 C++ 程序无关- 排序、大小写转换等国际化操作，
std::locale默认 facet 不支持 UTF-8，必须用 ICU 或std::experimental::filesystem（C++17）外的第三方库 - 别在多线程程序里全局调
setlocale，它不是线程安全的
怎么安全地从 UTF-8 std::string 提取一个 Unicode 码点
没有标准库函数直接做这事。C++20 的 std::mbrtoc8 还没落地，目前只能手撸或依赖轻量库（如 utf8cpp）。
容易踩的坑：用 std::wstring_convert<:codecvt_utf8>></:codecvt_utf8> 转整个字符串再取 [0]，既低效又危险——输入非法 UTF-8 时行为未定义（GCC 可能抛异常，MSVC 可能静默截断）。
- 检查首字节：
0x00–0x7F是 ASCII；0xC0–0xDF是 2 字节；0xE0–0xEF是 3 字节；0xF0–0xF4是 4 字节；其他值非法 - 验证后续字节是否在
0x80–0xBF范围，否则立即报错或跳过 - 组合字节得码点后，检查是否在 Unicode 有效范围（
0x0000–0xD7FF,0xE000–0x10FFFF），排除代理对和保留区
这事看着简单，但边界条件多。真要频繁操作码点，不如用 utf8cpp 的 utf8::next —— 它处理了所有异常路径，比自己写更可靠。
