Go 的字符串常量在编译期即确定，无论直接字面量还是 const 声明，均指向同一段只读内存区域，运行时零分配、无重复拷贝，大幅提升高频调用场景下的性能。
go 的字符串常量在编译期即确定，无论直接字面量还是 `const` 声明，均指向同一段只读内存区域，运行时零分配、无重复拷贝，大幅提升高频调用场景下的性能。
在 Go 中，字符串常量（如 "hello"）本质上是不可变的只读数据，由编译器在构建阶段固化到二进制文件的 .rodata（只读数据段）中。这意味着：
- 所有相同内容的字符串字面量（如循环中反复出现的 "hello"）会被自动合并（string interning）；
- 通过 const HELLO = "hello" 定义的常量，与直接写 "hello" 在语义和底层实现上完全等价——它不创建新变量，也不分配运行时内存，仅作为编译期符号引用该已存在的字符串数据。
以下实验可直观验证这一点：
package main
import (
"fmt"
"reflect"
"unsafe"
)
const Hello = "hello"
func main() {
fmt.Println("=== 字面量循环 ===")
for i := 0; i < 3; i++ {
s := "hello"
hdr := (*reflect.StringHeader)(unsafe.Pointer(&s))
fmt.Printf("值: %q → 地址: %d, 长度: %d\n", s, hdr.Data, hdr.Len)
}
fmt.Println("\n=== const 循环 ===")
for i := 0; i < 3; i++ {
s := Hello
hdr := (*reflect.StringHeader)(unsafe.Pointer(&s))
fmt.Printf("值: %q → 地址: %d, 长度: %d\n", s, hdr.Data, hdr.Len)
}
}输出示例（地址值因编译环境略有差异，但每轮循环内地址恒定且两组完全一致）：
=== 字面量循环 === 值: "hello" → 地址: 4870353, 长度: 5 值: "hello" → 地址: 4870353, 长度: 5 值: "hello" → 地址: 4870353, 长度: 5 === const 循环 === 值: "hello" → 地址: 4870353, 长度: 5 值: "hello" → 地址: 4870353, 长度: 5 值: "hello" → 地址: 4870353, 长度: 5
✅ 关键结论：
- 两种写法（log.Println("hello") 与 log.Println(HELLO)）内存分配完全相同：均不产生新的字符串对象，每次调用仅传递同一个 StringHeader（含固定指针 + 长度），开销为 O(1)；
- const 不引入额外运行时成本，反而提升可读性与可维护性（集中管理字面量、避免拼写错误）；
- 此行为虽未在 Go 语言规范中强制要求，但所有主流 Go 编译器（gc）均稳定实现该优化，可视为事实标准。
⚠️ 注意事项：
- 此优化仅适用于编译期已知的字符串字面量。若字符串由运行时拼接生成（如 fmt.Sprintf("hello-%d", i)），则每次都会分配新内存；
- const 本身不改变底层数据布局，它只是为编译期常量提供命名绑定，对性能无负面影响，却显著增强代码健壮性。
因此，在高频日志、模板渲染或协议字段等场景中，优先使用 const 声明字符串，既是最佳实践，也是零成本的性能优化。
