Taskfile.yml 是 Go 项目自动构建的正确起点，需严格遵循命名、版本、cmds 数组等规范，显式设置环境变量与跨平台参数，并通过 deps 编排任务以保障可复现性。
go build 是起点，但仅靠它无法构成“自动构建”——你需要任务编排、环境隔离、跨平台支持和可复现性。直接在 shell 里敲 go build -o bin/app . 能跑通一次，但没法持续集成、没法区分 dev/staging/prod 构建行为、也没法让队友或 CI 环境得到一致结果。
用 Taskfile.yml 替代手写 shell 脚本
Task 是专为 Go 项目设计的轻量级任务运行器，YAML 定义、跨平台一致、原生支持 env/dir/deps，比 Make 更可靠（尤其在 Windows 上）。
- 文件名必须是
Taskfile.yml（全小写、带点、后缀 yml），且放在项目根目录；写成taskfile.yaml或Taskfile都不识别 -
version必须加引号，如version: '3'；v2 不支持status和dotenv，已淘汰 -
cmds必须是数组：即使只有一条命令，也要写成- go build -o bin/app .，不能写cmds: go build -o bin/app . - 没声明
dir字段时，工作目录就是Taskfile.yml所在位置，不会自动 cd 进cmd/或internal/
交叉编译必须显式设 GOOS/GOARCH
Go 的 GOOS 和 GOARCH 是环境变量，task 默认不继承父 shell 的环境，也不能靠本地 export GOOS=linux 临时生效。
- 每个任务需单独声明
env，避免污染其他任务：例如build-linux里设GOOS: linux，build-darwin里设GOOS: darwin - Windows 下生成可执行文件，命令末尾必须加
.exe后缀：go build -o bin/app-windows-amd64.exe . - 若要并行构建多平台，用
deps声明依赖：build-all: &build-all deps: [build-linux, build-darwin, build-windows]；默认并发执行，无需额外配置
别把 Makefile 直接翻译成 YAML
常见错误是把 Makefile 的变量展开、隐式路径、shell 函数照搬进 Taskfile，导致跨平台失败或构建不一致。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Make 中的
$(shell git rev-parse --short HEAD)在 Task 中不能直接用；应改用vars+sh命令预计算，或用status检查前置条件 - Make 的
.PHONY对应 Task 的status字段，用于跳过缓存判断；不设status的任务，task 会检查输出文件时间戳决定是否跳过 - 不要在
cmds里写多行 shell 逻辑（如 if/for）；应拆成独立任务，用deps控制顺序，保持单任务职责清晰
CI 中跑 task 要注意 PATH 和二进制位置
GitHub Actions 或 GitLab CI runner 通常不预装 task，也不能依赖系统包管理器（如 apt install task）安装，版本易错乱。
- 推荐在 CI 脚本中用二进制直装：
curl -sL https://gitcode.com/gh_mirrors/ta/task/raw/master/install-task.sh | sh - 确认
$HOME/bin在$PATH中；CI 环境可能需要显式添加：echo "$HOME/bin" >> $GITHUB_PATH（GitHub Actions） - CI 中建议加
--force参数强制运行（绕过status缓存），确保每次构建干净：task --force build-linux
真正容易被忽略的是：task 不是“另一个 Make”，它是以 Go 项目为前提设计的工具——所有路径、环境、依赖都默认围绕 Go 工作区（go.mod 位置）组织。一旦你把 Taskfile.yml 放错位置，或在子模块里试图复用根目录的 task 定义，就立刻失去可复现性。
