旧项目迁移后 import 报 multiple packages named xxx，是因为 go 编译器仅依据 package 声明名（而非路径）识别包；启用 go.mod 后，若多个目录声明同名 package（如均含 package utils），则构建时硬性报错。
为什么旧项目迁移后 import 会报 multiple packages named xxx
因为 Go 编译器只认 package 声明的名称，不看路径。旧系统若没启用模块（go.mod），所有包都默认在隐式 main 模块下；一旦你加了 go mod init，而目录结构里又存在同名包（比如两个 utils 目录都写了 package utils），Go 就直接报错：multiple packages named utils。
这不是路径没写对，也不是 IDE 显示异常，是编译期硬性拦截——只要同名 package 出现在同一构建上下文，就炸。
- 别指望删掉一个
utils目录来“解决”，可能其他代码正依赖它 - 也别改
package utils为package myutils，那等于重命名整个包，所有调用点都要同步改，风险高、易漏 - 最稳妥的解法：保留原包名，靠
import别名隔离作用域
旧包和新模块路径混用时怎么写 import 别名才不出错
常见场景：旧代码用相对路径或 GOPATH 风格导入，比如 import "utils"；新模块启用了 go.mod，路径变成 github.com/yourorg/project/internal/utils。两者共存就会触发冲突。
正确做法是统一用完整模块路径 + 显式别名：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 别名必须紧贴双引号，不能有空格：
import localutils "github.com/yourorg/project/internal/utils"✅ - 禁止写成
import localutils" github.com/.../utils"❌（空格导致语法错误） - 别名不能是 Go 关键字（如
type、func），也不能和当前文件已声明的变量同名 - 如果本地包和第三方包都叫
log，建议用来源缩写：stdlog "log"、zerolog "github.com/rs/zerolog"
重构中如何批量更新别名调用，避免漏改
别名一改，所有用到该包的地方都得同步换前缀，比如从 utils.Do() 改成 localutils.Do()。手动搜替换容易漏，尤其跨文件调用。
- 用
grep -r "utils\." ./ --include="*.go"扫描所有以utils.开头的调用（注意转义点号） - IDE 的重命名功能不一定覆盖跨文件引用，尤其当别名和变量名相同（如
utils := getUtils()）时，会误判 - 重点检查测试文件（
*_test.go）、命令入口（cmd/下）、以及接口实现文件，这些地方最容易漏 - 改完后跑一次
go build ./...，编译失败的位置就是漏改点
vendor 目录和 go.mod 共存时的命名冲突陷阱
旧系统可能自带 vendor/，而你又启用了 Go Modules，这时 Go 会优先读 vendor/ 里的代码，但 go.mod 里声明的模块路径可能和 vendor 中的实际路径不一致，导致同一个包被解析出两个不同路径，最终还是落到同名 package 冲突上。
- 要么彻底禁用 vendor：
go env -w GO111MODULE=on，然后删掉vendor/，再跑go mod tidy - 要么保留 vendor，但必须确保
go mod vendor生成的内容与go.mod完全匹配，且所有import路径严格对应vendor内的目录结构 - 特别注意：
vendor下的包如果没带go.mod文件，Go 会把它当作 legacy 包处理，可能忽略其内部module声明，造成路径解析错乱
真正的麻烦不在语法层面，而在路径解析和构建缓存的耦合上——有时候 go clean -cache 比改代码还管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
