go 语言要求两个命名类型之间不可直接赋值，即使底层类型相同；仅当至少一方为未命名类型（如字面量类型）时才允许赋值——该规则是 go 类型安全与语义清晰性的核心设计，而非语法限制。
在 Go 中，type Foo string 并非简单的类型别名（如 C 的 typedef），而是一个全新、独立、具名的类型。它拥有自己的方法集、包作用域身份和类型系统地位。因此，Foo("hello") 不能直接赋值给 string 变量，反之亦然——这并非编译器“不近人情”，而是 Go 显式区分表示（representation） 与含义（meaning） 的关键机制。
例如，标准库中的 os.FileMode 定义为 type FileMode uint32。尽管其底层是 uint32，但你无法将任意 uint32 值（如 0x1234）直接传给期望 FileMode 的函数：
func chmod(name string, mode os.FileMode) error { /* ... */ }
chmod("file.txt", 0644) // ❌ 编译错误：cannot use 0644 (untyped int) as os.FileMode
chmod("file.txt", os.FileMode(0644)) // ✅ 显式转换，表明语义意图若取消该规则（即允许任意同底层命名类型自由赋值），将导致严重语义混淆：
- 类型边界失效：type UserID string 和 type Email string 若可互换，用户 ID 就可能被误传为邮箱，引发权限绕过或日志泄露；
- API 稳定性受损：一旦 type ConfigTimeout int 可与 int 自由混用，后续将其重构为 time.Duration 时，所有隐式 int 赋值点将静默失效或行为异常；
- 文档与意图丢失：命名类型是 API 的自解释契约。func Serve(addr NetworkAddress) 比 func Serve(addr string) 更明确地表达了参数的领域语义，而强制转换 NetworkAddress("localhost:8080") 正是调用者对契约的主动确认。
值得注意的是，该规则对复合类型（如 []float64、map[string]int）“看似宽松”，实则逻辑一致：type Foo []float64 是命名类型，[]float64 是未命名类型，满足“至少一方未命名”的赋值条件；而 type Bar string 与 string 均为命名类型，故不可互赋——差异不在类型种类，而在是否双方皆具名。
因此，当你需要在保持类型安全的前提下实现灵活交互，应合理使用显式类型转换：
type Username string
type Password string
func login(u Username, p Password) { /* ... */ }
user := Username("alice")
pass := Password("s3cr3t")
login(user, pass) // ✅ 类型正确
// login(Username("alice"), "s3cr3t") // ❌ 不允许：Password ≠ string
// login(user, Password("s3cr3t")) // ✅ 显式构造，语义清晰总结而言，Go 的赋值规则不是对开发者设限，而是以轻微的语法成本（一次显式转换），换取长期的可维护性、可读性与安全性。它让类型成为 API 设计的第一道防线，也让每一次类型转换都成为一次有意识的语义声明。
