在 go 中，调用其他包的函数前必须显式导入该包；不存在绕过 import 语句直接调用未导入包中函数的机制。
在 go 中，调用其他包的函数前必须显式导入该包；不存在绕过 import 语句直接调用未导入包中函数的机制。
Go 的设计哲学强调显式依赖和编译时可验证的模块边界。这意味着：
- 所有跨包访问（包括函数、变量、类型）都必须通过 import 声明显式引入；
- 编译器在构建阶段严格检查所有符号引用是否来自已导入的包；
- 不存在类似 Python 的 importlib.import_module() 或 Java 的反射类加载机制来动态导入未声明的包。
例如，假设有如下 mypkg.go：
// mypkg.go
package mypkg
import "fmt"
func Test() {
fmt.Println("test")
}则 main.go 必须按如下方式编写才能合法调用 mypkg.Test()：
// main.go
package main
import "mypkg" // ✅ 必须导入
func main() {
mypkg.Test() // ✅ 正确调用
}⚠️ 常见误区与注意事项：
- ❌ import _ "mypkg"（空白导入）仅执行包初始化，不暴露其导出标识符，仍无法调用 Test()；
- ❌ 尝试通过反射（如 reflect.ValueOf(mypkg.Test)）调用的前提仍是 mypkg 已被导入并出现在当前作用域；
- ❌ Go 不支持运行时动态链接或插件式热加载（除非使用 plugin 包，但该包要求目标包以特殊方式编译为 .so，且仍需在主程序中 import "plugin" 并显式打开，不能跳过包声明）；
- ✅ 若希望减少主模块依赖，可考虑将逻辑抽象为接口，由已导入的包接收实现（如回调、选项函数），但这不改变“调用方仍需导入提供方包”的本质。
总结：Go 的 import 不是可选语法糖，而是强制性的依赖声明契约。任何试图绕过它的做法都会导致编译失败（undefined: mypkg）。遵循显式导入原则，不仅保障类型安全与构建可靠性，也使项目依赖关系清晰可溯——这是 Go 工程化实践的基石。
