Go语言是三位Google工程师为解决C++编译慢、并发难、依赖乱等工程痛点，以“少即是多”为原则设计的减法型语言：砍掉继承、异常、泛型（至1.18才加）、隐式转换；保留特性均支持单趟解析以保编译速度；goroutine/channel为务实调度折中；接口强调运行时行为契约而非声明式实现。
Go 语言不是“从零抽象设计出来”的，而是三位 Google 工程师在真实工程痛感下，用白板写出来的减法清单。
为解决 C++ 编译慢、并发难、依赖乱而生
2007 年，Rob Pike、Robert Griesemer 和 Ken Thompson 在 Google 内部用 20% 时间启动项目，直接动因很具体：
- C++ 编译一个大型分布式服务要十几分钟，改一行代码等编译像“罚站”
- 写并发得手动管线程、锁、条件变量，出错率高且难调试
- 头文件依赖像毛线团，
make经常失败，新人配环境要半天 - 部署时得打包一堆动态库，不同机器环境稍有差异就 panic
他们没想造新范式，就想让“写服务代码像写脚本一样快，跑起来像 C 一样稳”。
白板上的第一条原则：少即是多
公开资料里多次提到，最初那块白板上列的不是特性，而是砍掉什么：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 去掉类继承（
type A struct{ B }是组合，不是extends） - 去掉构造函数、析构函数、异常（
panic不是 try/catch，只用于真正异常） - 去掉泛型（直到 Go 1.18 才加，且设计极度克制）
- 去掉隐式类型转换（
int和int64不能混用）
所有保留的语法，都必须能被编译器单趟解析完——这是为了快。连 go fmt 的风格都是强制的，因为“省掉团队争论缩进该用几个空格的时间，就是省掉一次线上事故的排查时间”。
goroutine 和 channel 不是炫技，是调度器级妥协
他们不要 pthread，也不要 Erlang 那种完全用户态调度，而是做了个务实折中：
- 用
g（goroutine）、p（processor）、m（OS thread）三层模型，让十万级并发不压垮系统 -
channel不是消息总线，本质是带锁的环形缓冲区 + goroutine 唤醒队列，send和recv操作必须成对出现，否则直接fatal error: all goroutines are asleep - deadlock! - 没有
yield、没有resume，调度时机全由 runtime 控制——你写代码时根本不知道哪行会切走，但也不需要知道
这种设计让 Go 程序员不用学“协程生命周期”，但也意味着：一旦写出阻塞逻辑（比如在 for 里死等 channel），程序就卡死，没有任何隐藏兜底。
接口不是语法糖，是运行时契约
Go 接口不声明“我实现什么”，而是问“你能做什么”。这带来两个硬约束：
- 结构体方法接收者是值还是指针，直接决定它能不能赋给某个接口——
io.Writer要求(*bytes.Buffer).Write，传bytes.Buffer{}就报错 - 接口值底层是
iface（含 itab 指针 + 数据指针），每次赋值都要查表；空接口interface{}是eface，更轻但无方法表 - 接口比较（
==）可能 panic，因为底层数据如果是[]byte或map[string]int，就不可比较
最常被忽略的一点：接口的“松耦合”是以可寻址性为代价的。函数返回的临时 struct、map 中的 value，哪怕方法集完全匹配，也无法自动取地址去满足指针接收者接口——这不是 bug，是设计铁律。
