go 语言规定，函数内部声明的类型标识符作用域从其类型名出现处开始，而非声明块起始处；因此内层同名类型若声明在字段使用之后，字段仍会绑定外层类型，导致类型不匹配错误。
go 语言规定，函数内部声明的类型标识符作用域从其类型名出现处开始，而非声明块起始处；因此内层同名类型若声明在字段使用之后，字段仍会绑定外层类型，导致类型不匹配错误。
在 Go 中，
类型声明的作用域遵循精确的词法位置规则
，而非简单的“块级作用域”直觉。这一点在嵌套作用域（尤其是函数体内重新声明同名类型）时尤为关键。
根据
Go 语言规范 §Declarations and scope
：
The scope of a type identifier declared inside a function begins at the identifier in the TypeSpec and ends at the end of the innermost containing block.
这意味着：
类型标识符在其 type 声明语句中首次出现的标识符位置才真正“进入作用域”
—— 此前的代码（即使在同一 {} 块内）无法感知该新类型。
问题复现与解析
以下代码触发编译错误：
表面上看，两个 feed 类型定义都在 fn() 内部，但 []feed{} 字面量出现在 type feed struct{} 声明
之前
，因此该字面量中的 feed 解析为外层 feed 类型；而结构体字段 Feeds []feed 中的 feed 同样解析为外层类型（因为内层类型尚未就绪）。看似“同源”，实则
左右 operands 实际指向不同包/作用域下的两个独立类型
（即使名称相同、定义相同），Go 视其为不兼容类型。
正确写法：调整声明顺序
只需确保内层 type feed 声明位于所有对其引用之前：
关键注意事项
?
作用域起点是标识符，不是 type 关键字
：type feed struct{} 中的 feed 标识符所在位置才是作用域起始点；
?
不存在“类型重载”或“遮蔽延迟生效”
：内层类型不会 retroactively 影响其声明前的代码；
?
外层类型始终可被显式访问
：若需明确使用外层 feed，可通过包名限定（如 mypkg.feed），但本例中无包限定，故依赖作用域查找规则；
?
结构体字段类型解析独立于字面量
：字段 Feeds []feed 和字面量 []feed{} 分别独立进行标识符解析，均受当前作用域内可用类型约束。
总结
这不是 bug，而是 Go 明确定义的、可预测的作用域行为。它保障了类型解析的确定性与静态可分析性。开发中若需在函数内重构类型，务必遵守“先声明、后使用”原则；借助 IDE 的标识符跳转与作用域高亮功能，可有效规避此类陷阱。理解此规则，是写出健壮、可维护 Go 代码的重要一环。
type user struct {
Feeds []feed // ✅ 绑定到外层定义的 feed 类型
}
type feed struct{} // 外层 feed
func fn() {
type user struct {
Feeds []feed // ❌ 此处的 feed 仍指外层 feed（因内层 feed 尚未声明）
}
type feed struct{} // ⏭️ 内层 feed 作用域从此行开始
_ = user{
Feeds: []feed{}, // ? 编译错误：cannot use []feed literal (type []feed) as type []feed in field value
}
}func fn() {
type feed struct{} // ✅ 先声明，后使用
type user struct {
Feeds []feed // ✅ 现在绑定到内层 feed
}
_ = user{
Feeds: []feed{}, // ✅ 编译通过
}
}