字面量是编译期确定的语法节点，非运行时值；如42、"hello"、[]int{1,2,3}在编译期解析，不分配内存、不触发调用；&T{}强制堆分配，常量参与类型推导但接口常量非法。
字面量不是“值”，是编译期确定的语法节点
Go 的 42、"hello"、[]int{1,2,3} 这些不是运行时“生成”的值，而是编译器在语法分析阶段就识别出的常量或复合结构描述。它们不分配内存，也不触发任何函数调用——比如 len([3]int{1,2,3}) 中的数组字面量，在编译期就能算出长度为 3，根本不会构造运行时对象。
常见错误：以为 make([]int, 0) 和 []int{} 等价，其实前者是运行时调用，后者是字面量；前者可动态指定容量，后者必须所有维度长度已知（如 [2][3]int{{1,2,3},{4,5,6}} 合法，[2][]int{{1},{2,3}} 非法）。
-
[]int{}是字面量，类型是[]int，底层 slice header 在编译期固定（data=nil, len=0, cap=0） -
make([]int, 0)是表达式，每次执行都返回新 slice header，cap 可能非零（如make([]int, 0, 10)） - 结构体字面量中字段名不可省略：
struct{a,b int}{1,2}编译失败，必须写struct{a,b int}{a: 1, b: 2}或全位置赋值struct{a,b int}{1,2}（仅当字段顺序明确且无嵌入时）
字符串字面量里的 x、u、U 转义只在编译期解析
Go 不支持运行时拼接字符串后做转义解析。写 "u660e" 得到「明」字没问题，但 "\u" + "660e" 得到的是字面字符串 u660e，不是 Unicode 字符。
容易踩的坑：从配置文件或网络读取带转义的 JSON 字符串（如 "name": "\u660e\u65e5"），直接用 json.Unmarshal 就行；但如果手动拼接或替换，别指望 Go 会二次解析转义序列。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
""必须是合法 UTF-8 字节序列，否则编译报错：""不合法（UTF-8 中无效编码） -
"u00FF"是 Unicode 码点 U+00FF，对应字节是0xC3 0xBF（UTF-8 编码），和"ÿ"等价 - 原始字符串字面量
`u00FF`不解析转义，内容就是反斜杠+u+00FF 五个字符
复合字面量的 & 操作符行为容易误解
写 &T{} 并不等于先构造再取地址。Go 规定：对复合字面量加 &，等价于在堆上分配并初始化该值，然后返回其地址——即使该类型可栈分配，&T{} 也强制逃逸到堆。
性能影响明显：频繁写 &bytes.Buffer{} 会导致大量小对象分配，比复用 sync.Pool 或局部变量慢数倍。
-
new(T)和&T{}效果相同（都零值初始化 + 堆分配），但后者更常见 -
T{}本身不逃逸，比如func() T { return T{} }返回值通常栈分配 - 切片字面量加
&：&[]int{1,2} → 返回 *[]int，底层 slice header 在堆上；但s := []int{1,2}; &s是取栈上变量地址，不逃逸
常量表达式与运行时常量的区别很关键
Go 的常量（const）是编译期纯值，参与类型推导和边界检查；而运行时“不变量”只是普通变量，哪怕用 const 声明的接口类型字面量也不存在——const x interface{} = 42 是非法的，因为 interface{} 无法在编译期确定底层表示。
这个限制直接影响泛型约束和类型推导：你不能用 const 值去满足一个要求“可比较”的泛型约束，除非它本身是可比较类型（如整数、字符串、指针）。
-
const s = "hello"是字符串常量，可用作数组长度：[len(s)]byte{} -
const p = unsafe.Pointer(nil)合法，但const i = int(unsafe.Sizeof(int(0)))非法（unsafe.Sizeof是运行时函数） - 浮点常量精度由字面量决定：
const x = 0.1是精确的十进制 0.1（编译器内部用高精度表示），但float64(0.1)是 IEEE 754 近似值
最易被忽略的一点：字面量的类型默认推导可能和直觉不符。比如 1 是 untyped int，默认 int 类型宽度依赖平台；而 <code>int32(1) 明确溢出 panic。写位运算时，别依赖字面量“看起来安全”。
