直接按字节切字符串会破坏UTF-8编码，导致乱码或解析失败；必须在合法rune边界处分片，即从目标位置向前查找utf8.RuneStart为true的位置来确定安全切点。
直接按字节切 s[:n] 会破坏 UTF-8 编码，导致乱码或解析失败；真正安全的等长分片必须落在合法 rune 边界上。
为什么不能用 s[i:i+chunkSize] 硬切
Go 的字符串底层是字节数组，但语义是 UTF-8 编码文本。一个中文字符（如“你”）占 3 字节，一个 emoji（如“?”）占 4 字节。若 chunkSize=10，而第 10 字节刚好落在某个 rune 中间，s[:10] 就会截断该 rune，后续 range 或 json.Unmarshal 会看到 或报 invalid UTF-8。
- 错误现象：
fmt.Println([]rune(s[:10]))返回长度小于预期，或含0xFFFD替换符 - 典型场景：日志归档、API 分块响应、WebSocket 消息分帧
- 影响：接收方无法正确解码，JSON/XML 解析失败，前端显示豆腐块
用 unicode/utf8 找最近的合法 rune 起始位置
核心思路：从目标字节位置向前扫描，用 utf8.RuneStart 找到上一个完整的 rune 开头，确保切点不落在多字节字符中间。
- 不要从头遍历每个
rune——性能差；应从chunkSize附近向后/向前试探 - 推荐做法：先取
s[:min(chunkSize, len(s))]，再从末尾倒查，找到最后一个utf8.RuneStart为true的索引 - 边界情况：若整个 chunk 都在单个超长
rune内（极罕见，如损坏数据），退回到chunkSize强制切（此时已无法无损） - 示例逻辑片段：
func splitAtRuneBoundary(s string, maxBytes int) []string {
if len(s) <= maxBytes {
return []string{s}
}
// 从 maxBytes 位置往前找合法 rune 起始
i := maxBytes
for i > 0 && !utf8.RuneStart(s[i-1]) {
i--
}
if i == 0 { // 没找到，第一个 rune 就超长
i = maxBytes
}
return append([]string{s[:i]}, splitAtRuneBoundary(s[i:], maxBytes)...)
}
strings.Split 和等长分片是两回事，别混用
strings.Split 是按分隔符切，结果长度完全不确定；它解决的是结构化分词问题，不是字节/字符对齐问题。
立即学习“go语言免费学习笔记（深入）”；
- 常见误用：想把长文本按每 1024 字符发包，却写
strings.Split(s, "")再拼 —— 这生成的是单字符切片，内存爆炸且无意义 - 混淆后果：用
strings.SplitN(s, "", n)模拟等长切，实际得到的是 rune 数量近似相等，但字节数严重不均（ASCII vs 中文） - 真正需要等长字节块时（如 TCP 分帧），必须用
utf8.DecodeRuneInString+ 循环累加字节数，而非依赖strings包
生产环境必须处理的三个细节
写完基础切分函数只是开始，漏掉这些会导致线上静默故障。
- 末尾块必须显式
res = append(res, s[i:])，不能靠递归自动收尾——否则空字符串或超短剩余段会被丢弃 - 每次切分后检查
len(chunk)是否为 0，避免空串进入传输流（某些协议栈会跳过空帧） - 若用于网络发送，务必在每块前加长度头（如
binary.Write(conn, binary.BigEndian, uint32(len(chunk)))），否则接收方无法判断包边界
最易被忽略的是：UTF-8 安全切分和网络帧边界是两个正交问题。前者保编码正确，后者保传输完整——两者缺一不可，但实现上必须分开处理。
