🚀 省流助手（速通结论）
- 属性禁区：Go 的属性是物理内存布局，必须在
struct定义时锁死，不支持任何形式的动态外挂。 - 接口纯度：Go 接口是纯行为契约。TS 中那种“既能存 id 又能调 read()”的混合接口在 Go 里是语法非法。
- 领地意识：Go 的方法挂载有严格的包（Package）隔离。你不能像 TS 扩展
interface或修改原型链那样去动内置类型或其他包的结构体。 - Type 的本质：TS 的
type擅长类型组合与映射计算；Go 的type则是物理隔离的类型声明，即使底层结构相同，也不存在自动兼容。
1. 属性：TS 是动态涂鸦，Go 是模具浇筑
在 TS 中，interface 描述的是一种“期望的形状”，我们可以通过交叉类型（Intersection Types）实现极其灵活的形状组合。但 Go 的 struct 本质是连续的内存布局，字段在编译那一刻就“焊死”了。
TypeScript (形状组合与扩展)
interface User { name: string }
// 交叉类型：在原形状基础上动态叠加新形状
type Admin = User & { role: string };
Go (静态内存布局)
type User struct { Name string }
// ❌ 错误：Go 不支持任何形式的“运行时属性外挂”或“类型交叉”
// 你无法给 User 动态增加 Role 属性
// ✅ 只能通过“组合（Composition）”重新铸模
type Admin struct {
User // 嵌入 User 的所有字段
Role string
}
🪝 思维钩子：Go 的结构体属性不是键值对，而是内存坑位。你想外挂属性？除非你能在运行中的内存里凭空变出一个地址。
2. 接口：TS 是“全能说明书”，Go 是“入场券”
这是 TS 程序员最容易撞墙的地方：习惯性地想给接口定义一个属性。
TypeScript (混合契约：属性+方法)
interface Logger {
level: string; // ✅ 描述了对象长什么样
log(): void; // ✅ 描述了对象能干什么
}
Go (行为契约：仅方法)
type Logger interface {
// Level string // ❌ 编译报错：接口里不许塞入任何叫“属性”的沙子
Log()
}
🪝 思维钩子：TS 的接口是“对象的规格说明书”；Go 的接口是“能力的入场券”。它只关心你能对外提供什么服务（方法），完全不关心你肚子里存了什么（字段）。
3. 方法外挂：有边界的“分布式定义”
Go 的方法虽然写在 struct 花括号外，看起来很自由，但它有极其严格的领地意识。
TypeScript (原型与接口扩展)
// TS 可以通过声明合并（Declaration Merging）或原型链，随时给类型增加能力
interface String {
toMyUpper(): string;
}
Go (包级别隔离)
// ❌ 错误：不能给内置类型 int 挂方法
func (i int) MyFunc() { ... }
// ❌ 错误：不能给其他包（如 strings 包）的类型挂方法
func (s strings.Builder) MyFunc() { ... }
// ✅ 正确：只能给“本包内定义”的类型挂方法
type MyInt int
func (i MyInt) MyFunc() { ... }
🪝 思维钩子：Go 的方法外挂本质是“分布式定义”。它要求你必须是该类型的“法定监护人”（在同一个包里），否则你没资格给它定规矩。
4. Type 定义：类型计算 vs 物理声明
TS 的 type 具备极强的编程属性（如映射类型、条件类型），而 Go 的 type 是为了明确边界。
TypeScript (类型组合与计算)
type Status = "active" | "inactive";
type ReadOnly<T> = { readonly [P in keyof T]: T[P] }; // 强大的类型计算
Go (物理隔离的新类型)
type MyInt int
var a MyInt = 10
var b int = 20
// a = b // ❌ 报错：即使底层都是 int，但在 Go 眼里它们是“生殖隔离”的
a = MyInt(b) // ✅ 必须显式转换
🪝 思维钩子：TS 的 type 是逻辑上的建模；Go 的 type 是物理上的隔离。即使底层结构一模一样，Go 也会强制你通过显式转换来承认它们是不同的物种。
结语：从“结构形状”回归“行为本质”
在 TypeScript 的重度使用经验中，我们习惯了 基于结构形状（Structural Typing） 的编程范式。在 TS 的世界里，interface 是一个全能的形状描述符，我们通过交叉类型、映射类型等工具，极其灵活地定义着数据的拓扑结构。
但转到 Go 之后，你会发现这种关于“形状”的直觉需要被重新拆解。Go 并不是一门纯粹的传统面向对象语言，它选择了一条更偏向工程物理的路径：
- 数据的本质：回归到物理内存布局（Struct）。它是静态的、不可动态外挂的。这种“死板”保证了内存的可预测性。
- 行为的本质：回归到纯粹的方法契约（Interface）。它剥离了所有数据属性，强制你只关注“这个东西能做什么”，而非“它长什么样”。
从 TS 的“橡皮泥式”自由组合，切换到 Go 的“乐高式”扁平组合，起初确实会产生巨大的不适。你会质疑为什么接口不能带属性，为什么不能动态扩展类型。但当你习惯了这种基于行为契约的解耦方式后，你会获得一种极致的确定性：数据归数据，行为归行为，边界清晰，逻辑即白盒。
这不只是语法的转型，而是一场从“逻辑建模”到“物理工程”的思维对齐。
