Buffalo 不内置 Cron 调度能力，需手动集成 robfig/cron/v3；必须显式启用秒支持、管理实例生命周期防重复注册，并妥善处理关闭以避免任务泄漏。
Buffalo 本身不内置 Cron 调度能力
Buffalo 是一个 Go Web 框架，聚焦于路由、模板、数据库集成等 Web 开发常见需求，buffalo 命令和核心库中**没有提供定时任务调度模块**。它不会解析 cron 表达式，也不包含类似 Spring 的 @Scheduled 或 Quartz 的触发器管理机制。
这意味着你不能在 actions/ 或 app.go 里直接写 cron: "0 0 2 * * ?" 这类配置并期望框架自动执行——那会报错或被完全忽略。
实际做法是：**手动引入第三方 cron 库（如 github.com/robfig/cron/v3），在应用启动阶段显式初始化并注册任务**。
在 Buffalo 项目中集成 robfig/cron/v3
推荐使用 robfig/cron/v3，它支持秒级精度、时区、任务包装器（如重试、日志），且与 Buffalo 的生命周期兼容性好。
操作步骤如下：
- 运行
go get github.com/robfig/cron/v3安装依赖 - 在
app.go的App()函数内（或单独新建jobs/目录）初始化 cron 实例 - 调用
c.AddFunc()注册函数，传入标准 crontab 格式字符串（注意：v3 默认**不带秒字段**，需显式启用） - 务必调用
c.Start()，并在应用关闭前调用c.Stop()（可借助 Buffalo 的App.SignalNotify或grift钩子）
示例代码片段（放在 app.go 中）：
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
c := cron.New(cron.WithSeconds())
_, _ = c.AddFunc("*/10 * * * * *", func() {
log.Println("每 10 秒执行一次：清理过期 session")
})
c.Start()
// 注意：此处需确保 c.Stop() 在进程退出前被调用
crontab 表达式字段差异与常见坑
Linux crontab 是 5 字段（分 时 日 月 周），而 robfig/cron/v3 默认也是 5 字段；但很多开发者误以为它原生支持 6 字段（含秒）——其实必须加 cron.WithSeconds() 才能识别 * * * * * *。
容易踩的坑包括：
- 忘记启用秒支持，导致
"* * * * * *"解析失败，报错expected exactly 5 fields, found 6 - 时区默认为
Local，若部署在 UTC 服务器上，"0 0 2 * * ?"（意图为每天凌晨 2 点）实际按服务器本地时间跑，可能偏差 8 小时 - 任务函数 panic 会导致该任务后续不再触发，
v3不自动恢复，需自行包装recover()或用cron.WithChain(cron.Recover(cron.DefaultLogger)) - Buffalo 的
buffalo dev热重载会重启进程，但旧 cron 实例未 stop，造成任务重复注册（表现为同一任务执行多次）
避免热重载导致任务重复注册
这是 Buffalo + cron 最隐蔽的问题：每次保存代码触发 buffalo dev 重载，app.go 会被重新执行，如果 cron 初始化逻辑没做单例保护，就会不断新建 cron.Cron 实例并 Start()，最终多个调度器并发执行同一任务。
解决办法很简单：
- 把 cron 实例声明为包级变量（如
var taskCron *cron.Cron） - 在初始化前加判断：
if taskCron == nil { taskCron = cron.New(...) } - 在
buffalo dev退出时（SIGINT/SIGTERM），通过signal.Notify捕获并调用taskCron.Stop()
别依赖 defer —— 它只在当前 goroutine 退出时执行，而 buffalo dev 是杀进程，defer 来不及触发。
真正要小心的，不是表达式写对没写对，而是实例生命周期没管住。一旦跑进生产环境，重复任务可能引发数据双写、资源争抢甚至资损。
