internal包通过编译器强制访问控制隔离实现细节，使重构局限于包内；replace临时解耦腐化依赖；接口应定义在调用方层以降低重构成本；依赖图单向性是重构不可逾越的硬约束。
为什么 internal 包能挡住 80% 的重构蔓延
Go 的 internal 包不是语法糖，是编译器强制执行的访问控制机制。只要把实现细节（比如数据库查询逻辑、第三方 SDK 封装）放进 internal/repository/db 或 internal/adapter/sms，外部模块——包括同项目下的其他 service、cmd 甚至测试目录——就无法直接 import 它们。
这意味着：你改了 internal/repository/db 里的 SQL 构建方式，只要接口没变（比如 UserRepository 的方法签名不变），所有调用方完全无感。重构范围被物理隔离在包内，不会像裸写在 service 里那样，一动牵全身。
- 错误做法：把
sql.DB直接暴露给service层，导致业务逻辑里混着db.QueryRow调用 - 正确做法：只暴露
GetUserByID(id int) (*User, error)这类语义化方法，底层换 PostgreSQL 或加缓存都不影响上层 - 注意：
internal的路径必须严格满足 Go 规则——只有父目录及其同级子目录可导入，cmd/app和pkg/util都不能越界引用
go.mod + replace 是临时解耦的救命绳
当两个微服务（比如 user-service 和 order-service）原本共享一个私有公共库，但该库已腐化、文档缺失、又不敢贸然升级时，replace 指令能让你在不改动任何业务代码的前提下，把依赖“钉死”到一个干净分支或本地副本。
例如，order-service 的 go.mod 中写：
replace github.com/yourorg/common => ./local-fork/common
然后你在 ./local-fork/common 里只保留 types.User 和 errors.ErrInsufficientBalance 这两个真正需要的定义，删掉所有无关函数和依赖。这样既断开了对烂库的耦合，又避免了复制粘贴类型定义带来的维护地狱。
- 别用
replace长期替代重构——它只是争取时间的缓冲带 - 替换目标必须是合法 module（含
go.mod），不能指向任意目录 - CI 环境需确保
replace路径存在且可读，否则构建失败
接口定义放在哪，决定了重构成本高低
把 UserRepository 接口放在 internal/service 里，还是放在 internal/repository 里？答案是：放在调用方所在的层——也就是 internal/service。
理由很实际：service 层知道它需要什么能力（查用户、删用户），但不知道也不该关心怎么查（SQL？Redis？HTTP 调用？）。所以接口由 service 定义，repository 实现。这样当你把 MySQL 换成 DynamoDB，只需重写 repository/dynamo 包，连 go mod tidy 都不用跑。
- 反模式：在
repository包里定义interface，然后让service去 import 它——这等于让基础设施决定业务契约 - 接口方法参数尽量用基本类型或
model包里的结构体，避免传入*sql.Tx或context.Context（后者应由 service 层传入） - 一个接口只对应一类操作，比如
UserReader和UserWriter分开，避免“大而全”的接口导致实现方被迫实现无用方法
重构时最常被忽略的硬约束：依赖图不可逆
Go 的包导入方向是单向的：上层可以 import 下层，下层绝不能 import 上层。如果你发现 internal/repository 里 import 了 internal/service，说明架构已经泄漏——可能是为了复用某个校验函数，或是误把业务规则塞进了数据层。
这种泄漏会让重构变成拆弹作业：改一处，要同步改三处，还容易漏掉某条隐式依赖链。工具上可以用 go list -f '{{.Deps}}' ./internal/... 手动检查，但更有效的是在 CI 中加入静态分析，比如用 golangci-lint 配置 interfacer 和 goimports 规则，自动拦截跨层 import。
真正的难点不在技术，而在人：当开发同学说“我就加一行日志，顺便用下 service 里的工具函数”，这个“顺便”就是架构滑坡的起点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
