go 编译器目前不保证对重复的字符串字面量进行跨包或跨文件的自动去重（即无全局字符串驻留/interning），相同内容的字符串常量在二进制中可能被多次存储；但实际影响通常有限，且可通过合理设计规避冗余。
go 编译器目前不保证对重复的字符串字面量进行跨包或跨文件的自动去重（即无全局字符串驻留/interning），相同内容的字符串常量在二进制中可能被多次存储；但实际影响通常有限，且可通过合理设计规避冗余。
在 Go 语言开发中，尤其是涉及模板代码生成、HTML 片段硬编码或大量重复字面量的场景（如 <td>、</td>、{"status":"ok"} 等），开发者常会关心：多个相同字符串字面量是否导致可执行文件膨胀？编译器是否会自动合并它们？
答案是：Go 编译器（截至 Go 1.22）默认不执行跨编译单元的字符串常量去重（interning）。这意味着：
- 在 file1.go 中写 s := "<td>"，
- 在 file2.go 中再写 t := "<td>"，
- 即使二者内容完全一致，链接后的二进制中很可能存在两份独立的字符串数据（位于 .rodata 段），并各自持有独立的字符串头（string 结构体：指针 + 长度）。
这一行为由 Go 语言规范明确回避——语言规范未规定字符串字面量的存储实现细节，而官方 issue #5160 也证实：Go 当前无计划引入全局字符串驻留机制，主要出于确定性、构建可重现性及避免隐式性能开销的考量。
✅ 实际影响评估：通常无需过早优化
尽管存在重复存储，但需理性评估其影响：
- 单个字符串字面量（如 "<td>" 仅 5 字节）在现代二进制中占比极小；
- Go 的链接器已对只读数据段做基础合并（如同文件内重复字面量可能被合并），但跨包/跨文件不保证；
- 使用 go tool objdump -s main\.main your_binary 可验证：搜索 "<td>" 常可见多处独立地址。
? 快速验证示例：
echo 'package main; func main() { _ = "<td>"; _ = "<td>" }' > a.go echo 'package main; func f() { _ = "<td>" }' > b.go go build -o test a.go b.go go tool objdump -s ".*<td>.*" test # 观察是否出现多个匹配地址
✅ 推荐实践：显式集中管理，兼顾可读与可控
当重复字符串高频出现（如模板生成器产出数百个 "<div>"、"</div>"），建议主动抽象而非依赖编译器优化：
// constants.go —— 统一声明，语义清晰，便于维护
package main
const (
TDOpen = "<td>"
TDClose = "</td>"
TROpen = "<tr>"
TRClose = "</tr>"
)
// 或使用私有变量（若需运行时计算/初始化）
var htmlFragments = struct {
TDOpen, TDClose string
TROpen, TRClose string
}{
TDOpen: "<td>",
TDClose: "</td>",
TROpen: "<tr>",
TRClose: "</tr>",
}调用侧简洁安全：
for i, a := range list {
write(htmlFragments.TDOpen)
write(a)
write(htmlFragments.TDClose)
}✅ 优势：
- 零运行时开销：const 在编译期内联，var struct 仍为只读数据，无额外 indirection；
- 强可维护性：一处修改，全局生效；支持 IDE 全局重命名；
- 明确意图：避免“魔法字符串”，提升代码自解释性；
- 兼容性无忧：不依赖未承诺的编译器行为。
⚠️ 注意事项
- ❌ 避免过度工程：若仅 2–3 处重复，直接使用字面量更简洁；
- ❌ 不要用 []string 数组索引替代具名常量（如 myStrings[0]），牺牲可读性且无实际收益；
- ✅ 若需动态拼接（如 fmt.Sprintf("<%s>", tag)），优先考虑 sync.Pool 缓存 strings.Builder，而非预存组合结果；
- ? 对 Web 服务等场景，更显著的体积优化点在于：启用 UPX 压缩、移除调试信息（-ldflags="-s -w"）、使用 buildmode=plugin 拆分模块。
总结
Go 不提供字符串字面量的跨文件自动去重，这是设计取舍而非缺陷。面对重复字符串，应以工程化思维主动管理——通过 const 或结构化 var 显式归一化，既确保二进制精简可控，又提升代码质量与协作效率。记住：可预测的显式控制，永远优于不可靠的隐式优化。
