go 编译器目前不保证对重复的字符串字面量进行跨包或跨文件的自动去重（即无全局字符串驻留/interning），相同字符串可能在二进制中多次存储；但实际影响通常有限，优化应优先依赖编译器自身能力，而非手动抽象。
go 编译器目前不保证对重复的字符串字面量进行跨包或跨文件的自动去重（即无全局字符串驻留/interning），相同字符串可能在二进制中多次存储；但实际影响通常有限，优化应优先依赖编译器自身能力，而非手动抽象。
在 Go 项目中，尤其是模板代码生成场景（如 HTML 片段硬编码），开发者常会担忧类似 <td>、</td>、{"id": 等高频字符串字面量是否导致可执行文件体积膨胀。例如：
// file1.go
write("<td>")
write(user.Name)
write("</td>")
// file2.go
write("<td>")
write(user.Email)
write("</td>")直觉上，若这些字符串在数十个生成文件中重复出现数百次，似乎值得提取为全局常量或切片索引访问。但Go 编译器（gc）当前并不实施跨编译单元的字符串字面量合并（string interning）。
根据 Go issue #5160（截至 Go 1.23 仍为 open 状态），官方明确指出：语言规范未规定字符串常量的存储方式，编译器实现也未承诺对相同字面量做全局 deduplication。实测表明：
- 同一包内多个 const s = "hello" 通常会被编译器合并（得益于 SSA 优化阶段的常量折叠）；
- 但跨包（如 pkgA/s1.go 和 pkgB/s2.go 中均使用 "some_tag"）则大概率各自保留独立副本；
- 使用 var s = "xxx"（非常量）时，更无法期待共享 —— 每次声明都分配独立只读数据段空间。
✅ 验证方法（推荐）：
可通过 objdump 或 readelf 检查最终二进制中的只读数据段（.rodata）：
go build -o app . readelf -x .rodata app | grep -a "<td>" # 若输出多行匹配，则说明存在重复存储
⚠️ 不建议的手动优化模式（反模式）：
var html = [...]string{"<td>", "</td>", "<div>", "</div>"}
write(html[0]); write(data); write(html[1])该写法不仅未减小二进制体积（html 数组本身需存储所有字符串头 + 数据副本），还引入了额外的内存间接访问和边界检查开销，性能与体积双输。
✅ 推荐实践：
- 信任编译器：对 const 字符串保持自然表达，Go 1.20+ 已增强包内常量合并能力；
- 启用构建优化：始终使用 go build -ldflags="-s -w"（剥离调试信息与符号表），这对减小体积效果远超字符串去重；
- 模板层优化：若由代码生成器驱动，应在生成逻辑中复用字符串变量（如 tdOpen := "<td>"），而非依赖运行时索引；
- 超大规模场景：考虑将静态 HTML 片段外置为嵌入资源（embed.FS），由 text/template 渲染，兼顾可维护性与体积控制。
总结：Go 当前不提供跨文件字符串字面量自动 deduplication，但盲目抽象字符串常量既无效又损害可读性。工程实践中，应聚焦于编译器友好写法、构建参数调优及更高层次的架构设计，而非微观字符串管理。
