Go uuid 为什么导入路径找不到（参数形态）

Go 导入 uuid 找不到，先看完整导入字符串。import "uuid" 指向 Go 1.27 新增的标准库，需要实际参与构建的工具链支持它；import "github.com/google/uuid" 指向独立的第三方模块，需要在当前项目中声明依赖。两者虽然默认包名都叫 uuid，但不能靠修改函数参数、添加 https 前缀或执行同一条下载命令互相替代。

标准库官方文档：https://pkg.go.dev/uuid

第三方项目官方地址：https://github.com/google/uuid

先确定项目需要哪一种 uuid

生产项目要固定的目标是“同一份源码在开发机和 CI 解析到同一个包”。Go 1.27 发布说明明确列出了新 uuid 包，因此不能再笼统地说 Go 没有内置 UUID；但较早版本工具链也不会因为你看到了新文档而自动拥有这个包。

先从原项目的 import 和 API 用法判断意图。只想修复导入时，不要顺手替换 UUID 实现；第三方类型与标准库类型属于不同包，包别名相同也不会让类型相同。现有接口若公开了第三方 UUID 类型，更换路径应当作为一次独立迁移处理。

读取实际工具链与模块环境

请在报错项目所在目录运行下面的诊断命令。它们是供读者使用的排障示例，本文没有执行这些命令，也不提供虚构的运行结果。

# 查看当前项目实际选用的工具链版本
go version
# 查看模块、工作区、工具链选择和构建参数
go env GOMOD GOWORK GOTOOLCHAIN GOFLAGS
# 判断标准库路径能否被当前环境解析
go list uuid

go version 显示当前选中的工具链版本。GOTOOLCHAIN、go.mod 和 go.work 都可能参与工具链选择；编辑器使用的环境也可能与命令行不同。若报错发生在 CI，就应读取 CI 同一构建步骤里的版本，而非引用开发机的版本。

标准库路线遇到旧工具链时，可以把构建环境升级到支持该包的版本，并让项目的最低版本声明与实际需求一致。不要只在旧环境里把 go.mod 数字改大后假定升级完成；禁用了自动切换时，工具链可能直接拒绝加载要求更新版本的项目。

第三方路线中，GOMOD 应指向目标项目的 go.mod。Unix 上显示 /dev/null 通常说明当前处于模块模式但没有主模块文件；先进入正确目录。只有确实在建立一个新项目时才执行 go mod init，不要在既有仓库子目录随意增加第二个模块。

把 import、版本参数和模块配置分开放

标题中的“参数形态”落实到这里，就是不要混淆源码导入参数与 go 命令的版本查询参数。import 使用包路径，不带协议，也不带 @版本；下载第三方模块时，版本查询写在命令参数后面。

v1.6.0 是这里明确选定的示例版本，不代表最新版本推荐。已有项目应保留团队批准的版本约束，结合仓库策略决定升级，而不是默认运行全依赖更新。

# 仅在选择第三方实现时，于目标模块目录添加示例版本
go get github.com/google/uuid@v1.6.0
# 在源码 import 已正确的前提下整理模块依赖
go mod tidy

若选择标准库路线，下面是一个独立的 Go 1.27 及以后版本示例。它展示路径、包别名与调用入口的关系，不与第三方示例放进同一个 main 文件。

package main

import (
    "fmt"
    stduuid "uuid" // 标准库路径，工具链需支持该包
)

func main() {
    // 生成标识并转为文本；别名只影响当前文件的引用名称
    requestID := stduuid.New()
    fmt.Println(requestID.String())
}

若项目明确选择 google/uuid，则使用下面这个独立示例。第三方模块的官方 go.mod 声明了 github.com/google/uuid，import 中不要添加 https:// 或 @v1.6.0。

package main

import (
    "fmt"
    googleuuid "github.com/google/uuid" // 第三方模块的完整导入路径
)

func main() {
    // 继续使用原实现，避免把导入修复变成类型迁移
    requestID := googleuuid.New()
    fmt.Println(requestID.String())
}

这里的 New 都是不带实参的调用。是否能调用某个函数，应看当前完整路径对应的 API 文档；函数名看起来相似不能证明两个包的全部能力、签名与行为都一致。

为依赖下载保留必要的访问边界

标准库 uuid 的可用性由工具链决定，不需要添加 github.com/google/uuid 依赖来“补齐”。第三方路径确认正确后，才继续处理模块下载。企业网络可以使用组织批准的模块代理，但代理配置不能修复拼错的路径，也不能给旧工具链安装一个新的标准库包。

# 仅查看下载相关配置，不修改机器级环境
go env GOPROXY GOSUMDB GOPRIVATE GONOPROXY GONOSUMDB
# 查看当前项目选中的第三方模块版本
go list -m github.com/google/uuid

对公开模块，不要为了消除一次报错就全局关闭 GOSUMDB，也不要把所有公共仓库都划入私有模块匹配范围。Go 会根据配置使用 go.sum 与校验数据库维护下载一致性；关闭相关机制不会解决 import 路径本身不合法的问题。共享日志前，只保留排障所需的公开包路径和配置含义，代理地址里的凭据及内部域名应脱敏。

让日志能区分路径错误与下载失败

排障记录至少保留完整错误行、完整包路径、实际 Go 版本与当前主模块位置。不同 Go 版本的错误措辞可能不同，下表按含义分类，不能把某条示例短语当作唯一匹配规则。

若日志中的完整路径根本不是正文两种形式之一，先回到对应项目的一方文档确认路径。不要因为包名也叫 uuid，就把任意第三方库替换成 google/uuid。

把修复落实到 CI 与交付配置

标准库路线应让本地、CI 和构建镜像采用支持 uuid 的工具链，并把最低版本要求纳入项目配置。第三方路线应提交实际使用的 go.mod、go.sum；采用 vendor 的仓库还应按现有策略更新 vendor。只在某台开发机的模块缓存里下载成功，不等于其他环境会得到同样的依赖声明。

交付记录可以简短写成三项：选定的完整导入路径、实际构建工具链、相关配置文件的变更。团队应在自己的交付流水线中确认项目能解析和构建；这里没有声称本文示例已通过运行。

已经 go get 了，为什么编辑器仍然找不到？

看编辑器打开的模块根目录和使用的 Go SDK 是否一致。依赖加在另一个模块里，或编辑器仍用旧工具链，都可能让命令行和编辑器表现不同。先修正环境归属，再刷新语言服务。

把 import 改成 uuid 就能去掉第三方依赖吗？

不能直接作这个推断。标准库路径需要相应工具链，类型和 API 也需要迁移；依赖关系中还可能有其他包继续引用第三方实现。导入修复优先保留原项目实现。

go.mod 写了新版本，机器就一定使用它吗？

版本声明与工具链选择有关，但仍取决于 GOTOOLCHAIN、工作区以及本机可用工具链。以报错步骤里的 go version 为准，避免根据配置文件的一个数字推断实际环境。

资料：Go 1.27 发布说明、标准库 uuid 文档、google/uuid 官方仓库、Go Modules 参考、Go 工具链选择规则。