go编译器ssa阶段不处理字符串去重或拼接优化，仅生成opconststring指令；字符串常量的跨包去重由链接器在.rodata段按内容完成，ssa只负责正确加载与寻址。
Go 编译器对字符串常量的 SSA 优化不涉及“字符串内容层面”的变换（比如合并 "ab" + "c"），它根本不会在 SSA 阶段做字符串拼接、去重或规范化——这些事发生在更早的词法/语法解析或后端数据节（.rodata）布局阶段。
字符串常量在 SSA 中只是 OpConstString 值，不参与数据流优化
SSA 的核心是建模**控制流与值依赖关系**，而字符串字面量在 Go 中是只读、不可变、无副作用的常量。编译器在构建 SSA 时会为每个字符串字面量生成一个 OpConstString 指令（如 v5 = ConstString ["/api/v1"]），但它：
- 不参与常量传播（
OpConstString不会被代入算术表达式） - 不触发死代码消除（只要被引用，就一定会保留）
- 不被 φ 节点合并（不同位置的
"foo"在 SSA 中仍是独立vN） - 其地址（
&"hello"[0]）若被取用，会立刻进入逃逸分析路径，和 SSA 无关
真正去重发生在链接期，不是 SSA 阶段
你看到多个 "<td>" 在最终二进制里只存一份，是因为：
<ul>
<li>前端已将相同字面量归一化为同一 <code>*types.String 对象（语义等价判断）
OpConstString 输出到 .rodata 段，并由链接器（ld）按内容去重（类似 COMDAT）v7 是从哪条指令来的”验证方式：go tool objdump -s".*td><td. test> 查匹配地址数；若仅一个，说明链接器去重成功 —— 和 SSA 无关。</td.>
想让字符串优化“可见于 SSA 日志”，唯一入口是逃逸分析联动
当字符串被取地址、转为 []byte、传给接口或闭包时，逃逸分析会在 SSA 阶段介入，但目的不是优化字符串本身，而是决定存储位置：
-
s := "hello"; _ = &s[0]→ 逃逸分析标记该字符串需分配在堆（实际仍只读，但需可寻址）→ SSA 中对应OpAddr指令出现 -
fmt.Println("world")→ 参数经接口转换，触发隐式堆分配（因interface{}接收）→ SSA 中出现OpMakeInterface和堆分配调用 - 这些节点会被
-gcflags="-m -m"打印为leaking param: s to interface{} value，但日志里绝不会说“已合并字符串”
真正影响字符串内存布局的，是源码组织方式（比如集中声明 const）和链接器行为；SSA 只负责确保这些常量被正确加载、传递、寻址——它不“思考”字符串内容，只“搬运”它们。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
