buffalo 的 grift 任务不支持命令行 flag 参数，必须通过环境变量（如 task_id）或 os.args 手动解析传参；官方因避免 flag 冲突和反射开销而禁用动态 flag 注册。
Buffalo 的 grift 任务不支持命令行参数直接传入，必须通过环境变量或硬编码方式传递 —— 这是设计使然，不是你用错了。
为什么 grift 不接受 --arg 或 -p 这类 flag
Buffalo 的 grift 子命令基于 github.com/rubenv/sql-migrate 风格的轻量任务系统，它只解析预定义的全局 flag（如 --env、--config），所有自定义参数需由任务函数自行从 os.Args 或环境变量中提取。官方明确不打算支持动态 flag 注册，避免与 Go 的 flag 包冲突或引入运行时反射开销。
- 执行
buffalo task mytask --foo bar会报错：flag provided but not defined: -foo -
grift.Register只接收函数签名func(*grift.Context) error，没有参数注入机制 - 试图用
flag.Parse()在任务里手动解析会导致 panic：flag 已被主程序解析过一次
用 os.Getenv 传参最稳妥
这是 Buffalo 官方文档隐含推荐的方式，兼容所有环境（dev/staging/prod），且能配合 .env 文件管理。
- 在
grifts/mytask.go中读取：func MyTask(c *grift.Context) error { id := os.Getenv("TASK_ID") if id == "" { return errors.New("missing TASK_ID env var") } // … } - 调用时设置：
TASK_ID=123 buffalo task mytask - 开发时可提前写入项目根目录的
.env：TASK_ID=456，再直接运行buffalo task mytask - 注意：环境变量名建议全大写 + 下划线，避免和系统变量冲突
临时调试可用 os.Args，但别上生产
如果只是本地快速验证逻辑，且确定不会并行跑多个 grift 任务，可以绕过环境变量，直接截取 os.Args：
-
grift启动后，os.Args形如[buffalo task mytask --env=development]，你的参数得加在mytask后面，比如：buffalo task mytask 789 - 代码里取：
if len(os.Args) > 3 { arg := os.Args[3] // 注意索引，前三个是 buffalo/task/mytask } - 风险很高：不同 shell 对空格/引号处理不一致；CI 环境可能禁用直接传参；多任务并发时容易串参数
真正麻烦的不是怎么传，而是忘记清理环境变量——比如本地设了 TASK_ID=123，之后忘了删，结果在 staging 环境误删了生产数据。每次改完 grift 任务，顺手检查下 env | grep TASK 是个好习惯。
