symfony/scheduler 不是独立包，需通过 symfony/framework-bundle（v6.4+）启用 scheduler: true 配置，并在 dev/test 环境运行 bin/console scheduler:listen --daemon；纯 console 应用需手动注册 schedulercommand；scheduler:run 适用于外部调度器场景。
Composer 安装 symfony/scheduler 失败：找不到包
symfony/scheduler 并不是一个独立发布的 Composer 包，它目前（截至 Symfony 7.1）仍处于实验性阶段，未发布为 symfony/scheduler。直接运行 composer require symfony/scheduler 会报错：Could not find package symfony/scheduler。
你真正需要的是 symfony/console + symfony/framework-bundle（或 symfony/runtime）的组合，并手动启用调度器功能——它被集成在框架核心中，但默认不激活。
- 确保已安装
symfony/framework-bundle（v6.4+ 或 v7.0+），scheduler 功能从该版本起内建 - 检查
config/packages/framework.yaml中是否启用了scheduler: true - 若用的是纯 Console 应用（无 Bundle），需手动注册
SchedulerCommand和Scheduler服务，且依赖symfony/consolev6.4+
配置 scheduler 后运行 bin/console scheduler:listen 报 Command "scheduler:listen" is not defined
这个错误说明命令未被注册，常见于 Bundle 未正确加载、配置未生效，或环境未匹配。
关键点是：scheduler 命令只在 dev 和 test 环境默认启用；生产环境（prod）下被禁用，且不会自动注册命令。
- 确认当前环境是
dev：APP_ENV=dev bin/console scheduler:listen - 检查
config/bundles.php是否启用了Symfony\Bundle\FrameworkBundle\FrameworkBundle::class - 清空缓存：
bin/console cache:clear --env=dev，否则新配置可能不加载 - 若自定义了
ConsoleApplication（如无 Bundle 场景），需显式添加：$application->add(new SchedulerCommand($scheduler))
写了一个 Schedule 类，但任务没触发：时间、时区、执行逻辑全对，就是不跑
最常被忽略的是「调度器不自动轮询」——scheduler:listen 是一个长进程，必须持续运行才能检测和触发任务；它不是 systemd/cron 替代品，而是应用内轻量轮询器。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
这意味着：它只在命令启动期间有效，退出即停止，也不会跨请求持久化状态。
- 不要靠单次执行
bin/console scheduler:listen --no-interaction就以为任务会“后台常驻”——它只是监听一次然后退出 - 必须加
--daemon（Symfony 7.1+）或使用--watch（旧版）保持运行：bin/console scheduler:listen --daemon - 确认系统时区与 PHP 时区一致（
date_default_timezone_set()影响CronExpression解析） - 任务回调函数若抛出未捕获异常，该任务会被静默跳过（日志级别为
debug，需开monologdebug 日志才可见）
能否用 cron 调度 bin/console scheduler:run 而不是 listen？
可以，但语义不同：scheduler:run 是单次扫描执行（类似 cron job 本身），而 scheduler:listen 是持续监听 + 自动重试 + 状态感知的交互式模式。
如果你已有外部调度器（如系统 cron、Kubernetes CronJob），scheduler:run 更合适，也更可控。
-
bin/console scheduler:run --env=prod可在生产环境安全使用（无需 daemon） - 注意：它默认只执行「已到期且未失败」的任务；失败任务需加
--force才重试 - 避免高频调用（如每秒一次）——内部有锁机制，频繁运行会导致竞争和日志刷屏
- 推荐间隔 ≥30 秒；若需亚秒级精度，应换用专用队列系统（如 Messenger + Redis Streams）
真正麻烦的从来不是怎么写一个 Schedule 类，而是搞清它到底依赖谁在“看时间”、谁在“发号施令”、以及谁在“兜底失败”。漏掉环境、时区、守护方式任意一环，任务就安静得像没写过。
