internal目录不会拖慢函数调用，它仅为编译期可见性约束，不引入任何运行时开销、不改变汇编指令、不影响内联决策；真正影响性能的是接口动态派发、指针接收者nil检查和逃逸导致的堆分配。
Go 语言里不存在“跨模块调用”这个性能概念——Go 没有模块（module）级别的运行时调用开销，只有包（package）间调用，而它的开销和是否跨 internal、是否跨 go mod、是否跨目录完全无关。
为什么 internal 目录不会拖慢函数调用
internal 是纯编译期约束，不是运行时机制。它不插入任何跳转指令，不改变函数签名，也不影响内联决策。
- 只要函数满足内联条件（比如小、无闭包、非指针接收者方法体过大），
go build -gcflags="-m"就会显示can inline，无论它在internal/util还是pkg/codec - 错误认知常来自：把
internal当成“必须加 wrapper 才能用”的隔离墙，结果人为引入func (c *Client) Do() { return c.impl.do() }这类转发层，间接调用 + 接口调度才是真开销来源 - 编译器生成的汇编代码里，
internal/foo.Bar()和public/foo.Bar()完全一样；你可以用go tool compile -S main.go | grep "foo\.Bar"验证
真正影响跨包调用性能的三个常见原因
不是目录结构，而是调用方式本身。
-
接口动态派发：用
interface{ Do() }调用比直接调用具体类型慢 2–5 倍，因为要查itable；高频路径上优先传函数值或具体类型，比如func(fn func(int) int, x int) int -
指针接收者方法隐含 nil 检查：每次调用
(*T).Method()前编译器插入test %rax, %rax; je，看似微小，但百万次循环里可观测到延迟上升 -
逃逸导致堆分配 + GC 压力：比如
return &Result{}让对象逃逸，后续调用链中所有基于该指针的操作都失去栈优化机会；用go build -gcflags="-m -l"看清哪些变量逃了
如何验证某次跨包调用有没有额外开销
别猜，用工具看机器码和运行时行为。
- 检查是否内联：
go build -gcflags="-m -l" main.go，搜索目标函数名，看到inlining call to表示成功，cannot inline: unhandled node则说明被拒（通常因闭包、defer 或太大） - 对比汇编差异：对两个包分别执行
go tool compile -S pkg1/foo.go > foo.s和go tool compile -S pkg2/bar.go > bar.s，观察调用目标是否为直接CALL还是经由寄存器间接跳转 - 压测真实路径：用
go test -bench=. -benchmem对比CallFromSamePackage和CallFromInternalPackage的 ns/op，差值若超过 1ns，大概率是上面提到的接口/逃逸问题，而非internal
最容易被忽略的是：开发者常把“不能 import internal”误解为“调用 internal 有代价”，其实它只是编译器的一道门禁，连门框都不参与执行。性能优化永远发生在调用点——参数怎么传、类型怎么选、内存怎么活，而不是目录怎么放。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
