用 go/ast 解析单个 .go 文件仅能获取该文件顶层 import 路径字面量，需手动遍历 ast.file.imports 并用 strconv.unquote 提取带引号的路径字符串，无法识别条件编译、模块依赖或类型信息；要获取真实构建依赖，须改用 golang.org/x/tools/go/packages。
直接用 go/ast 解析单个 .go 文件，只能拿到该文件顶层的 import 语句字面量，无法自动展开依赖树或识别条件编译（如 //go:build）是否启用某个导入——它不解析模块、不读 go.mod、也不做类型检查。
用 go/ast 提取当前文件的 import 路径列表
这是最轻量、最可控的方式，适用于扫描源码结构、生成文档或做静态 lint。关键点是：必须手动遍历 *ast.File.Imports，并处理引号包裹的路径字符串。
-
Imports是一个[]*ast.ImportSpec切片，每个元素对应一行import语句 - 路径在
ImportSpec.Path的Value字段里，是带双引号的字符串（如"fmt"），需用strconv.Unquote去掉引号 - 别名（
ImportSpec.Name）和点操作（.）、下划线（_）导入都存在，但路径本身不变 - 忽略
ImportSpec.Doc和Comment——它们只是注释，不影响实际导入
file, err := parser.ParseFile(fset, "main.go", src, parser.ImportsOnly)
if err != nil {
log.Fatal(err)
}
for _, imp := range file.Imports {
path, _ := strconv.Unquote(imp.Path.Value) // 如 "net/http"
fmt.Println(path)
}
为什么不能只靠 go/ast 得到“完整依赖”
go/ast 是纯语法层工具，它不理解 Go 的构建模型。以下情况它完全无感：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 同一个包被多个文件 import，它不会去重或合并
-
import _ "net/http/pprof"和import "net/http"在 AST 里都是独立节点，但语义不同（后者引入符号，前者只触发init） - 条件编译指令（
//go:build !windows）可能导致某行import实际不生效，AST 不做判断 - 没有
go.mod时，import "github.com/foo/bar"是否存在、版本为何，AST 一概不知
要获取真实可构建的依赖列表，得换标准库组合
如果目标是“这个包编译时实际会拉哪些依赖”，就不能停留在单文件 AST。必须切换到模块感知层面：
- 用
go/build（旧模块模式）或golang.org/x/tools/go/packages（推荐，支持 modules）加载包，它会自动解析go.mod、处理构建约束、过滤测试文件 -
packages.Load返回的*packages.Package中，PkgPath是模块路径，Imports是直接依赖的包路径 map（key 是导入路径，value 是 *Package 指针） - 递归遍历
Imports可得完整依赖图，但注意循环引用和重复节点需手动去重 - 避免用
go list -f '{{.Deps}}'这类 shell 方式——它依赖外部命令，不可嵌入程序，且输出格式不稳定
容易被忽略的细节
真正写代码时，最容易卡在路径合法性与上下文缺失上：
- 传给
parser.ParseFile的src必须是原始字节（[]byte），不是文件路径字符串；否则可能 panic 或读错编码 - 用
packages.Load时，必须设Config.Mode = packages.NeedName | packages.NeedFiles | packages.NeedImports，缺任意一项都会让Imports为空 -
import "./local"这种相对路径在 AST 里能拿到，但在模块模式下几乎无效——它只在go build的 legacy GOPATH 模式下被允许 - 标准库包（如
"fmt"）的PkgPath是"fmt"，而第三方包（如"github.com/sirupsen/logrus"）的PkgPath就是完整模块路径，二者格式一致，可统一处理
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
