Go go:generate 怎样固定代码生成工作目录

如果同一条 go generate 指令在不同目录启动后表现不一样，先不要给生成器随意加全局路径。Go 的规则其实很明确：每条 //go:generate 指令都在所属包的源码目录执行，和你从仓库根目录还是子目录发起命令无关。要固定行为，应让指令使用包相对路径，并把仓库级目录作为显式参数传给生成器。

本文只讨论生成指令的执行目录和可复现参数，不把“生成成功”扩大解释为代码已经编译或发布。官方地址：https://go.dev/src/cmd/go/internal/generate/generate.go

记住一句话：go generate 固定的是“指令所属包目录”，不是“调用者当前目录”；需要仓库根目录时，自己把它写成参数。

先确认 go generate 的固定边界

go generate ./... 可以从仓库根目录触发多个包，但每个包里的生成器仍以自己的源码目录作为工作目录。Go 源码实现把命令的 Dir 设为指令文件所在目录，因此 ./config.yaml 代表的是当前包里的文件，而不是启动命令的目录。

// 该指令位于 internal/schema/schema.go，路径从 internal/schema 解释。
//go:generate go run ../../tools/gen -out generated.go

package schema

例如目录为 repo/internal/schema 时，上面的 ../../tools/gen 指向 repo/tools/gen，generated.go 则落在 repo/internal/schema。从仓库根目录执行或从模块外执行，只要目标包相同，这两个相对关系就不变。

包内路径和仓库级路径要分开处理

最稳定的约定是：生成结果属于哪个包，就把输出文件写成包内相对路径；生成工具属于仓库，就从包目录写出到工具目录。这样生成器不需要猜测用户的启动位置。

// 输出属于 schema 包，工具位于仓库根目录的 tools/gen。
//go:generate go run ../../tools/gen -out generated.go -format schema

package schema

不要把 go generate 的启动目录硬编码成生成器的工作目录，也不要默认 os.Getwd() 就是仓库根目录。os.Getwd() 在生成器里拿到的是包目录；这不是错误，反而是 Go 为每个包提供的稳定边界。

需要仓库根目录时，显式传入 -root

当模板、版本文件或多个包共享的输入位于仓库根目录，建议让生成器接受 -root，而不是读取启动 shell 的目录。下面的写法仍然基于包目录，但把“仓库根在哪里”变成了可读、可记录的参数。

// 生成器从 internal/schema 出发，显式把仓库根目录传为 ../..。
//go:generate go run ../../tools/gen -root ../.. -input api/schema.yaml -out generated.go

package schema

package main

import (
    "flag"
    "fmt"
    "os"
    "path/filepath"
)

func main() {
    // root 是相对包目录解析的，避免依赖调用者的 shell 目录。
    root := flag.String("root", ".", "仓库根目录")
    input := flag.String("input", "", "相对仓库根目录的输入文件")
    output := flag.String("out", "generated.go", "相对当前包目录的输出文件")
    flag.Parse()

    rootAbs, err := filepath.Abs(*root)
    if err != nil {
        fmt.Fprintln(os.Stderr, "解析仓库根目录失败:", err)
        os.Exit(1)
    }
    inputPath := filepath.Join(rootAbs, filepath.FromSlash(*input))
    // 输出仍按当前工作目录解释，保持生成文件属于当前包。
    outputPath := filepath.Clean(*output)
    fmt.Println("读取:", inputPath)
    fmt.Println("写入:", outputPath)
}

这个小程序只展示路径边界和错误处理，未在本文制作过程中执行。真正的生成器还应读取输入、写入临时文件并按项目约定替换目标；路径策略本身不依赖这些业务细节。

可复现生成还要记录哪些上下文

Go 会为生成器设置 GOFILE、GOLINE、GOPACKAGE、GOOS、GOARCH、GOROOT 和 DOLLAR 等变量。它们适合用于定位指令文件、识别包名和调用同一套 Go 工具链，但不能把 GOPACKAGE 当成目录，也不能把 GOROOT 当成项目根目录。

需要使用同一套工具链时，直接让指令调用 go；Go 会优先把当前工具链的 GOROOT/bin 放到生成环境的 PATH 前面。需要跨包共享数据时，则把文件位置写进参数或配置，不要靠未记录的 shell 环境。

// 只记录 Go 为生成指令提供的定位信息，不把它们当成仓库根目录。
//go:generate go run ./cmd/print-context

package schema

在多包场景中，go generate ./... 会按包处理；某个包的生成器返回错误后，该包后续指令不会继续。因而排查“目录不对”时，先看指令究竟属于哪个包，再看相对路径和显式参数，最后才检查环境变量。

常见误区与采用建议

• 把 ./tools/gen 写在包目录里，实际却把工具放在仓库根目录；应按包到工具目录的相对关系书写。
• 把 os.Getwd() 当成仓库根目录；它反映生成器当前工作目录，应该被当作包目录使用。
• 用 sh -c 隐藏多层路径计算；这会增加跨平台和引号问题，优先用生成器参数表达边界。
• 只在根目录手动执行一次；团队还应让 CI 直接运行 go generate ./...，确保每个包的指令都被处理。

如果项目只有一个包，包相对路径已经足够；如果多个包共享根目录输入，就统一采用 -root 或同等明确参数，并在每条指令旁写清楚参数相对哪个目录解析。这样迁移到 CI、工作区或不同 shell 时，生成行为更容易保持一致。

从子目录运行会改变生成器工作目录吗？

不会。命令的启动目录可以变化，但生成器仍在指令所属包的源码目录执行。

能不能用环境变量直接得到仓库根目录？

Go 提供的生成变量没有“仓库根目录”这一项。若项目需要它，应通过包相对参数、配置或外层脚本明确传入。

为什么推荐把输出写成 generated.go？

因为它是包内相对路径，含义不依赖调用者从哪里启动；仓库级文件则应单独设计参数和边界。

最终判断标准很简单：每个相对路径都能回答“相对哪个目录”，每个共享资源都通过参数表达，生成器就不会把 shell 的偶然位置误当成项目结构。