直接用[:n]截取字符串会乱码，因为Go字符串底层是UTF-8字节数组，而[:n]按字节截断可能切在多字节字符中间；应使用utf8.DecodeRuneInString或strings.Reader逐rune解码并累计字节数来安全截断。
为什么直接用 [:n] 截取字符串会乱码
Go 的字符串底层是 UTF-8 字节数组，[:n] 是按字节截断，不是按字符。如果 n 刚好卡在某个中文、emoji 或其他多字节字符的中间（比如 3 字节 UTF-8 字符只取了前 2 字节），解码时就会出现 或解析失败。这不是 Go 的 bug，而是裸字节操作的必然结果。
用 utf8.DecodeRuneInString 逐字符累加判断字节长度
核心思路：不预估字符数，而是从头遍历每个 Unicode 码点，累计其 UTF-8 编码字节数，直到即将超过目标上限时停止。这样能确保每个完整字符都被保留或整体跳过。
实操建议：
- 用
for i, r := range s遍历时，i是字节偏移量，r是 rune；但注意range本身已按 UTF-8 解码，所以更稳妥的是用utf8.DecodeRuneInString手动控制解码位置 - 目标是“最多
maxBytes字节”，所以每次 decode 后检查i + size <= maxBytes，而非<—— 允许刚好填满 - 遇到无法解码的非法 UTF-8 序列（如
DecodeRuneInString返回utf8.RuneError），可选择跳过或截断到上一个合法位置
func truncateToBytes(s string, maxBytes int) string {
if maxBytes <= 0 {
return ""
}
var result []byte
i := 0
for i < len(s) {
r, size := utf8.DecodeRuneInString(s[i:])
if r == utf8.RuneError && size == 1 {
// 非法字节，不计入，跳过
i++
continue
}
if i+size > maxBytes {
break
}
result = append(result, s[i:i+size]...)
i += size
}
return string(result)
}
用 strings.Reader + ReadRune 更简洁地控制边界
相比手动索引，strings.Reader 封装了读取位置和错误处理，代码更清晰，尤其适合嵌入工具函数中。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
-
ReadRune返回当前 rune 及其字节长度，天然适配“累计字节数”逻辑 - 需注意
ReadRune在 EOF 时返回0, 0, io.EOF，要提前 break，否则可能无限循环 - 若原始字符串含 BOM 或控制字符，它们也会被当作有效 rune 处理，无需额外过滤 —— 这符合“保持原文语义”的摘要需求
func truncateByReader(s string, maxBytes int) string {
if maxBytes <= 0 {
return ""
}
r := strings.NewReader(s)
var buf []byte
total := 0
for total < maxBytes {
rune, size, err := r.ReadRune()
if err != nil {
break
}
if total+size > maxBytes {
break
}
buf = append(buf, string(rune)...)
total += size
}
return string(buf)
}
性能与边界场景必须验证的三点
这类截断操作看似简单，但在高并发日志摘要、API 响应截断等场景下，微小差异会被放大。
- 空字符串、全 ASCII 字符串、全 emoji 字符串都要单独测 —— ASCII 单字节 vs emoji 四字节对累计逻辑影响很大
- 当
maxBytes小于单个最小 rune（即 1 字节）时，返回空字符串；但若maxBytes == 1且首字节是 ASCII，应返回该字符，不能误判为非法 - 不要依赖
len([]rune(s))计算字符数再反推字节 —— 这会分配额外内存且无法保证字节精度，纯属绕路
真正容易被忽略的是：UTF-8 中存在“可变宽度”和“非法序列”两个正交问题。只处理前者（如用 range）不够，必须显式应对后者（如检测 utf8.RuneError），否则线上遇到损坏文本时仍会乱码。
