直接调用 simdutf::validate_utf8 可快速布尔校验 UTF-8 合法性，它不解析不转换、基于 SIMD 批量处理，但需确保输入指针有效且长度非负，避免误将空输入判为编码错误。
怎么用 simdutf 快速判断一段字节是不是合法 UTF-8
直接调用 simdutf::validate_utf8，它不解析、不转换，只做布尔校验，比手写循环或用 ICU 快一个数量级。内部用 SIMD 指令批量检查，对齐和非对齐输入都处理得当。
常见错误是传入空指针或长度为 0 的缓冲区——simdutf::validate_utf8 不会崩溃，但返回 false；这容易被误判为编码错误。务必先确保指针有效、长度非负。
- 使用场景：HTTP 请求头解析前快速过滤非法 payload、日志预检、文件头 sniffing
- 注意
const char*必须指向真实内存，不能是 string_view.data() 后 string_view 已析构 - 如果只需判断“是否可能为 UTF-8”，别用
detect_encodings——它开销大且不保证精度
把 GBK 或 Latin-1 字节流转成 UTF-8，simdutf 能不能做
不能。simdutf 只处理 Unicode 编码族之间的转换（UTF-8 ↔ UTF-16 ↔ UTF-32），不支持 GBK、Big5、Shift-JIS 等 legacy 编码。强行传 GBK 字节给 convert_utf8_to_utf16 会触发断言失败或返回空结果。
正确做法是分两步：先用专用库（如 iconv、Boost.Text 或轻量级 utf8cpp 配合 Windows-1252 表）转成 UTF-16/UTF-32，再用 simdutf::convert_utf16le_to_utf8 进行高速二次转换。
立即学习“C++免费学习笔记（深入）”；
- Windows 上读取 ANSI 文件时，用
MultiByteToWideChar(CP_ACP, ...)先转 UTF-16，再喂给 simdutf - Linux/macOS 下推荐
iconv，注意iconv_open("UTF-8", "GBK")的第二个参数必须是真实编码名，不是 "gb2312" - 性能关键路径上，避免反复调用
iconv初始化；缓存iconv_t句柄
为什么 convert_utf8_to_utf16 返回的 std::string_view 指向临时对象
因为很多人误以为 simdutf::convert_utf8_to_utf16 返回的是可长期持有的字符串，其实它返回的是 std::string_view 或裸指针+长度，背后内存由调用方自己分配——库本身不管理堆内存。
典型翻车代码：auto sv = simdutf::convert_utf8_to_utf16(input); return sv;，此时 sv 指向栈上临时 buffer，函数返回后就悬垂了。
- 正确方式：提前分配好目标 buffer，例如
std::vector<char16_t> out(buf_len)</char16_t>，然后传out.data()和out.size() - 注意 UTF-16 输出长度单位是
char16_t个数，不是字节数；一个汉字在 UTF-16 中占 1 或 2 个char16_t - 如果不确定输出长度，先调用
utf8_length或utf16_length预估，留足空间，避免截断
编译时提示 undefined reference 到 simdutf::to_utf8 或类似符号
这是链接阶段问题：你用了头文件，但没链接实现。simdutf 默认是 header-only，但所有转换函数都依赖 simdutf::implementation 的具体实现体，必须显式启用。
最常漏的一步：没定义 SIMDUTF_IMPLEMENTATION 宏，或定义了却没在包含头文件前定义。
- 确保在 #include
"simdutf.h"之前定义：#define SIMDUTF_IMPLEMENTATION - 如果你用 CMake，确认没有把
simdutf.cpp排除在构建外；官方 repo 的simdutf.cpp是必须编译进项目的 - Clang/GCC 下若用 LTO，要确保
simdutf.cpp和调用代码用相同优化级别编译，否则内联失效导致符号找不到
