go无内置utf-16编解码支持，unicode/utf16仅转换rune与uint16切片，不处理字节序、bom或空终止；应使用golang.org/x/text/encoding/unicode包，并注意windows api调用时手动补零及正确预估长度。
Go 里没有内置 UTF-16 编码支持，unicode/utf16 只处理编码转换逻辑，不负责字节序或 BOM
Go 标准库的 unicode/utf16 包不是编解码器，它只提供 Encode 和 Decode 函数，把 []rune 和 []uint16 互相转换。它不碰字节（[]byte），也不管你是 Little-Endian 还是 Big-Endian，更不会自动识别或写入 BOM。
Windows API（如 WideCharToMultiByte）默认用 UTF-16LE，而 Go 的 encoding/binary 需你显式指定 binary.LittleEndian 才能正确序列化 []uint16 成字节流。
- 常见错误现象：
string(unsafe.Slice(&u16[0], len(u16)*2))直接转字符串 → 字节序错乱，Windows 上读出来是乱码 - 正确做法：先
utf16.Decode得到[]rune，再用[]byte(string(runes))转 UTF-8；反向则先 UTF-8 解码为[]rune，再utf16.Encode+binary.Write（指定 LE） - Windows 场景下必须手动处理 BOM：UTF-16LE 的 BOM 是
\xff\xfe，但 Go 程序读文件时若带 BOM，os.ReadFile会原样返回，需自己跳过前 2 字节再解码
golang.org/x/text/encoding/unicode 是唯一靠谱的 UTF-16 编解码器
如果你要读写磁盘上真实的 UTF-16 文件（比如 Windows 记事本保存的 .txt），别手写转换逻辑——直接用 x/text/encoding/unicode。它封装了 BOM 检测、字节序自动识别、以及与 io.Reader/Writer 的无缝对接。
- 使用场景：读取 Windows 生成的 UTF-16LE 文件、向 COM 接口传 UTF-16 字节、与 Cgo 调用 Windows API 交互
- 关键参数：
unicode.UTF16(unicode.LittleEndian, unicode.UseBOM)——UseBOM表示写入时加 BOM，读取时自动跳过；若设为unicode.ExpectBOM，则读取时强制要求 BOM，缺则报encoding.ErrInvalidUTF16 - 性能影响：比纯
utf16.Decode多一次内存拷贝，但对大多数 I/O 场景可忽略；兼容性远高于手撸逻辑，尤其在跨平台混合 BOM 存在时
Cgo 调用 Windows API 时，*uint16 必须指向以 \x00\x00 结尾的 UTF-16LE 字节块
Windows 的宽字符 API（如 CreateFileW、SetWindowTextW）接收 LPCWSTR，即指向 uint16 的空终止指针。Go 中不能直接传 []uint16，必须用 C.CString 类思路手动构造，并确保末尾双字节为零。
- 常见错误现象：
C.GoBytes(unsafe.Pointer(&u16[0]), C.int(len(u16)*2))→ 缺少结尾\x00\x00，API 调用崩溃或截断字符串 - 正确做法：分配
len(runes) + 1个uint16，最后一位清零；用C.CString不行（它按字节处理），得用C.malloc+unsafe.Slice+copy - 注意：
utf16.Encode输出不含结尾零，必须手动补；且整个切片需保持有效生命周期，不能是局部[]uint16的底层数组
UTF-8 和 UTF-16 长度不等价，len([]byte(s)) != len(utf16.Encode([]rune(s))) * 2
一个中文字符在 UTF-8 占 3 字节，在 UTF-16 占 2 字节；但遇到 Unicode 辅助平面字符（如 emoji ?、古汉字），UTF-16 需要两个 uint16（代理对），而 UTF-8 仍只需 4 字节。所以长度换算绝不能硬乘除。
立即学习“go语言免费学习笔记（深入）”；
- 典型坑：
buf := make([]byte, len(src)*2)预估 UTF-16 字节长度 → 对含 emoji 的字符串严重溢出 - 安全做法：先
utf16.Encode([]rune(s))得到[]uint16，再用len(u16) * 2；或直接用x/text/encoding的Encoder.Size方法预估 - Windows 路径限制：MAX_PATH 是字符数（
wchar_t个数），不是字节数。所以判断路径是否超长，该用len(utf16.Encode([]rune(path)))，而非len([]byte(path))
事情说清了就结束。最常被绕开的是 BOM 处理和空终止——这两点在 Windows 平台几乎必踩，而且错误表现往往延迟到运行时才暴露。
