mage需安装到$gobin并加入$path；magefile.go须为package main且无func main()；任务函数须返回Error且参数仅限零或一个context.context；不支持子目录递归扫描，靠函数名约定模拟层级；可用mage -compile生成二进制提速。
mage 命令没找到，Go module 模式下怎么装才生效
mage 不是 Go 标准工具，必须显式安装到 $GOBIN（默认是 $HOME/go/bin），且该路径得在 $PATH 里。很多人用 go install github.com/magefile/mage@latest 装完却执行不了 mage，八成是 $GOBIN 没进 $PATH。
- 先确认安装路径：
go env GOPATH和go env GOBIN，后者为空时会 fallback 到$GOPATH/bin - 检查
echo $PATH是否包含那个路径；没包含就补上，比如 zsh 中加export PATH=$HOME/go/bin:$PATH到~/.zshrc - 别用
go run github.com/magefile/mage@latest --help临时跑——它不读本地Magefile.go，也不支持 tab 补全，纯调试用
Magefile.go 编译失败：package main 冲突和函数签名错误
mage 要求 Magefile.go 必须是可执行的 Go 文件，但又不能真当普通 main 包运行。常见报错像 cannot load package: package main is not a main package 或 function must be of type func() error or func(context.Context) error，本质是 mage 对入口函数约束极严。
- 文件开头必须是
package main，但不能有func main()—— mage 会自己注入调度逻辑 - 所有公开任务函数（首字母大写）必须返回
error，且参数只能是零个或一个context.Context；func Build() error✅，func Build(out String) error❌ - 如果用了
go:generate或其他注释指令，确保它们在package main声明之后、函数之前，否则 mage 解析器可能跳过
如何让 mage 自动识别子目录下的任务（比如 mage test:unit）
mage 默认只扫描当前目录的 Magefile.go，不递归，也不支持冒号分隔的命名空间语法。所谓 mage test:unit 是假象——实际是靠函数名约定（如 TestUnit()）+ -l 列表过滤实现的。
- 想模拟层级，函数名用驼峰或下划线分隔：
TestUnit()、TestIntegration()、BuildFrontend()，然后用mage -l | grep test筛 - 跨目录复用任务？别硬塞路径。把公共逻辑抽成独立
.go文件（如tasks/build.go），在Magefile.go里 import 并调用，mage 会自动编译整个模块 - 注意：mage 不支持动态加载外部 Magefile，
mage -f ./other/Magefile.go仅指定单个文件，不会合并多个
mage 构建慢、重复编译、无法缓存中间产物
mage 每次运行都会重新编译整个 Magefile.go 及其依赖，不像 Make 那样能跳过未变更目标。这不是 bug，是设计取舍——它优先保证任务逻辑绝对干净，但代价是冷启动明显。
立即学习“go语言免费学习笔记（深入）”；
- 提速关键：用
mage -compile把当前 Magefile 编译成二进制（如mage -compile ./bin/mage-build），后续直接运行该二进制，跳过编译阶段 - 避免在任务里反复
exec.Command("go", "build", ...)——改用golang.org/x/tools/go/packages或os/exec复用 cmd 实例，减少进程开销 - 缓存输出？mage 本身不提供，但你可以用
os.Stat检查产物时间戳，或借助github.com/magefile/mage/mg的mg.Deps()声明前置依赖，控制执行顺序
真正麻烦的是跨平台构建时的环境差异——比如 windows 下路径分隔符、权限位、shell 内置命令缺失，这些不会报错，但会让任务行为不一致。写任务前先用 runtime.GOOS 分支处理，比事后 debug 强得多。