Go 中应定义窄接口（如Calculate(int64) int64）替代interface{}，避免运行时错误、提升IDE支持与编译检查；用map注册构造函数实现策略动态加载；金额统一用int64“分”处理精度；共享状态需加锁或抽离至外部服务。
为什么 Go 里不用 interface{} 实现策略，而要用接口类型
Go 没有传统 OOP 的抽象类或泛型策略基类，硬塞 interface{} 会导致运行时类型断言失败、IDE 失去跳转能力、编译期无法检查方法签名。真正该做的是定义一个窄接口，只包含策略必须实现的行为，比如 Calculate(price float64) float64。
- 接口越小越好，电商折扣策略只关心“输入原价，输出折后价”，别加
Validate()或GetName()这类非核心方法 - 所有具体策略（满减、打折、直降）都实现这个接口，编译器能立刻报错缺失方法
- 如果后续要加日志或限流，用装饰器包装接口实现，而不是往接口里塞新方法
如何让不同促销活动动态加载对应策略
不能靠 if/else 硬编码判断活动类型再 new 具体结构体——那等于把策略逻辑又写死在调用处。正确做法是用 map 做注册表，key 是活动类型字符串（如 "flash_sale"），value 是实现了策略接口的构造函数（不是实例）。
- 注册时机放在
init()函数里，避免漏注册或重复注册 - 构造函数返回指针（如
func() DiscountStrategy），避免值拷贝导致状态丢失（比如带计数器的限时限量策略） - 查找时先查 map，没命中直接 panic 或返回默认策略，别默默 fallback 到 0 折扣
- 示例：
var strategyMap = map[string]func() DiscountStrategy{ "coupon": func() DiscountStrategy { return &CouponDiscount{} }, "bulk": func() DiscountStrategy { return &BulkDiscount{} }, }
折扣计算中浮点数精度问题怎么处理
Go 的 float64 在价格计算中会累积误差，比如 99.99 * 0.8 得到 79.99200000000001，数据库存不进 DECIMAL(10,2)，前端展示也奇怪。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有金额统一用
int64存“分”，策略输入输出都以分为单位，Calculate方法签名应为Calculate(amountCents int64) int64 - 不要在策略内部做
float64运算后再math.Round，四舍五入规则和财务要求可能不一致 - 如果上游已传
float64，用strconv.ParseInt(fmt.Sprintf("%.f", price*100), 10, 64)转，但更稳妥是让调用方负责转整型
并发场景下共享策略状态是否安全
有些策略需要维护状态，比如“前 100 名享 5 折”的 counter 字段。如果多个 goroutine 同时调用 Calculate，不加保护会出错。
立即学习“go语言免费学习笔记（深入）”；
- 策略实例默认不共享，每次活动请求都 new 一个新实例最安全（无状态策略可复用）
- 如果真要共享状态（如全局限量），必须用
sync.Mutex或atomic，且锁粒度要细——别在Calculate全程加锁，只锁计数更新那段 - 更推荐把状态抽离到独立服务（如 Redis 计数器），策略本身保持无状态，否则单元测试难写、横向扩展受限
策略最难的从来不是接口怎么写，而是折扣规则变更时，怎么让新旧策略共存、灰度、回滚——这些和接口设计无关，得靠配置中心 + 版本号 + 请求上下文里的活动 ID 来驱动。
