不能直接用 []byte 反转中文或 emoji，因为 Go 的 string 是 UTF-8 编码，中文或 emoji 占多个字节，按字节反转会破坏字符边界导致乱码；应先转为 []rune 再反转，确保每个 Unicode 码点被完整处理。
为什么不能直接用 []byte 反转中文或 emoji？
因为 Go 的 string 是 UTF-8 编码，一个中文字符或 emoji 占多个字节（比如“你好”是 6 字节），[]byte 按字节交换会把多字节字符切开，导致乱码。例如：string([]byte("你好")[::-1]) 得到的是非法 UTF-8 序列，打印可能显示 或 panic。
真正安全的做法是先转成 []rune——每个 rune 对应一个 Unicode 码点，无论 ASCII、中文还是 ? 都占 1 个元素。
-
[]rune(s)是唯一能正确拆解 Unicode 字符的转换方式 -
string([]byte(s))只适合纯 ASCII 场景（如 HTTP header、base64 字符串） - 别写
string(unsafe.String(...))之类绕过类型检查的操作，毫无必要且破坏可读性
reverseString 函数里 i 还是 <code>i ？
必须用 i 。当 <code>i == j 时，指针指向同一个 rune，交换等于白做；当长度为奇数（如 5 个字符），中间那个索引是 2，此时 i=2, j=2，循环应终止。
如果误写成 i ，会多执行一次无意义交换（不影响结果但逻辑错误），更糟的是：若后续扩展为带区间反转（如只翻转子串），这个边界错误会导致越界或漏翻。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 标准写法：
for i, j := 0, len(runes)-1; i - 不要拆成两个独立
i++和j--，容易在中间插入其他逻辑时出错 - 避免手写
left++, right--后再判断，双指针更新和条件判断应绑定在 for 头部
高频调用时怎么避免反复分配 []rune？
每次调用都 []rune(s) 会触发内存分配，短字符串还好，但日志处理、协议解析等场景下，GC 压力明显上升。解决办法不是全局复用一个切片（会并发冲突），而是用 sync.Pool。
示例：
var runePool = sync.Pool{
New: func() interface{} { return make([]rune, 0, 64) },
}
func reverseString(s string) string {
buf := runePool.Get().([]rune)
buf = buf[:0]
buf = append(buf, []rune(s)...)
for i, j := 0, len(buf)-1; i < j; i, j = i+1, j-1 {
buf[i], buf[j] = buf[j], buf[i]
}
result := string(buf)
runePool.Put(buf) // 必须放回，且不能在 goroutine 中异步调用
return result
}
- 容量预设 64 是经验值，覆盖多数短字符串（URL、token、日志字段）
-
buf = buf[:0]清空但不释放底层数组，避免重新分配 - 归还前不能让
buf逃逸（比如传给另一个 goroutine 或存入 map） - 如果字符串长度经常超 64，考虑按长度分档维护多个 Pool，或改用预分配策略
要不要封装成方法或加 context 支持？
单纯反转字符串不需要 context、error 或 options。Go 标准库风格就是：输入明确、输出确定、无副作用。加 context.Context 或 func(...Option) 反而干扰调用方，也掩盖了核心逻辑。
真正需要扩展的点只有两个：
- 是否支持原地反转
[]rune（供上层复用缓冲区） - 是否提供区间反转版本（如
reverseRunes(runes, start, end)），用于实现“三步翻转法”
其余所谓“可配置编码”“支持流式输入”都是过早抽象——99% 的反转需求就是 string → string，写清楚边界、处理好 Unicode、压住 GC 就够了。
