utf8.DecodeRuneInString仅解码字符串首个rune，遇非法起始字节（如截断的continuation byte或非UTF-8数据）返回'\uFFFD'和size=1；它不验证后续字节合法性，也不等价于range遍历。
utf8.DecodeRuneInString 不是“解码整个字符串”，它只动第一个 rune —— 这点不搞清，后续所有截断、匹配、遍历逻辑都会出错。
为什么 utf8.DecodeRuneInString 总返回 '\uFFFD'？
它只在输入字符串以非法 UTF-8 字节开头时才返回替代字符。常见诱因：
- 你传入了被截断的字节切片（比如
s[1:]后首字节是0x80这类 continuation byte） - 原始数据根本不是 UTF-8（例如误把 GBK 或 Latin-1 数据当 string 传入）
- 用
unsafe.String或C.GoString转换时底层字节不合法
验证方式：先用 utf8.ValidString(s) 检查整体合法性，再调用 DecodeRuneInString；若仍失败，说明问题出在首字节位置本身。
utf8.DecodeRuneInString 和 range 循环的区别在哪
两者都按 UTF-8 规则解析，但行为边界不同：
立即学习“go语言免费学习笔记（深入）”；
-
range自动跳过非法字节序列（遇到0xFF这类无效起始字节，会跳过 1 字节后重试），而DecodeRuneInString遇到非法开头直接返回'\uFFFD'和 size=1 -
range是迭代器，适合全量遍历；DecodeRuneInString是单次解码，适合前缀判断、手动步进或实现自定义 tokenizer - 性能上，
range编译器有优化；DecodeRuneInString每次都要重新识别起始字节类型（0xxx/110xxx/1110xxxx等），无缓存
用 utf8.DecodeRuneInString 安全截断字符串的典型陷阱
很多人写 s = s[size:] 就以为万事大吉，但要注意：
- 如果原字符串末尾是孤立 continuation byte（如
"hello\x80"），第一次DecodeRuneInString返回'\uFFFD'+ size=1，截掉后剩下"ello\x80"，继续解码仍失败——这不是 bug，是 UTF-8 的设计使然 - 它不保证剩余部分合法：即使首 rune 解码成功，后续字节仍可能非法（比如中间插入
\xFF） - 别把它和
strings.TrimSuffix混用：后者是字节级匹配，对多字节字符无效；想删末尾字符，得用utf8.DecodeLastRuneInString，不是这个函数
真正难的不是调用函数，而是理解它只负责“当前位置是否构成一个合法 UTF-8 起始”——其余字节是否连贯、是否完整，它不管。
