go 规范明确指出：切片字面量中各元素表达式的求值顺序未定义，编译器可自由选择；这不表示行为随机或必会变化，而是意味着程序不应依赖任何特定顺序，否则将导致不可移植、不可预测的潜在错误。
go 规范明确指出：切片字面量中各元素表达式的求值顺序未定义，编译器可自由选择；这不表示行为随机或必会变化，而是意味着程序不应依赖任何特定顺序，否则将导致不可移植、不可预测的潜在错误。
在 Go 中，像 []int{a, f()} 这样的切片字面量，其内部各元素（a 和 f()）的求值顺序未被语言规范强制规定。这意味着：
- 编译器（如 gc）可在不同版本、不同平台或不同优化级别下选择先求值 a 或先调用 f()；
- 当前 gc 编译器（截至 Go 1.22）在多数情况下按从左到右顺序求值（因此你反复看到 [2, 2]），但这属于实现细节，非语言契约；
- 其他编译器（如 gccgo）或未来 gc 的优化变更，都可能改变该顺序——你的代码若隐含依赖 [1, 2] 或 [2, 2]，就已违反规范。
例如，以下代码看似无害，实则危险：
a := 1
f := func() int { a++; return a }
x := []int{a, f()} // ❌ 不安全：x[0] 可能是 1 或 2，取决于求值顺序
✅ 正确写法是显式控制顺序，消除歧义：
a := 1
f := func() int { a++; return a }
first := a // 明确先取 a 的值
second := f() // 再调用 f()
x := []int{first, second} // ✅ 语义清晰、行为确定
⚠️ 注意事项：
- “未指定（unspecified）” ≠ “未定义（undefined）”：Go 中这不是内存安全问题，不会崩溃，但结果不可跨环境保证；
- go vet 和静态分析工具不会警告此类问题，需开发者主动识别；
- 类似规则也适用于复合字面量（如 struct{}、map{}）、函数调用参数列表等场景。
总结：永远不要在同一个复合字面量中混用有副作用的表达式与依赖其副作用前状态的变量读取。将求值逻辑拆分为独立语句，是编写健壮、可维护 Go 代码的基本原则。
