Dot Import 应禁用，因其引发命名冲突、破坏可维护性；仅极少数本地测试场景可谨慎使用，推荐用语义化短别名替代。
Dot Import 会导致命名冲突，绝大多数情况不该用
Go 的 . 导入（即 import . "path/to/pkg"）会把目标包的导出标识符直接“平铺”进当前命名空间，看似省事，实则破坏了 Go 强调的显式性和可维护性。它不是语法糖，而是隐患开关。
常见错误现象：./main.go:5:2: Foo redeclared in this block —— 两个 dot-import 的包都导出了同名函数 Foo，编译直接失败；或者更隐蔽地，本地变量名意外覆盖了导入的函数名，运行时行为异常。
- 仅在极少数 REPL 式调试或临时脚本中可容忍（比如
go run单文件快速验证），生产代码、测试文件、模块接口层一律禁用 - 无法通过
go list -f '{{.Imports}}' .等工具清晰追踪依赖来源，IDE 跳转和重命名支持变弱 - 如果包后续新增导出名，可能悄无声息地破坏你的代码（例如加了个
Log函数，撞上了你已有的log变量）
替代方案：用短别名代替 dot import
真正需要“少打字”的场景，应该用显式别名，既保可读又控冲突。Go 官方工具链（gofmt、goimports）默认支持且鼓励这种写法。
使用场景：频繁调用某个包的多个函数（如 testify/assert、github.com/google/uuid），又不想每次写长包路径。
立即学习“go语言免费学习笔记（深入）”；
- 用
assert替代.：写import assert "github.com/stretchr/testify/assert"，然后调用assert.Equal(t, 1, x) - 别名要小写、语义清晰，避免用
u、h这类无意义缩写；uuid比u好，httpmock比m好 - 标准库包不建议别名（如
fmt、io），因为已是共识；第三方包别名后，务必在go.mod中锁定版本，防止别人拉取时行为漂移
为什么 go vet 和 golangci-lint 默认报 dot import 警告
go vet 把 . 导入列为可疑实践，golangci-lint 的 revive 和 stylecheck 规则也默认禁用它——这不是风格偏好，而是基于大规模工程经验的稳定性判断。
性能影响虽小（编译期解析开销几乎可忽略），但兼容性风险明确：Go 1.21+ 对 init() 执行顺序做了更严格定义，dot-import 包若含 init，其执行时机更难预测；跨 module 导入时，若两个 module 都 dot-import 同一依赖的不同版本，构建可能静默失败。
- CI 流水线中一旦开启
golangci-lint --enable-all，import . "xxx"会直接导致检查失败 - 某些静态分析工具（如
staticcheck）无法准确推导 dot-import 标识符的类型来源，导致误报或漏报 - 团队协作时，新人看到
Foo()不知道来自哪个包，查文档或跳转成本翻倍
唯一勉强能考虑 dot import 的边界场景
只有一种情况可以睁一只眼：在 _test.go 文件中，为简化测试辅助函数组织，且该包**完全不导出任何符号**、**仅用于当前测试文件内部**（即没有 exported 函数/类型）、**不被其他包 import**。
例如：一个 jsonutil_test.go 里写了个私有 mustMarshal 工具函数，然后 import . "./jsonutil_test" 来复用——但这其实更该用 func mustMarshal(...) 直接定义在测试文件顶部。
- 即便如此，也要在该文件顶部加注释说明：“This dot import is local-only and safe because…”
- 只要包路径里带
/vendor/、/internal/或涉及跨 module，立刻放弃 - 如果测试文件超过 200 行，或开始出现多个 dot-import，说明结构已失控，应重构为独立 helper 包 + 显式导入
