1. 课程导学与项目全景：依赖注入与Mock在Go项目中的价值
1.1 为什么需要依赖注入与Mock？——从“不可测试”到“可压测”
在Go后端项目中，业务逻辑往往直接耦合数据库、外部API、缓存等真实依赖。这种“硬编码”写法在单体阶段尚可运行，但一旦进入微服务、压测、持续交付场景，就会暴露出三个致命问题：
- 单元测试不可写：测试订单服务必须启动MySQL和Redis，导致测试变成集成测试，速度慢、不稳定。
- 压测无法隔离：压测时真实支付网关会拒绝重复请求，或产生真实扣款，无法安全压测。
- 代码难以扩展：替换支付渠道或数据库驱动需要修改业务代码，违反开闭原则。
依赖注入（DI）将依赖的创建与使用分离，Mock则通过模拟接口行为，让测试和压测脱离真实基础设施。两者结合，是构建可测试、可压测、可演进的Go项目的基石。
课程核心主张： 依赖注入不是“为了用而用”的设计模式，而是为了让代码在测试、压测、生产三种环境中都能以同一套逻辑运行，仅替换依赖实现。
1.2 课程目标与学习路径
本课程通过一个完整的订单服务 + 支付网关实战项目，带你走通从依赖注入设计到压测闭环的全流程。完成本课程后，你将掌握：
| 模块 | 核心能力 | 产出物 |
|---|---|---|
| 依赖注入设计 | 使用接口抽象 + 构造函数注入，解耦业务与基础设施 | 可替换依赖的订单服务核心代码 |
| Mock 策略 | 基于接口生成Mock，覆盖成功、超时、异常场景 | 支付网关Mock + 单元测试套件 |
| 压测闭环 | 在Mock环境下执行压测，收集延迟/吞吐/错误率，反推代码优化 | 压测脚本 + 性能报告 + 优化记录 |
| 项目结构 | 按职责分层：handler / service / repository / mock | 可复用的Go项目骨架 |
1.3 实战项目全景图：订单服务 + 支付网关
我们构建一个简化但完整的电商订单系统。核心流程为：用户下单 → 订单服务创建订单 → 调用支付网关扣款 → 更新订单状态。项目采用分层架构，所有外部依赖均通过接口注入。
1.4 依赖注入与Mock的价值对比
下表总结了在订单服务项目中，使用DI+Mock前后的关键差异：
| 维度 | 传统硬编码方式 | 依赖注入 + Mock 方式 |
|---|---|---|
| 单元测试 | 需要启动MySQL、Redis，测试慢且不稳定 | 注入Mock，毫秒级运行，100%稳定 |
| 压测安全 | 压测会真实调用支付网关，产生扣款 | Mock支付网关，零成本安全压测 |
| 异常模拟 | 难以模拟超时、网络错误、余额不足 | Mock可精确控制返回错误、延迟、panic |
| 代码耦合 | 业务逻辑直接依赖具体实现 | 业务逻辑只依赖接口，实现可替换 |
| 扩展性 | 新增支付渠道需修改业务代码 | 新增实现类即可，业务代码零改动 |
1.5 压测闭环：从Mock到性能优化
本课程的核心闭环是“依赖注入 → Mock测试 → 压测 → 分析 → 优化”。在Mock环境下，我们可以安全地模拟高并发、慢响应、异常抖动，从而验证系统的极限行为。
压测闭环五步法：
1. 使用依赖注入将真实支付网关替换为Mock支付网关
2. 编写压测脚本（基于Go的pprof或wrk），对订单服务发起高并发请求
3. 收集延迟分布、吞吐量、错误率、CPU/内存火焰图
4. 定位瓶颈（如数据库连接池不足、序列化开销大）
5. 优化代码后重复压测，验证改进效果
1. 使用依赖注入将真实支付网关替换为Mock支付网关
2. 编写压测脚本（基于Go的pprof或wrk），对订单服务发起高并发请求
3. 收集延迟分布、吞吐量、错误率、CPU/内存火焰图
4. 定位瓶颈（如数据库连接池不足、序列化开销大）
5. 优化代码后重复压测，验证改进效果
1.6 本章小结
依赖注入与Mock不是“银弹”，但它们是Go项目走向工程化、可测试、可压测的必经之路。本课程将带你从零搭建一个订单服务+支付网关项目，每一步都贯彻DI+Mock思想，最终形成一个可复用的压测闭环方法论。