internal目录无法限制第三方调用底层API，真正有效的限制手段只有三种：用接口隔离实现、工厂函数+非导出字段、禁止返回可修改的底层对象。
不能靠 internal 目录限制第三方模块调用你的底层 API —— 它只拦 import 路径，不拦运行时行为；第三方模块只要没直接 import 你内部包，就能通过你导出的 public 接口间接调用甚至滥用。
第三方模块能调用哪些 API，完全由你导出的接口决定
Go 没有 private method 或 package-level access control。只要一个函数、类型或方法是导出的（首字母大写），且被第三方模块 import 了你的主模块，它就能调用：
-
func NewClient() *Client返回的*Client，哪怕 Client 定义在internal/transport里，只要Client类型本身是导出的，第三方就能保存、传参、甚至反射调用其方法 -
type Option func(*config)这种函数类型，如果导出，第三方就能自己造Option并传入你的构造函数 - 返回
io.Reader的函数，第三方能直接io.Copy；但如果你返回的是具体 struct（如*json.Decoder），它就能调用.UseNumber()等非公共契约方法
真正有效的限制手段只有三种
不是加 internal，而是重构 API 设计：
-
用接口隔离实现：导出
type Service interface { Do() error }，不导出serviceImpl；所有构造函数返回接口，而非具体类型 -
工厂函数 + 非导出字段：让
NewService()返回接口，内部 struct 字段全小写；即使第三方拿到指针，也无法直接赋值或读取敏感字段 -
禁止返回可修改的底层对象：别返回
*http.Client、sql.DB、redis.Client等；改用封装后的DoRequest()方法，或返回不可变副本（如func Config() ConfigCopy）
常见误用：internal 放结构体 ≠ 安全
比如你把 type transport struct{ addr string } 放进 internal/http，但同时导出 func NewTransport(addr string) Transport，其中 Transport 是导出接口 —— 第三方仍能：
立即学习“go语言免费学习笔记（深入）”；
- 调用
NewTransport("x")得到实例 - 用反射读取
addr字段（只要它导出） - 若
transport实现了导出方法（如SetTimeout()），就能直接调用 - 甚至用
//go:linkname绑定私有方法（虽不推荐，但技术上可行）
关键不是“放哪”，而是“暴露什么”。internal 只防止 import "yourmod/internal/http"，拦不住通过 public surface area 的穿透。
想彻底切断调用链？只能靠编译期断连
如果某个底层能力绝对不允许第三方触达（比如密钥加载、本地 socket 连接），唯一可靠方式是：
- 不提供任何导出函数返回该能力
- 不暴露任何含该能力的接口（哪怕空接口
interface{}也不行） - 把相关逻辑下沉到
main包或 CLI-only 代码中，确保它不出现在任何go list -f '{{.Name}}' ./...可见的包路径里 - 用 build tag（如
//go:build !lib）把敏感实现和 library mode 隔开，让go build -tags lib时直接编译失败
最易被忽略的一点：只要你导出了一个接收 context.Context 并执行某操作的函数，第三方就可能把它塞进自己的 goroutine、timeout 控制甚至 mock 测试里 —— 限制不在路径，而在契约设计本身。
