在 Go 语言里，当我们在代码中写下两个并列的字符串字面量并用加号连接时，例如 "hello, " 与 "world"，编译器并不会生成运行时的拼接指令，而是在编译阶段就把结果算出来。这种能力来源于 Go 规范中对常量表达式的定义，以及编译器前端所做的常量折叠优化。
什么是字符串字面量与常量表达式
字符串字面量指的是直接写在源码里、由双引号包裹的字符序列，例如 "abc"。在 Go 中，字符串字面量属于无类型常量（untyped constant），只要不赋值给变量或参与含变量的运算，它就一直保持在编译期可知的状态。常量表达式则是由常量操作数构成的表达形式，Go 语言规范明确规定，常量表达式可以在编译时求值。
当加号两边都是字符串字面量时，整个表达式就是一个常量表达式。因为操作数没有依赖任何运行时数据，编译器在解析完抽象语法树后，就可以把这两个字面量合并成一个新的字符串常量。这种方式不会产生任何运行时的内存分配，最终可执行文件中只保留合并后的结果。
编译时求值的实现机制
Go 编译器（如 gc）在语法分析之后会进行常量折叠（constant folding）。对于字符串类型的常量表达式，会在 cmd/compile/internal/ir 与 cmd/compile/internal/typecheck 等阶段识别并合并。下面的代码展示了纯字面量连接和混入变量连接的区别：
package main
import "fmt"
func main() {
// 编译时求值：a 直接等于 "helloworld"
a := "hello" + "world"
// 运行时拼接：b 依赖变量 x
x := "hello"
b := x + "world"
fmt.Println(a, b)
}
在上面例子中，a 的初始化表达式全是字面量，编译器在生成中间代码时会直接把 "helloworld" 作为常量处理；而 b 因为涉及变量 x，只能在运行时通过字符串拼接逻辑完成，可能涉及内存分配与复制。
我们可以通过查看汇编来验证：对 a 的赋值通常不会出现对 runtime 拼接函数的调用，而 b 的构造往往会走到 runtime.concatstrings 或类似实现。这也是为什么在性能敏感路径上，推荐尽量使用字面量连接来避免不必要的运行时开销。
容易混淆的边界情况
并非所有看起来像字面量的写法都能编译时合并。例如通过常量标识符引用字符串，如果原声明是 const s = "hi"，那么 s + "there" 依然属于常量表达式，可以编译时求值。但如果使用 var s = "hi"，则 s 是变量，连接会退化为运行时操作。
另一个常见误区是认为字符串转换也一定免费。比如 string([]byte("abc")) 中虽然内部是字面量，但 []byte(...) 的转换在部分场景下仍可能生成运行时代码，因此并不总能像纯字符串字面量相加那样被完全折叠。写代码时应明确区分“字面量直接相加”和“包含转换或变量的表达式”。
实践建议与示例
在构建错误提示、日志前缀或配置键名时，如果片段都是已知内容，直接写成字面量连接是最优解。如下例子展示了如何利用该特性减少运行时工作：
package main
import "fmt"
// 编译时合并为 "server: listen error"
const errPrefix = "server: " + "listen error"
func main() {
// 直接使用已合并的常量
fmt.Println(errPrefix)
}
这里 errPrefix 作为常量声明，两个字面量在编译期就已经合并，使用时没有任何拼接代价。相比之下，若写成函数内 msg := prefix + "listen error" 且 prefix 是变量，则每次调用都会发生拼接。
总结来说，Go 的字符串字面量连接之所以能编译时求值，核心在于常量表达式规则与编译器的常量折叠。清楚这条边界，可以让我们在写代码时主动规避不必要的运行时字符串分配，同时保持代码清晰易读。