封装的核心是控制变化半径，而非追求代码美观；应按业务域（如/user、/order）建包，禁止跨包直连实现，用internal/划边界、pkg/提契约，接口定义在调用方，Facade仅协调不决策。
直接说结论：封装不是为了“写得漂亮”，而是为了把业务变化关进盒子里——盒外代码只认接口，盒内怎么改都不影响调用方。真正降低开发难度的封装，核心是控制变化半径，而不是堆砌设计模式。
按业务域建包，别按技术层建目录
看到 controllers/、services/、repositories/ 这种顶层目录，说明封装已经失效。所有用户相关逻辑散落在三个目录里，改个密码重置流程就得横跨七八个文件。
- 正确做法是每个业务功能自成一包：
/user、/order、/payment -
/user包内再拆：user/service.go、user/repo.go、user/handler.go，但对外只暴露UserService接口和CreateUserRequest类型 - 禁止跨包直连实现，比如
import "myproj/internal/order/repo"—— 这会把订单库存逻辑硬编码进用户模块，后续改库存策略就得同步改用户代码
用 internal/ 划死边界，用 pkg/ 提炼契约
internal/ 不是“放杂项的垃圾桶”，而是 Go 工具链强制的访问防火墙；pkg/ 也不是“通用工具集合”，而是对外承诺的稳定契约。
-
internal/config、internal/middleware可被cmd/api和cmd/worker共用，但外部项目绝对 import 不进来 -
pkg/logger必须有完整单元测试和文档注释，一旦被 3 个以上业务包强依赖，就要警惕它正演变成“上帝包”——此时该拆出pkg/logzap（结构化日志）和pkg/logstd（标准输出） - 别把错误处理塞进
pkg/common，命名模糊等于契约模糊；pkg/errx才能让人一眼明白：这是带分类码、可序列化的错误封装
Facade 封装复杂流程，但别让它变成新胶水层
当一个业务操作需要串起 4 个子系统（如下单 → 创建订单 → 扣库存 → 发通知 → 调支付），直接暴露调用链会让所有调用方重复写同样逻辑。这时 OrderFacade 是解药，但容易变成新坑。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Façade 必须只做协调，不做业务判断——
PlaceOrder()里不能有if isVIP { ... }这类分支，那是order/service.go的事 - 工厂函数
NewOrderFacade()要返回接口类型（OrderClient），而非具体结构体，否则调用方又开始依赖字段名 - 最容易踩的坑：把 Facade 当成万能入口，往里塞日志、重试、熔断——这些该由
internal/middleware统一注入，Facade 只管顺序编排
模块间通信必须走接口，且接口定义在调用方
Go 没有继承，但开发者常误用“包名相同就天然耦合”的思维。结果是改 user 包时，发现 payment 包里一堆 user.User 直接引用，字段一加就全编译不过。
- 跨业务调用，接口定义必须放在调用方包里（如
payment包定义UserGetter接口），被调方（user）只负责实现 - 被调方导出的类型只能是 DTO 或 ID，禁止导出数据库模型（
user/model.go里的User结构体绝不能被其他包 import） - 如果某个包 import 超过 3 个其他业务包，说明它正在承担路由或编排职责——该拆出独立的
orchestration/包，用事件驱动替代直接调用
真正难的从来不是写封装，而是每次新增一个功能时，都得重新判断：这个逻辑该放进现有包，还是新开一个？边界模糊的地方，就是下次重构时最痛的点。
