string转[]rune必分配新内存，因需utf-8解码并创建底层数组；[]rune转string也必拷贝编码，二者不可用unsafe.string互转，高频转换应避免以减少gc压力。
![golang中string与[]rune转换的性能开销_内存分配与拷贝](https://img.php.cn/upload/article/000/969/633/177173796371069.jpeg)
string 转 []rune 一定会分配新内存
Go 的 string 是只读字节序列，而 []rune 是可变的 Unicode 码点切片。两者底层结构完全不同，转换时必须逐个解析 UTF-8 编码并分配新底层数组。
常见错误现象：len(s) 和 len([]rune(s)) 不等（比如含中文或 emoji 时），误以为只是“类型转换”，实际是解码 + 分配。
- 每次
string→[]rune都触发一次完整 UTF-8 解码 + 堆上分配，开销与字符数成正比，不是常数时间 - 如果只是想遍历字符，直接用
for range s更高效——它内部按需解码，不分配整个[]rune - 若后续要频繁索引（如
r[5]），才值得转成[]rune；否则多数场景下，for range或strings.Reader更轻量
[]rune 转 string 触发一次拷贝
[]rune → string 看似“还原”，但 Go 不允许绕过只读约束，所以必须分配新字节空间、重新编码为 UTF-8。
使用场景：拼接、截取、修改后重建字符串（比如替换第 3 个汉字）。
立即学习“go语言免费学习笔记（深入）”；
- 该转换会触发一次完整的 UTF-8 编码过程，且结果
string的底层数组与原[]rune完全无关 - 注意：如果
[]rune中含有非法码点（如0xFFFD以外的超范围值），string()仍会编码，但可能产生非预期字节（Go 不校验 rune 值合法性） - 性能敏感路径中，避免“转 rune → 改几个元素 → 转回 string”这种来回拷贝；考虑用
bytes.Buffer或预分配[]byte手动编码
用 unsafe.String 跳过拷贝？别试
有人想用 unsafe.String 把 []rune 的底层字节强行解释为 string，这是错的。
错误现象：得到乱码、panic 或不可预测的字符串内容。
-
[]rune底层是uint32数组，每个元素占 4 字节；UTF-8 编码后的string是变长字节流，二者内存布局完全不兼容 - 即使全是 ASCII 字符（rune == byte），
[]rune存的是[0x00,0x00,0x00,0x61]这样的 4 字节整数，直接 reinterpret 会读出大量零字节和错位数据 - Go 1.20+ 的
unsafe.String仅适用于[]byte→string场景，对[]rune无意义
真正需要优化的点：别在热路径反复转换
最常被忽略的不是单次转换开销，而是高频调用导致的 GC 压力和缓存失效。
典型场景：HTTP 请求体解析、日志字段处理、模板渲染中的字符串操作。
- 如果函数签名是
func f(s string)，但内部反复rs := []rune(s)，考虑改为接收[]rune或重构为只遍历一次 - 字符串切片（如
s[i:j]）本身不分配，但切完再转[]rune仍要全量解码——哪怕你只想要其中两个字符 - 用
utf8.DecodeRuneInString手动解码指定位置，比转整块[]rune更省；标准库的strings.IndexRune就是这么做的
