Go 允许将未命名类型（如 []byte）直接赋值给基于其定义的命名类型（如 json.RawMessage），是因为 Go 类型系统中“可赋值性”规则仅要求底层类型相同，且至少一方为未命名类型；而 []byte 是未命名复合类型，int64 是命名基础类型，导致行为差异。
go 允许将未命名类型（如 `[]byte`）直接赋值给基于其定义的命名类型（如 `json.rawmessage`），是因为 go 类型系统中“可赋值性”规则仅要求底层类型相同，且**至少一方为未命名类型**；而 `[]byte` 是未命名复合类型，`int64` 是命名基础类型，导致行为差异。
在 Go 的类型系统中，赋值是否合法并非取决于“是否为自定义类型”，而是严格遵循语言规范中关于可赋值性（Assignability）的定义：
A value x is assignable to a variable of type T if one of the following conditions applies:
— x's type is identical to T; or
— x's type V and T have identical underlying types, and at least one of V or T is not a named type.
关键在于：[]byte 是未命名类型（unnamed type），而 int64 是命名类型（named type）。
✅ 为什么 json.RawMessage = []byte 合法？
type RawMessage []byte // 命名类型，底层类型为 []byte
var msg json.RawMessage
var data []byte = []byte(`{"name":"alice"}`)
msg = data // ✅ 编译通过- []byte 是切片字面量类型（由 [...]T 或 []T 语法构造），属于未命名类型；
- RawMessage 是命名类型，但其底层类型与 []byte 相同；
- 满足“底层类型相同 + 至少一方未命名”的条件 → 赋值合法。
❌ 为什么 time.Duration = int64 不合法？
type Duration int64 // 命名类型，底层类型为 int64 var d time.Duration var n int64 = 1000 d = n // ❌ 编译错误：cannot use n (type int64) as type time.Duration
- int64 本身是预声明的命名类型（见 Go 规范：Predeclared identifiers）；
- Duration 也是命名类型；
- 二者均为命名类型，且类型名不同 → 不满足可赋值性条件；
- 必须显式转换：d = time.Duration(n)。
? 补充验证：自定义命名切片 vs 自定义命名整数
type MyBytes []byte // 命名切片类型
type MyInt int64 // 命名整数类型
func main() {
b := []byte("hi")
i := int64(42)
var mb MyBytes = b // ✅ OK: []byte 未命名，MyBytes 命名 → 满足条件
var mi MyInt // = i // ❌ ERROR: both MyInt and int64 are named types
mi = MyInt(i) // ✅ OK: explicit conversion
}⚠️ 注意事项
- 此规则与运行时开销无关：所有合法的隐式赋值都是编译期类型重解释，零成本；
- type T = U（类型别名）与 type T U（新命名类型）语义不同：前者完全等价（T 和 U 可互换），后者创建独立命名类型（需遵守可赋值性规则）；
- 切片、映射、通道、函数、接口、结构体等复合类型的字面量形式均为未命名类型；而所有 type X Y 定义（包括 type IntAlias = int 以外的 type IntNew int）均产生命名类型。
✅ 正确实践建议
- 当设计封装类型（如 type UserID string 或 type Payload []byte）时，明确预期赋值场景；
- 对 []byte 等未命名底层类型，可安全依赖隐式赋值提升可读性；
- 对 int, int64, string 等预声明命名类型，务必使用显式转换以表达清晰意图，避免混淆；
- 使用 go vet 或静态分析工具（如 staticcheck）可辅助识别潜在类型误用。
理解这一机制，不仅解决了 json.RawMessage 的困惑，更深化了对 Go “类型安全 + 显式意图”设计哲学的掌握——它不阻止你做合理的事，但要求你为跨命名边界的操作承担明确责任。
