字符串字面量转 *string 为什么不能直接取地址
Go 中字符串是只读的底层结构（struct{data *byte; len int}），但语言层禁止对字面量或临时值取地址。你写 &"hello" 会报错 cannot take address of "hello"，不是因为字符串“不可变”，而是因为字面量没有固定内存地址。
实操建议：
- 需要
*string时，先声明变量再取址：s := "hello"; ptr := &s - 在函数参数需传
*string且你只有字面量？封装成局部变量再传，别试图绕过编译器 - 注意：哪怕
s是局部变量，只要它没逃逸到堆上，&s指向的仍是栈地址——这点和 C 不同，Go 运行时会自动决定逃逸，不用手动干预
unsafe.String 和 unsafe.Slice 改写底层字节的风险点
从 Go 1.20 起，unsafe.String 允许把 []byte 转为 string 而不拷贝；反过来用 unsafe.Slice(unsafe.StringData(s), len(s)) 可得可写字节切片。但这不是“让字符串可变”，只是绕过类型系统暴露底层内存。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 对通过
unsafe.String构造的字符串调用strings.ReplaceAll后再改写底层字节 → 触发未定义行为（原字符串可能已被 GC 复用内存） - 把
unsafe.Slice得到的[]byte传给任何会扩容的函数（如append）→ 切片底层数组可能被复制，后续改写失效 - 跨 goroutine 共享这种“伪可变”字符串 → 没有同步机制，数据竞争几乎必然发生
性能影响：零拷贝确实快，但代价是失去编译器保护。仅在 hot path 且已压测验证的场景考虑，日常开发优先用 strings.Builder 或 []byte 拼接。
什么时候该用 strings.Builder，而不是反复 + 或 fmt.Sprintf
字符串拼接看似简单，但 + 在循环中每次都会分配新内存并拷贝全部内容，fmt.Sprintf 额外带格式解析开销。而 strings.Builder 底层用 []byte 缓冲，支持预分配容量，真正高效。
使用场景判断：
- 拼接次数不确定（比如遍历未知长度的 slice）→ 用
strings.Builder，调用Grow()预估容量 - 拼接固定几段（如
"prefix-" + name + "-suffix"）→ 直接+更清晰，编译器会优化成一次分配 - 要格式化数字/布尔等 →
fmt.Appendf（接受Builder的Write接口）比fmt.Sprintf少一次中间字符串分配
注意：Builder.String() 返回的是新分配的字符串，底层 []byte 缓冲会被丢弃——它不是“复用字符串”，而是复用拼接过程中的内存。
从 []byte 转 string 的三种方式性能与安全边界
Go 里最常踩坑的是误以为 string(b)、unsafe.String、reflect.StringHeader 可以随意混用。它们的区别不在“能不能转”，而在“谁负责管理内存”。
-
string(b)：安全默认项。拷贝b内容，b后续修改不影响字符串。适合大多数场景 -
unsafe.String(&b[0], len(b))：零拷贝，但要求b生命周期必须长于所得字符串，且b不能被修改（否则字符串内容随机变） -
reflect.StringHeader手动构造：Go 1.20+ 已不推荐，容易因字段顺序或对齐变化崩溃，且unsafe包本身不保证兼容性
兼容性影响：前两种在所有稳定 Go 版本都有效；第三种在 Go 1.17+ 已被明确标记为“可能破坏”，连文档都不鼓励。
事情说清了就结束
