[]rune与string相互转换不会被内联，因编译器调用runtime.stringtoslicerune和runtime.slicerunetostring，需utf-8解码/编码、动态长度计算及堆分配，无法在编译期展开。
[]rune 转 string 和 string 转 []rune 在 Go 官方编译器（gc）中 **不会被内联**，也不做逃逸分析优化 —— 无论字符串多短、rune 切片多小，每次转换都必然分配新内存。
为什么 string 到 []rune 不内联？
Go 编译器对 string → []rune 的转换实现为调用运行时函数 runtime.stringtoslicerune。该函数必须：
- 遍历 UTF-8 字节流，逐个解码码点
- 为每个有效 rune 分配并写入
[]rune底层数组 - 处理无效 UTF-8 序列（填入
0xFFFD）
这些逻辑无法在编译期展开为纯机器指令，且涉及动态长度判断和内存分配，因此编译器明确禁止内联。哪怕 str := "a" 这样单字符字符串，[]rune(str) 仍会触发一次堆分配。
为什么 []rune 到 string 也不内联？
对应函数是 runtime.slicerunetostring，它需要：
- 计算所有 rune 的 UTF-8 编码总字节数（每个 rune 可能占 1–4 字节）
- 分配新字符串底层字节数组
- 逐个编码 rune 并拷贝
同样含不可预测的循环与内存分配，编译器不内联。即使 string([]rune{'x'}) 这种简单调用，也会走完整 runtime 路径，且新字符串底层数组独立于原 []rune。
哪些场景容易误判“编译器优化了”？
开发者常因以下现象误以为有内联或零拷贝：
- 用
range遍历字符串时，编译器确实做了 UTF-8 解码优化（不生成临时[]rune），但这是range语义层面的特殊处理，和显式转换无关 - 短字符串常被分配到 span cache 或 mcache 中，分配延迟低，但仍是真实堆分配
- GC 未立即回收小对象，导致多次转换看起来“复用内存”，实际是 GC 滞后，不是编译器优化
可通过 go tool compile -S 查看汇编输出验证：所有 []rune(s) 和 string(r) 调用都会出现对 runtime.stringtoslicerune 或 runtime.slicerunetostring 的直接 call 指令。
真正影响性能的关键点
转换本身开销不大，但高频调用时累积的堆分配会显著拖慢 GC 周期。尤其要注意：
- 避免在 hot path（如 HTTP handler 内部、循环体）反复做
[]rune(s) - 不要为单字符操作（如取首字符）转
[]rune—— 改用utf8.DecodeRuneInString(s) - 若需多次切片/索引，先转一次
[]rune并复用，而非每次操作都重新转换
编译器不做优化，就得靠人盯住分配路径 —— 这是 Go 处理 Unicode 时最常被忽略的隐性成本。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
