Go设计模式重在接口契约与组合，而非继承和类图；标准库中io.Reader、http.HandlerFunc等体现策略与适配器思想；应先写真实需求再提炼抽象，避免过度设计。
设计模式不是 Go 语言的必需品，盲目套用反而会破坏 Go 的简洁性。Go 新手该先理解语言本身如何“自然表达意图”，再看哪些模式是被语言特性消解了、哪些是值得保留的变体。
先忘掉 UML 和“23 种模式”这个概念
Go 没有继承、没有抽象类、没有接口实现强制绑定，传统面向对象模式里的 FactoryMethod、TemplateMethod、AbstractFactory 大部分失去意义。强行翻译会导致代码臃肿、类型混乱。
- 别一上来就画类图——Go 关注的是
struct+func+interface三者如何协作 - 别背“某模式解决某问题”——先写一个真实小需求（比如读配置、发 HTTP 请求、管理连接池），再回头看看哪段逻辑重复、哪处耦合难测
- Go 标准库里几乎不出现模式名称，但处处是模式思想：比如
io.Reader是策略模式的极简实现，http.HandlerFunc是函数式适配器
从标准库和 net/http 中认出真模式
Go 的模式长在接口定义和组合方式里，不是靠继承树堆出来的。重点观察标准库怎么用 interface{} 和匿名字段做解耦。
-
io.Reader和io.WriteCloser是行为契约，任何满足签名的类型都能插拔——这就是策略模式的本质，不用Strategy类名也能成立 -
http.Handler接口只有ServeHTTP(http.ResponseWriter, *http.Request)一个方法，而http.HandlerFunc把函数转成满足该接口的类型——这是适配器模式，且只用一行转换：func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) { f(w, r) } -
net/http.Server字段里嵌入Handler，又允许传入任意实现了该接口的值——这就是组合优于继承的直接体现，不是“装饰器模式”的教科书复刻，但效果一致
动手改写一个“过度设计”的例子
新手常写的“规范”代码，比如为日志加个 LoggerInterface 再搞个 NewFileLogger()、NewConsoleLogger() 工厂，其实远不如直接用 log.Logger + io.Writer 组合来得清晰。
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
立即学习“go语言免费学习笔记（深入）”；
- 删掉所有带
Factory、Manager、Context（非context.Context）后缀的包名和类型名 - 把“创建对象”的逻辑下沉到 main 或 cmd 层，业务层只依赖接口，比如
type Storer interface { Save(context.Context, []byte) error } - 用结构体字段直接持有依赖，而不是通过 setter 注入：
type Service struct { storer Storer cache Cache }—— 初始化时传进去，不提供修改入口
真正需要警惕的，是那些 Go 里“不存在但你硬要造”的东西
比如为每个实体写 xxxRepository 接口、搞一套 Usecase 层包装单个函数、用 errors.Wrap 堆叠 5 层调用栈——这些不是模式，是惯性思维的副产品。
- Go 的错误处理是值语义，
if err != nil就地处理或返回，不需要try/catch式的模板 - 并发原语（
goroutine+channel）天然支持生产者-消费者、管道等模式，不必套Observer或Mediator名称 - 如果某个“模式”让你多写了 3 个文件、5 个接口、2 层包装，却没让测试更容易写、逻辑更易替换、错误更易定位——那就不是 Go 的模式，只是 Java 的影子
最常被忽略的一点：Go 的设计模式，往往藏在接口定义的粒度里。一个方法的接口（如 io.Closer）比十个方法的接口（如 java.util.Collection）更符合 Go 哲学。别急着实现，先想清楚——这个抽象，到底要隔离什么变化？
