Go语言中字符串不可变，因底层为只读[]byte；直接用*string无法修改，需转[]byte操作再转回，或极少数场景用unsafe（风险高）。

Go 语言中字符串是不可变的（string 类型底层是只读的 []byte），无法通过指针直接修改其内容。所谓“通过指针修改字符串”，本质是绕过 string 类型约束，用 *[]byte 或 unsafe 手段操作底层字节数组——但这属于非安全、非标准做法，仅在极少数性能敏感且可控场景下可考虑。

为什么不能直接用 *string 修改内容

声明 var s string = "hello" 后，&s 是一个 *string，但它指向的是一个包含 data 指针和 len 字段的只读结构体。即使你用 unsafe 获取底层数据地址，Go 运行时也不保证该内存可写，且可能触发 panic 或导致未定义行为。

• 字符串字面量通常分配在只读内存段（如 ELF 的 .rodata）
• string 和 []byte 虽共享底层数据，但 string 的类型系统禁止写入
• 任何试图写入 string 底层字节的操作都需绕过类型安全检查

安全且推荐的做法：转成 []byte 再操作

绝大多数情况下，应把字符串转为切片处理，再转回字符串。这是 Go 官方推荐、内存安全、语义清晰的方式：

func modifyString(s string) string {
    b := []byte(s)        // 复制一份可写字节切片
    for i := range b {
        if b[i] == 'a' {
            b[i] = 'x'
        }
    }
    return string(b)      // 转回 string（同样会复制）
}

• 每次 []byte(s) 和 string(b) 都触发一次内存拷贝，对大字符串有开销
• 适用于中小规模文本（KB 级以内）、逻辑清晰、无竞态风险
• 如果原字符串来自 make([]byte, n) 并转成 string，可保留原始切片引用避免重复分配

不推荐但可行的“零拷贝”方式：unsafe.String + unsafe.Slice（Go 1.20+）

仅当确定源字节切片生命周期长于字符串、且你控制全部访问路径时，才考虑此方式。它不修改原 string，而是构造一个可写视图：

立即学习“go语言免费学习笔记（深入）”；

import "unsafe"

func unsafeModify(b []byte) string {
    // 修改 b 内容（注意：b 必须是可写的，不能是 string 转来的只读切片）
    for i := range b {
        if b[i] == 'a' {
            b[i] = 'x'
        }
    }
    // 构造新 string，共享 b 的底层数组（零拷贝）
    return unsafe.String(&b[0], len(b))
}

• 关键前提：传入的 b 必须是可写切片（如 make([]byte, n) 分配），不能是 []byte("abc") 这种字面量切片（底层仍只读）
• unsafe.String 不复制内存，但返回的 string 仍不可写；真正可写的是原始 b
• 滥用 unsafe 会导致 GC 误判、内存泄漏或崩溃，生产环境慎用

常见错误与陷阱

以下操作看似合理，实则危险或无效：

• 对 string 字面量取地址并尝试强制转换：ptr := (*[100]byte)(unsafe.Pointer(&"hello"[0])) → 运行时 panic
• 用 reflect.StringHeader 修改 Data 字段 → Go 1.17+ 已禁用，编译失败
• 假设 string(s) 和 []byte(s) 共享同一块内存 → 实际上 []byte(s) 总是拷贝
• 在 goroutine 中并发读写同一个底层 []byte，同时又通过 unsafe.String 暴露为 string → 数据竞争

真正需要“高效修改字符串”的场景，往往说明设计上更适合全程使用 []byte，而非在 string 和 []byte 之间反复横跳。字符串不可变不是缺陷，而是 Go 类型系统保障一致性的基础——绕过它，就得自己扛起所有安全责任。