包名冲突时必须用点号前缀重命名
go 不允许两个同名包直接导入，哪怕路径不同也会报 import "xxx" is a program, not an importable package 或更常见的 multiple packages named xxx。这时候不能删包、不能改源码，唯一解法是显式重命名——而且必须加点号（.）或自定义别名，否则编译器不认。
常见场景：你同时用 github.com/golang/freetype 和 golang.org/x/image/font，两者都导出了 Font 类型；或者本地 models 包和第三方 github.com/xxx/models 冲突。
- 重命名语法固定：
alias "path/to/pkg"，比如ft "github.com/golang/freetype" - 如果想让被导入包的导出名“裸奔”进当前作用域（类似 Python 的
from x import *），必须用.：.“github.com/xxx/utils” —— 但极其危险，容易覆盖已有变量或函数 - 别名不能是 Go 关键字（
type、func等），也不能是已声明的标识符
重命名后调用方式要同步改
别名不是符号链接，只是编译期的引用标签。一旦用了 ft "github.com/golang/freetype"，所有原本写 freetype.ParseFont(...) 的地方，必须改成 ft.ParseFont(...)；否则编译报错 undefined: freetype。
容易踩的坑是：只改了 import 行，忘了改后续所有调用点。尤其在重构旧项目时，ide 自动重命名不一定覆盖跨文件引用，得靠 grep -r "freetype." ./ 扫一遍。
立即学习“go语言免费学习笔记（深入）”；
- 别名区分大小写：
FT和ft是两个不同别名 - 同一个包在不同文件里可以起不同别名，但同一文件内不能重复定义别名
- 如果别名和本地变量同名（比如
log "log"+var log *Log），会触发log redeclared as imported package name
go mod tidy 不会自动处理重命名
go mod tidy 只管依赖树和 go.sum，完全不管 import 行里的别名。它不会帮你把 "github.com/xxx/v2" 改成 v2 "github.com/xxx/v2"，也不会警告你别名是否冲突。
这意味着：手动改别名后，必须自己验证所有引用是否连通。运行 go build 是最简单的检验方式；若想提前发现，可用 go list -f '{{.Imports}}' your/package 查看实际解析的导入路径和别名绑定关系。
- 别名不影响模块版本解析，
v2 "github.com/xxx/v2"和xxx "github.com/xxx/v2"拉的还是同一个 commit - VS Code 的 Go 插件有时会误标别名后的调用为 “undefined”，重启 gopls 或清缓存（
gopls restart）可解决 - CI 流程中如果用了
go vet或静态检查工具，它们对别名的支持程度不一，建议在本地先跑通
慎用 . 别名：它绕过作用域隔离
用 . 导入相当于把整个包的公开符号平铺到当前文件顶层作用域。表面上省事，实则埋雷：一旦包升级新增了和你本地变量同名的导出项（比如包新加了个 Config，而你代码里已有 var Config = ...），立刻编译失败，且错误提示极不直观。
真实案例：某团队用 . 导入 github.com/spf13/cobra，后来 cobra 加了 Version 常量，撞上了他们已有的 var Version = "1.2.0"，构建卡住两小时才定位到。
-
.只应在极小的 CLI 工具脚本里临时用，生产代码禁止出现 - IDE 对
.的跳转和补全支持差，鼠标悬停看不到来源包 - 代码审查时看到
.就该打回去，除非有不可抗力（比如生成代码硬编码了该写法）
事情说清了就结束。真正麻烦的不是怎么写别名，而是当多个间接依赖各自引入了同名包（比如都依赖 golang.org/x/net 但版本不同），这时得靠 replace + 重命名组合拳，那又是另一层水深。