为结构体方法编写可维护单元测试需：抽象依赖为接口并手动模拟、初始化所有字段防panic、用表驱动覆盖多维输入输出、测试与被测代码同包以访问未导出成员。
如何为结构体方法编写可维护的单元测试
Go 中结构体方法的测试本身没有特殊语法，关键在于控制依赖和明确测试边界。如果结构体方法依赖外部服务（如数据库、HTTP 客户端），直接调用会导致测试慢、不稳定、难调试。必须把依赖抽象成接口，再用模拟实现替换。
例如，一个 UserManager 结构体有 GetUserByID 方法，内部调用 db.QueryRow —— 这时不能在测试里连真实数据库。应定义 DBQuerier 接口，让 UserManager 依赖该接口，而非具体 *sql.DB。
- 结构体字段尽量导出或提供访问方法，否则测试中无法构造有效输入或断言内部状态
- 避免在方法内直接调用全局函数（如
time.Now()、rand.Intn()），改用可注入的函数字段或接口 - 测试文件名保持为
xxx_test.go，且与被测代码同包（非xxx_test子包），才能访问未导出字段或方法
用 interface + mock 实现结构体依赖隔离
Go 原生不带 mock 框架，但靠接口+手动模拟已足够。核心是：找出结构体方法实际调用的外部行为，将其提取为接口，然后在测试中传入满足该接口的模拟类型。
比如结构体有字段 httpClient *http.Client，而方法中调用了 c.Do(req) —— 更好的做法是定义 HTTPDoer 接口含 Do(*http.Request) (*http.Response, error)，再让结构体持有该接口值。
- 模拟类型只需实现接口中被实际调用的方法，无需全量实现
- 在模拟类型中用字段（如
Resp *http.Response、Err error）控制返回值，便于不同测试用例切换行为 - 不要用第三方 mock 库（如 gomock）去生成大量模板代码；手工 mock 更轻量、更易读、调试更直接
测试结构体方法时常见 panic 场景及规避方式
测试中出现 panic: runtime error: invalid memory address or nil pointer dereference 是最常遇到的问题，根本原因通常是结构体字段未初始化就调用方法。
