包名冲突时必须用导入别名，Go编译器只认package声明的标识符；别名紧贴import、不可省略，如import u "path"；\_用于仅执行init()；路径解析失败常被误认为别名问题。
包名冲突时必须用导入别名，不能靠文件名或路径“猜”
Go 编译器只认 import 语句末尾的包名（即 package 声明的那个标识符），不看路径、不看文件夹名。两个包都声明 package utils，哪怕路径完全不同，也会报错 ./main.go:5:2: import "xxx/utils" is a program, not an importable package 或更常见的 multiple packages named utils。
解决方式只有一种：显式加别名。别名不是可选项，是冲突下的强制语法要求。
- 别名写在双引号前，紧贴
import，例如：import u "github.com/xxx/utils" - 别名不能是 Go 关键字（如
type、func），也不能是已声明的变量名 - 如果只是想避免重名但不改调用前缀，用
.别名（import . "xxx/utils"）——但会污染当前命名空间，容易引发隐式覆盖，不推荐 - 别名作用域仅限当前文件，不影响其他文件对同一包的引用方式
第三方包和本地包同名时，别名要兼顾可读性和一致性
常见场景：你自己写了 utils 目录，又用了 github.com/gorilla/utils。两者都习惯叫 utils，但 Go 不允许。
这时候别名不是随便起个字母就行，得让人一眼看出来源：
立即学习“go语言免费学习笔记（深入）”；
- 优先用缩写表意，比如
gorilla "github.com/gorilla/utils"、local "myproject/utils" - 避免用
u、ut这类无上下文缩写，尤其当文件里同时出现多个u.X()调用时，根本分不清来自哪边 - 团队项目中，建议在 README 或 internal/docs/import-rules.md 里统一约定别名规则（例如所有外部工具包用作者名前缀）
- 别名不影响构建性能，但会影响 IDE 的跳转准确率——某些老版本 GoLand 在别名过短时无法正确解析符号
用 _ 导入别名触发 init 函数但不暴露包内容
有些包（比如数据库驱动）只提供 init() 注册逻辑，不需要调用任何函数。这时你既不能省略导入（否则 init 不执行），又不想引入命名冲突风险。
_ 是唯一合法且明确的“仅执行 init”的导入方式：
- 写法固定为：
import _ "github.com/go-sql-driver/mysql" - 不能跟其他别名混用，
_ "xxx"是完整语法，中间不能有空格 - 如果误写成
import _ "xxx"; xxx.Do()，会报错undefined: xxx—— 因为_表示彻底丢弃包名绑定 - 这种导入在
go list -f '{{.Imports}}' .中仍会显示，说明它参与依赖分析，只是不进入当前作用域
嵌套模块下多级路径导致的“伪冲突”，其实是 GOPATH 或 Go Module 配置问题
有时候你以为是包名冲突，实际是 Go 工具链没找对包。典型现象：明明改了别名，还是报 cannot load xxx: cannot find module providing package xxx。
这往往不是别名的问题，而是模块路径解析失败：
- 检查
go.mod是否包含对应模块的require行，没有就运行go get github.com/xxx/pkg - 确认
GO111MODULE环境变量没被设为off（尤其在旧项目里） - 如果本地包路径含空格或中文，某些 Windows 版本的
go build会静默失败，错误信息却指向别名冲突 - 用
go list -m all看实际加载的模块版本，有时缓存了旧版，而新版已改包名——此时别名再合理也救不了
别名解决的是编译期符号冲突，不是路径发现失败。这两类问题经常被当成一回事，但修复路径比改别名重要得多。
