Go ast.IsGenerated 为什么识别不到生成文件注释

ast.IsGenerated 识别不到生成文件注释，先看解析时是否启用了 parser.ParseComments，再看标记是否符合固定格式，并位于文件顶部的合法位置。它检测的是 AST 中保留的特殊注释，不能根据文件名、生成器执行记录或代码风格推断来源。

官方文档：https://pkg.go.dev/go/ast

生成代码约定：https://pkg.go.dev/cmd/go

先用保留注释的解析方式读取文件

最小可用方式是调用 parser.ParseFile 时把模式设为 parser.ParseComments，检查错误后再传给 ast.IsGenerated。默认模式并不保留用于该判断的注释列表，因此磁盘文件上明明有标记，内存 AST 却可能没有它。

已有 AST 时，重点是它当初怎样被解析。给后续函数加一个布尔开关，不能补回先前丢弃的注释。应重新从当前源码解析，或者让提供 AST 的上游明确保留注释。ast.File 的 File.Comments 才是识别所依赖的信息载体，IsGenerated 不负责重新打开原文件。

对照标准标记的格式与位置

规范标记是一行形如 // Code generated by samplegen; DO NOT EDIT. 的注释。固定前缀为 // Code generated ，固定后缀为 DO NOT EDIT.，中间是生成器说明。大小写、空格和末尾英文句点都属于这套格式，不能用中文句号或自行翻译的提示替代。

这行应放在文件首个非注释、非空白文本之前；对于普通合法 Go 源文件，直接把标准标记放在 package 声明之前即可。它可以与其他文件头注释共同存在，不必恰好是第一行，也不必成为与 package 紧邻的文档注释。把标记写在 package 后面，不符合该约定。推荐输出普通的独立行注释，避免使用看似相同的块注释包装。

只改变一个条件观察识别差异

下面给出可直接保存的 Go 程序。它保持问题边界集中，只改变解析模式、句点或标记位置；打印注释组数和识别布尔值，帮助读者把“未保留注释”与“标记不合约定”区分开。这是供读者执行的示例，不是已经采集的性能或运行报告。

package main

import (
    "fmt"
    "go/ast"
    "go/parser"
    "go/token"
    "log"
)

func main() {
    // 采用标准行注释标记，放在 package 之前。
    marker := "// Code generated by samplegen; DO NOT EDIT.\n"
    cases := []struct {
        label string
        src   string
        mode  parser.Mode
    }{
        {"保留注释", marker + "package demo\n", parser.ParseComments},
        {"未保留注释", marker + "package demo\n", 0},
        {"缺少句点", "// Code generated by samplegen; DO NOT EDIT\npackage demo\n", parser.ParseComments},
        {"标记放在包后", "package demo\n" + marker, parser.ParseComments},
    }
    for _, item := range cases {
        // 每项独立解析；解析错误不能被当作正常的 false。
        fs := token.NewFileSet()
        file, err := parser.ParseFile(fs, "demo.go", item.src, item.mode)
        if err != nil {
            log.Fatalf("%s：%v", item.label, err)
        }
        fmt.Printf("%s：注释组=%d，生成标记=%v\n",
            item.label, len(file.Comments), ast.IsGenerated(file))
    }
}

按接口约定，第一项具备识别条件；第二项没有保留注释；第三项缺失固定后缀的句点；第四项把标记放到了 package 之后。后三项均不应靠文件名或另一处生成指令补成 true。比较时先确认 err，再看注释是否存在，最后看标记文本与位置。

注释组数只用于辅助观察输入，数量大于零不代表其中必有生成标记。一段普通版权声明也会形成注释组。识别结果的依据是特殊注释，而不是所有注释的总数量；不要为了得到 true 把任意带“generated”的说明都当作标准标记。

把识别结果用于工具策略

在重写工具或静态分析工具里，可以根据这个布尔结果决定是否跳过自动修改，但需要明确它只是声明式标记。false 不保证源码一定手写，true 也不是来源认证或不可修改权限。标记可以被普通文本编辑改动，最终策略应由工具使用者决定。

只需要读取头部信息时，可结合官方示例使用 parser.PackageClauseOnly；若还需要遍历函数、声明或分析类型，则不要把只解析包子句的 AST 当成完整语法树。保留注释解决识别输入问题，解析范围解决后续处理需求，两者应分别选择。手工构造或经变换的 AST 还应注意注释列表与位置是否仍对应同一份源码。

常见问题与速查表

有 go:generate 指令就一定返回 true 吗？

不会。生成命令指令与输出文件的生成标记是不同约定。IsGenerated 不执行命令，也不根据命令存在与否判断。

标记必须放在第一行吗？

不必。规范要求它位于首个非注释、非空白文本之前。版权头可以在前面，建议仍保持标准行注释形式。

只检查 File.Doc 可以替代 IsGenerated 吗？

不宜。生成标记不必正好被关联为包文档，手工只检查 Doc 容易漏掉文件头中的其他注释组。