go反射无法读取结构体字段注释，因注释不参与编译；需用go/parser+go/ast解析源码获取，属构建期工具行为，非运行时反射能力。
Go 反射无法直接读取结构体字段的注释
反射（reflect）在运行时只能看到编译后的类型信息，而 Go 源码中的注释（包括 // 或 /* */）不会被保留到二进制中。所以无论你怎么调用 reflect.TypeOf 或 reflect.ValueOf，都拿不到字段上方那行 // 用户名 这类注释。
常见错误现象：写了一堆 field.Tag.Get("json") 以为也能 field.Tag.Get("comment")，结果返回空字符串——因为注释压根没进 tag，更不在反射对象里。
- 注释不是语言特性的一部分，只是源码文本，编译器会丢弃它
-
struct字段的reflect.StructField里没有注释字段 - 想靠
runtime/debug.ReadBuildInfo()或go:embed加载源码再解析？那已不属于“反射”范畴，而是源码分析
要提取注释得用 go/parser + go/ast 解析源文件
真正可行的路径是把 .go 文件当文本读进来，用官方 go/parser 构建 AST，再遍历节点找结构体定义和紧邻其上的 comment group。这不是运行时能力，而是构建期或开发期工具行为。
使用场景：生成文档、校验字段说明完整性、自动生成 API 描述、IDE 插件提示等。
- 必须指定准确的文件路径，比如
"./user.go"，不能只传包名 - 需注意 GOPATH / Go Modules 下的相对路径解析逻辑，推荐用
filepath.Abs标准化 -
ast.CommentGroup是注释容器，要通过ast.Node.Pos()和字段位置比对来判断是否“属于该字段” - 字段声明前的注释才有效；如果注释在字段后、或跨行空行隔开，就可能匹配失败
简短示例：定位 User.Name 字段的前导注释
file, err := parser.ParseFile(fset, "user.go", src, parser.ParseComments)
if err != nil {
log.Fatal(err)
}
// 遍历 file.Decls 找 *ast.TypeSpec，再找 *ast.StructType...
// 然后对每个 *ast.Field，检查 f.Doc.List[0].Text别硬塞注释进 struct tag，tag 不是注释搬运工
有人试图用 //go:generate 脚本把注释内容自动写进 tag，比如把 // 用户名 变成 `json:"name" comment:"用户名"`。这看似绕过了限制，但实际埋了坑。
性能 / 兼容性影响：tag 值变大，反射读取开销略增（可忽略），但主要问题是维护成本和一致性风险。
- 一旦源码注释改了，tag 不同步就立刻失真
- 生成脚本难覆盖所有 case：多行注释、空行、字段分组（如
Age, Height int共享一个注释） - 第三方库（如
mapstructure,encoding/json）不认commenttag，纯属自定义，别人看不懂 - gofmt 会重排 tag 顺序，可能导致生成逻辑错乱
gomodifytags 或 gopls 是更稳的替代方案
如果你的目标是“在编辑器里看到字段注释”，其实不用自己写 AST 分析器。VS Code 的 Go 插件默认依赖 gopls，它内部就做了完整的源码索引，能实时响应光标所在字段并展示上方注释。命令行下也可以用 gomodifytags 提取和操作 tag，配合 -format 参数还能输出带注释的结构体摘要。
容易被忽略的地方：这些工具依赖 go list -json 获取包信息，所以当前目录必须是 module 根或含 go.mod；否则 gopls 会 fallback 到 GOPATH 模式，可能找不到你正在看的文件。
验证方式：在 VS Code 里把光标停在字段名上，等几秒看悬浮提示是否包含注释内容——如果没出现，先检查状态栏右下角的 gopls 是否就绪，再确认文件是否被正确纳入 workspace。
