2. Go 项目结构设计原则

在构建一个同时承载契约测试与性能压测的 Go 工程时，项目结构的设计直接决定了测试的可维护性、模块的可替换性以及压测环境的隔离性。本节将围绕四个核心原则展开：标准 Go 项目布局、模块化设计、接口隔离与依赖注入。

2.1 标准 Go 项目布局（Standard Go Project Layout）

Go 社区虽然未强制规定单一项目结构，但 golang-standards/project-layout 已成为事实标准。该布局将代码、测试、文档、部署配置按职责分离，尤其适合需要同时管理单元测试、契约测试与性能压测的中大型项目。

2.2 模块化设计

模块化设计要求将系统拆分为高内聚、低耦合的独立模块。在 Go 中，每个模块对应一个 go.mod 文件，模块之间通过 replace 指令或版本依赖进行连接。这种设计对测试的直接影响体现在：

• 契约测试范围可控：每个模块可独立发布自己的契约（如 Pact 文件），消费者与提供者只需关注模块边界。
• 压测粒度可调：可针对单个模块进行微基准测试（micro-benchmark），也可对组合模块进行端到端压测。
• 依赖升级安全：修改内部模块时，只需运行该模块的契约测试与压测，无需全量回归。

2.3 接口隔离原则（ISP）

在 Go 中，接口隔离原则天然通过小接口实现。一个接口只包含调用方真正需要的方法，避免定义庞大的“上帝接口”。这对测试架构的支撑体现在：

• 契约测试的桩更轻量：只需实现被测试模块依赖的小接口，而非整个服务。
• 压测中的 mock 更精准：性能压测时，对下游依赖的模拟只需覆盖接口中实际调用的方法，减少 mock 开销。
• 接口变更影响最小化：新增方法不会破坏已有契约测试的桩实现。

// 反例：大接口
type UserService interface {
    Create(ctx context.Context, u User) error
    Get(ctx context.Context, id string) (User, error)
    Update(ctx context.Context, u User) error
    Delete(ctx context.Context, id string) error
    List(ctx context.Context, filter Filter) ([]User, error)
    Authenticate(ctx context.Context, token string) (User, error)
}

// 正例：按调用方拆分的小接口
type UserCreator interface {
    Create(ctx context.Context, u User) error
}
type UserGetter interface {
    Get(ctx context.Context, id string) (User, error)
}
type UserAuthenticator interface {
    Authenticate(ctx context.Context, token string) (User, error)
}

2.4 依赖注入（DI）

依赖注入将对象的依赖关系从内部创建转移到外部注入，使得测试时可以轻松替换为桩或 mock。Go 中常见的 DI 方式包括：构造函数注入、参数注入、以及使用 wire 等 DI 框架。

2.5 四原则协同架构图

下图展示了四个原则如何共同支撑一个可测试、可压测的 Go 项目结构：

2.6 原则落地检查清单

在开始编写契约测试与性能压测之前，建议使用以下清单验证项目结构是否满足四个原则：

1. 标准布局：是否包含 /cmd、/internal、/pkg、/test、/api 目录？
2. 模块化：每个业务域是否有独立的 go.mod？模块间是否通过 replace 或版本依赖连接？
3. 接口隔离：每个接口是否只包含 1-3 个方法？是否存在超过 5 个方法的接口需要拆分？
4. 依赖注入：核心业务对象的依赖是否通过构造函数传入？是否存在全局变量或 init() 中创建的依赖？