Go go/printer.Config.Fprint 怎样保留自定义格式化缩进规则

批量生成 Go 源码时，真正容易失控的不是 AST 节点，而是“谁决定输出格式”。直接调用 printer.Fprint 可以快速得到源码，却很难在多个生成器之间统一缩进和制表位。把 printer.Config 与 Config.Fprint 固定在生成层，就能明确控制 Mode、Tabwidth 和 Indent；如果目标是完全贴合 gofmt，则应把最后的格式化交给 go/format。

记住三点：Indent 负责整体左移，Tabwidth 影响制表位显示，Mode 决定使用制表符、空格或原始输出；配置应集中在生成层，而不是散落在每个调用点。

• 输入关系：Fprint 读取 AST 节点和 token.FileSet 的位置信息，再写入 io.Writer。
• 格式关系：TabIndent 与 UseSpaces 解决缩进和对齐策略，RawFormat 会绕过 tabwriter。
• 工程关系：自定义排版与 gofmt 兼容不是同一目标，生成器要先选定交付标准。

从一次输出到批量生成，先拆开格式责任

小工具里调用一次 printer.Fprint 通常没有问题，但代码生成服务一旦同时处理接口、模型和测试模板，输出策略就会被不同的调用者悄悄改变：有人依赖默认八列制表位，有人把片段再包进额外缩进，还有人把“看起来像 gofmt”当成真正的 gofmt 结果。规模扩大后，差异会出现在提交对比、缓存键和生成文件的稳定性上。

因此可以把职责分成三层：AST 构造层只关心节点，位置层由 token.FileSet 管理，输出层只接受一个明确的 printer.Config。下面的示例保留这条边界，配置只在打印入口出现。

package main

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

func main() {
    // 示例源码只作为 AST 输入，不把格式策略写进节点构造过程。
    src := `package demo
func Add(a, b int) int { return a + b }`
    fset := token.NewFileSet()
    file, err := parser.ParseFile(fset, "demo.go", src, parser.ParseComments)
    if err != nil {
        panic(err)
    }

    var out bytes.Buffer
    cfg := printer.Config{
        // 使用显式配置，避免不同调用点依赖默认值。
        Mode: printer.UseSpaces,
        Tabwidth: 4,
        Indent: 1,
    }
    if err := cfg.Fprint(&out, fset, file); err != nil {
        panic(err)
    }
    fmt.Print(out.String())
}

Config 的三个旋钮如何共同决定缩进

Config.Fprint 的参数顺序很重要：输出目标是 io.Writer，位置解释依赖 fset，最后才是要打印的 AST 节点。节点可以是文件、注释节点、声明、语句或表达式；如果只传一个节点，却复用了错误的文件集，源码位置相关行为就会失去上下文。

Indent 表示所有代码至少额外左移多少级；Tabwidth 是制表位宽度，影响制表符和对齐的计算；Mode 则是一组位标志。TabIndent 强制缩进使用制表符，UseSpaces 让对齐使用空格，RawFormat 不使用 tabwriter 且会忽略 UseSpaces，SourcePos 用于输出保持源位置的 //line 指令。不要把它们当成“空格数量”三个独立开关，而要把它们看成一份输出政策。

如果团队要求四列制表位，先确认下游是否真正关心制表位，而不是只关心最终视觉宽度。工具链中混用 TabIndent 和 UseSpaces，往往会让生成结果在编辑器、差异查看器和后续格式化阶段表现不同。

把配置固定在生成层，避免调用点漂移

更稳妥的做法是让每类生成任务拥有一个打印入口，并把 AST 构造与格式策略隔离。这样调用者只能选择“生成哪类文件”，不能临时改变同一类文件的缩进规则。

func printGenerated(fset *token.FileSet, file *ast.File) (string, error) {
    var buf bytes.Buffer
    // 生成层统一输出策略，调用者不再重复拼装 Config。
    cfg := printer.Config{Mode: printer.TabIndent, Tabwidth: 8, Indent: 0}
    if err := cfg.Fprint(&buf, fset, file); err != nil {
        return "", err
    }
    return buf.String(), nil
}

func printLikeGofmt(fset *token.FileSet, file *ast.File) (string, error) {
    var buf bytes.Buffer
    // 需要贴合 gofmt 时，使用 go/format，而不是猜 printer 参数。
    if err := format.Node(&buf, fset, file); err != nil {
        return "", err
    }
    return buf.String(), nil
}

这两个函数的边界很清楚：前者适合需要自定义输出政策的源码生成器，后者适合把结果交付给遵循 gofmt 的仓库。它们都返回字符串并保留错误，不让上层把格式错误误判成 AST 构造错误。

上线后看什么，什么时候换 go/format

在批量生成场景里，先观察三个信号：同一输入重复生成时差异是否稳定、生成文件是否频繁出现无意义的空白变更、下游是否要求直接通过 gofmt 相关门禁。前两个信号偏向于集中 Config，最后一个信号则说明自定义策略可能已经超出需求。

不要为了“更好看”同时打开互相冲突的模式。若需要原始排版，明确记录 RawFormat 的理由；若需要保留源位置，单独评估 SourcePos 带来的 //line 指令影响。格式政策一旦进入生成器的公共接口，就应当随版本记录，而不是让每个模板作者自行决定。

常见疑问

为什么设置了 UseSpaces，结果仍然看到制表符？

先检查是否同时设置了 RawFormat 或 TabIndent。前者会忽略 UseSpaces，后者会让缩进独立使用制表符；另外还要区分“缩进”与“对齐”，两者并非同一个输出位置。

Config.Fprint 能不能替代 gofmt？

不能把两者当成完全等价。Config.Fprint 提供可控的打印政策，go/format.Node 才是更直接的 gofmt 风格入口。若仓库的验收标准就是 gofmt，应在生成层明确采用后者。