Go go/format.Node 怎样把 AST 重新格式化成 Go 源码

如果你已经通过 go/parser 得到了一棵 Go AST，想把它重新写成可读源码，最直接的入口是 go/format.Node。它接收目标 io.Writer、同一套 token.FileSet 和 AST 节点，把节点按 gofmt 风格写出；函数不会修改传入节点。

官方资料：https://pkg.go.dev/go/format@go1.27.2#Node　https://go.dev/src/go/format/format.go

实用判断：要保留完整文件的导入整理和注释关系，就把 *ast.File 交给 format.Node；只格式化局部声明、语句或表达式时，要自己承担局部节点不排序导入的边界。

前置条件：FileSet、parser 和 AST 要对应

format.Node 依赖节点里的位置信息。解析时创建的 token.FileSet 应该和传入 format.Node 的 FileSet 是同一套，否则注释和位置相关信息可能无法按预期写出。先用标准库解析一份完整源文件：

package main

import (
    "bytes"
    "fmt"
    "go/format"
    "go/parser"
    "go/token"
)

func main() {
    src := []byte("package demo\n\nfunc add(a int,b int)int{return a+b}\n")
    fset := token.NewFileSet()

    // 解析注释，后面交给 format.Node 时才能继续携带文件注释。
    file, err := parser.ParseFile(fset, "demo.go", src, parser.ParseComments)
    if err != nil {
        // 语法不完整时先返回解析错误，不要把半成品 AST 继续格式化。
        panic(err)
    }

    var out bytes.Buffer
    // file 是完整的 *ast.File，Node 会按完整文件规则处理输出。
    if err := format.Node(&out, fset, file); err != nil {
        // Writer 或 AST 结构异常都要作为当前转换失败处理。
        panic(err)
    }
    fmt.Print(out.String())
}

这里的关键不是把字符串“美化”，而是让 parser.ParseFile、token.FileSet、*ast.File 和输出 Writer 形成一条完整关系。示例中的输入没有宣称为本机运行结果，读者可以把它当作最小结构实验。

调用 format.Node：完整文件和局部节点怎么选

Node 支持的节点范围不止 *ast.File，还包括 *printer.CommentedNode、声明切片、语句切片，以及可赋值给表达式、声明、规格或语句的节点。日常 AST 重写一般按下面的选择做：

如果只是把函数体中的一个表达式输出到日志，传表达式即可；如果准备覆盖原文件，建议始终围绕完整 *ast.File 组织，最后一次性写出。Node 不会修改节点，所以 AST 的增删改应发生在格式化前。

格式化失败时，先分清是哪一层出错

排查可以按三个层次进行：

1. 解析层：parser.ParseFile 失败，说明输入不是当前解析模式可接受的完整 Go 源码；先修输入，不要调用 Node。
2. AST 层：节点类型虽然能传入，但结构不完整或位置关系异常，Node 可能提前返回格式化错误。此时检查你改写的父子节点和 token.Pos 来源。
3. 输出层：Writer 写入失败时，结果可能只写了一部分。把它视为一次失败写入，不要直接覆盖原文件。

var out bytes.Buffer

// 先写入内存，避免格式化失败时破坏原始文件。
if err := format.Node(&out, fset, file); err != nil {
    // 保留原文件，记录错误上下文后交给上层处理。
    return fmt.Errorf("format AST: %w", err)
}

formatted := out.Bytes()
// 只有格式化成功，才把 formatted 交给后续的原子保存逻辑。

这个模式也解释了为什么不要把 format.Node 直接连到最终文件句柄：格式化是内存中的转换阶段，保存是另一个需要失败保护的阶段。

接入 AST 重写流程的最小闭环

一个可靠的转换器可以保持“解析—修改—格式化—保存”的顺序：

1. 用一个 FileSet 解析源文件，并保留注释选项。
2. 只修改 AST 中明确需要改变的节点，不在格式化阶段猜测业务语义。
3. 把完整 *ast.File 交给 format.Node 写入内存缓冲区。
4. 格式化成功后，再进入临时文件、重命名或版本控制差异检查。

还要注意一个容易忽略的事实：标准库格式规则会随 Go 版本变化。如果你的工具依赖输出字节级稳定，官方源码建议固定使用特定版本的 gofmt，不要把不同 Go 版本下的 go/format 结果当成永远一致。

常见问题

format.Node 和 format.Source 有什么区别？

Node 面向已经得到的 AST 节点；Source 面向一段语法正确的源码字节并返回格式化后的字节。已经做过 AST 改写时用 Node 更自然，只有源码文本时才考虑 Source。

局部声明格式化后为什么没有自动整理 import？

因为导入整理需要完整文件语境。官方文档明确区分了完整 *ast.File 与局部节点；局部声明或语句只负责自身的格式化，不承担完整文件的导入排序。

为什么不能把格式化错误忽略？

Node 可能在输出完成前提前返回错误，忽略错误会得到截断或不可用的源码。先保留原文件，记录错误，再回到 AST 结构和 Writer 状态排查。

小结：把同一套 FileSet 从解析传到 format.Node；完整文件优先传 *ast.File；局部节点要接受导入不整理的边界；格式化先写内存，成功后再保存。