go 通过限制同底层类型的命名类型间直接赋值，强制开发者显式转换，从而在编译期防止语义混淆（如将 `os.filemode` 当作普通 `uint32` 使用），提升代码可维护性与类型安全性。
在 Go 中，类型别名（如 type Foz string）并非简单的语法糖，而是创建了新的命名类型（named type）。根据 Go 规范的可赋值性规则（Assignability），两个类型 V 和 T 要满足赋值条件，需满足：
- 它们具有相同的底层类型，且
- 至少其中一个是未命名类型（unnamed type）——即类型字面量（如 []float64、map[string]string、func() 等）。
这正是示例中行为差异的根本原因：
type Foz string var foz Foz = "hello" var s string = foz // ❌ 编译错误：Foz 和 string 均为命名类型 var s2 string = string(foz) // ✅ 正确：显式类型转换
而切片、映射、通道、函数等类型之所以“看似能赋值”，是因为它们的字面量形式（如 []float64）是未命名类型：
type Foo []float64
var foo Foo = []float64{1, 2}
var s []float64 = foo // ✅ 合法：Foo（命名）与 []float64（未命名）满足规则但基础类型如 string、bool、float64 的字面量（string、bool、float64）本身也是命名类型（由语言预声明），因此 type Tai bool 与 bool 之间构成两个命名类型 → 违反“至少一个未命名”的条件 → 编译失败。
为什么这样设计？核心价值在于语义隔离
假设取消该限制，允许任意同底层类型的命名类型自由赋值，将导致严重语义模糊：
type UserID int
type ProductID int
type Timestamp int
func GetUser(id UserID) *User { /* ... */ }
func GetProduct(id ProductID) *Product { /* ... */ }
// 若允许隐式赋值：
var uid UserID = 123
var pid ProductID = uid // ❌ 当前被禁止 —— 这绝非偶然！
GetUser(pid) // 逻辑灾难：用产品 ID 查询用户Go 的严格赋值规则在此处成为一道静态防线：pid := ProductID(uid) 必须显式写出，迫使开发者确认该转换的合理性，避免低级但高危的类型误用。
典型实践：os.FileMode 与 time.Duration
标准库大量依赖此机制保障类型安全：
package os
type FileMode uint32 // 命名类型，底层为 uint32
func (f FileMode) IsDir() bool { /* ... */ }
// 以下调用均合法（因 FileMode 可隐式转为 uint32 仅当接收方接受 uint32）
// 但反过来：uint32 值不能直接传给期望 FileMode 的函数
func Chmod(name string, mode FileMode) error
// ❌ 错误：防止误传任意数字
// os.Chmod("file.txt", 0755) // 编译失败！必须写 os.Chmod("file.txt", 0755 | 0x8000)
// ✅ 正确：明确构造 FileMode
os.Chmod("file.txt", FileMode(0755))同理，time.Duration 是 int64 的命名类型，确保 time.Sleep(5) 必须写为 time.Sleep(5 * time.Second)，杜绝 time.Sleep(5)（5纳秒？5秒？5毫秒？）这类歧义。
总结：不是限制，而是契约
Go 的赋值规则本质是类型系统对语义契约的强制执行：
- ✅ 鼓励清晰意图：string(foz) 比静默转换更能传达“我清楚知道这是字符串语义的再解释”；
- ✅ 支持领域建模：RGBASlice、HSVASlice 等类型可共存于同一项目，互不干扰；
- ✅ 降低维护成本：重构时，类型名变更会立即暴露所有依赖点，而非在运行时崩溃。
因此，当你遇到 cannot use xxx (type YYY) as type ZZZ 错误时，请勿视其为繁琐障碍——它正默默守护着你代码中每一处类型背后的业务含义。
