gocron/v3 中 AddFunc 不支持传参是设计约束，须用 AddJob + cron.FuncJob 显式捕获参数，或实现 cron.Job 接口绑定参数；时区未显式设置（如 time.UTC）会导致初始化 panic，阻断后续参数传递逻辑。
gocron/v3 AddFunc 无法直接传参，这是设计使然
AddFunc 接收的函数签名固定为 func()，不支持参数。这不是 bug，是 v3 明确的设计约束：避免闭包捕获外部变量引发的竞态或内存泄漏。常见错误是写成这样：
userID := 123
c.AddFunc("* * * * * ?", func() {
process(userID) // ❌ userID 是循环外变量，所有任务共享同一份值
})结果是所有调度实例都拿到最后一次赋值的 userID，或者更糟——如果 userID 在后续被修改，任务执行时读到的是未知状态。
用 FuncJob 包装带参函数才是安全做法
v3 提供了 cron.FuncJob 类型，它接受一个闭包，但关键在于：你必须在每次构造时「显式捕获」所需参数，而不是依赖外部变量作用域。
- ✅ 正确：用局部变量绑定参数，再传入
FuncJob - ✅ 正确：把参数塞进结构体，实现
Job接口（适合复用、带状态） - ❌ 错误：直接在
AddFunc的匿名函数里引用循环变量或全局变量
示例：
立即学习“go语言免费学习笔记（深入）”；
userID := 123
c.AddJob("* * * * * ?", cron.FuncJob(func() {
process(userID) // ✅ 这里 userID 是当前栈帧的副本，安全
}))注意：AddJob 替代了旧版 AddFunc，返回 cron.EntryID，便于后续控制生命周期。
需要动态 ID 或上下文？自己实现 Job 接口更可控
当你要区分“哪个任务触发了”“带 traceID 打日志”“根据配置决定是否跳过”，靠闭包不够。此时应实现 cron.Job 接口：
type UserJob struct {
ID int
Callback func(int)
}
func (u *UserJob) Run() {
u.Callback(u.ID)
}然后注册：
job := &UserJob{
ID: 123,
Callback: func(id int) { log.Printf("user %d processed", id) },
}
c.Schedule(cron.Every(5*time.Second), job)这种写法完全绕过闭包陷阱，参数绑定在结构体字段上，可序列化、可测试、可加锁控制状态。
容器环境 panic "invalid time zone" 会干扰参数传递逻辑
如果你在 Docker 或 CI 环境中看到 AddJob 或 Schedule 调用前就 panic 报 invalid time zone，说明 cron 实例根本没创建成功——参数传递那步压根没跑。根本原因不是参数问题，而是时区加载失败。
- 必须显式指定时区：
cron.New(cron.WithLocation(time.UTC)) - 别依赖
time.Local，它在无/etc/localtime的镜像里必然失败 - 哪怕你参数包装得再完美，cron 实例初始化失败，一切调度都无从谈起
这个点容易被忽略：错误日志出现在任务注册之前，但开发者第一反应总往“参数怎么传”上想，其实该先看 cron.New 是否成功返回。
