构造函数注入是go中事实标准的di方式，类型安全、可读性强、便于测试；应避免循环依赖、过度注入和运行时di框架，重视接口抽象与边界划分。
构造函数注入是Go里最直接可靠的DI方式
Go没有运行时容器，构造函数注入就是事实标准。它不依赖任何框架，类型安全、可读性强、IDE能跳转、单元测试时mock也自然——只要接口定义清晰，替换实现就只改一行。
-
NewUserService必须接收所有依赖（如*sql.DB、EmailSender），不能在内部调用newDB()或newSMTPClient() - 接口要小而专注，比如
PaymentClient不该同时含Charge()和Refund()；拆成两个接口更利于测试隔离 - 避免把配置结构体（如
Config）整个传入构造函数——应提取所需字段，或封装为行为接口（如RateLimiter）
wire生成代码前必须理清依赖拓扑
Wire不是魔法，它只忠实翻译你写的依赖图。一旦出现循环引用（比如 A 依赖 B，B 又依赖 A 的某个方法），wire build 会直接报错，且错误信息只提示“cycle detected”，不指明具体哪条边。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 先画草图：从顶层 handler 开始，逐层向下标出每个 struct 依赖什么，箭头方向必须单向（只能从上层指向底层）
- 提供者函数（
func() *DB）命名要带模块前缀，比如userdb.NewDB，避免不同包里同名函数冲突 - 不要在 provider 里做副作用操作（如初始化 Redis 连接池并 ping），这些应放在
main()或单独的Init()函数里
测试时接口 mock 的关键不是工具而是契约设计
Go里没法 patch 函数，所以“mock f1()”本质是 mock 它所属的结构体。如果 f1() 是顶层函数，又没被包装进接口，那它就无法被替换成 fake 实现——这是设计缺陷，不是测试技术问题。
- 把所有外部调用（HTTP、DB、发邮件）都抽象为接口，并让业务逻辑只依赖这些接口
- mock 实现写在测试文件里即可，不用第三方库；例如
type MockEmailSender struct{ called bool }+Send()方法 - 警惕“过度注入”：一个
UserService不该接收Logger、MetricClient、Tracer三个独立接口，应合并为Telemetry接口，否则调用方组装成本飙升
IOC-golang这类运行时DI框架在真实项目中容易失控
它用反射注册类型、自动解析依赖，在小demo里很炫，但上线后你会遇到三类问题：启动慢（反射扫描耗时）、报错晦涩（“failed to resolve type X” 没上下文）、调试困难（断点进不到自动生成的装配代码）。
- 除非团队已统一使用且配套了完善的诊断工具链，否则建议 stick with wire 或纯手动
- IOC-golang 的 tag 注入（如
//go:inject）会让结构体字段语义模糊，db *gorm.DB `inject:""`看不出它是必需依赖还是可选 - 它的生命周期管理（singleton/scoped）在微服务里常与 HTTP 请求生命周期错位，比如把 request-scoped 的 validator 注册成 singleton，会导致状态污染
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
