go 语言规定：函数内部声明的类型标识符，其作用域从 type 关键字后的标识符起始处开始，而非从整个 type 声明语句开头算起；因此嵌套类型声明的顺序直接影响类型解析结果。
go 语言规定：函数内部声明的类型标识符，其作用域从 type 关键字后的标识符起始处开始，而非从整个 type 声明语句开头算起；因此嵌套类型声明的顺序直接影响类型解析结果。
在 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.
这意味着以下代码中：
func fn() {
type user struct {
Feeds []feed // ❌ 此处 'feed' 尚未进入作用域 → 解析为外层的 feed 类型
}
type feed struct{} // ✅ 'feed' 标识符从此处起才开始可见
_ = user{
Feeds: []feed{}, // ⚠️ 编译错误：[]feed 字面量类型（内层 feed）≠ user.Feeds 字段类型（外层 feed）
}
}尽管 type feed struct{} 出现在 user 结构体定义之后，但由于 user 中字段 Feeds []feed 的 feed 标识符出现在 type feed 声明之前，它无法绑定到即将声明的内层 feed，而只能引用外层包级（或上层作用域）已存在的 feed 类型。随后 []feed{} 字面量实际构造的是内层 feed 类型切片，与 user.Feeds 字段期望的外层 feed 切片类型不兼容，从而触发编译错误：
cannot use []feed literal (type []feed) as type []feed in field value
⚠️ 注意：该错误信息看似矛盾（两个 []feed 并列），实则是编译器在提示「左右两侧虽同名，但属不同作用域下的不同类型」——Go 中类型名相同但定义位置不同，即为完全不同的类型（无隐式兼容性）。
✅ 正确写法是调整声明顺序，确保字段引用的类型已在作用域中：
func fn() {
type feed struct{} // 先声明，使标识符生效
type user struct {
Feeds []feed // ✅ 此处 'feed' 可正确解析为内层类型
}
_ = user{
Feeds: []feed{}, // ✅ 类型匹配，编译通过
}
}? 进阶提示：
- 外层包级类型声明（如文件顶层 type feed struct{}）作用域覆盖整个包，且声明顺序无关（因所有顶层声明在同一个块中，按“声明后即可见”处理）；
- 而函数内局部类型声明受更严格的“标识符起始点”规则约束，顺序不可颠倒；
- 若需复用外层类型，建议避免同名重声明；若需隔离类型语义，应确保新类型声明前置，并考虑使用具名别名（如 type localFeed = feed）提升可读性。
总结：这不是 bug，而是 Go 显式、一致的作用域设计体现——它消除了对声明顺序的模糊依赖，强制开发者显式控制类型可见性边界。理解并遵守这一规则，是编写健壮、可维护 Go 代码的重要基础。
