Symfony 6.0 定时任务依赖系统 cron，需手动配置 crontab 调用命令；命令须继承 Command 类、置于 src/Command/、避免 HTTP 上下文依赖，并用绝对路径+环境参数+日志重定向调用。
定时任务不是靠 Cron 本身实现的
Symfony 6.0 自身不提供 Cron 守护进程或后台调度器，cron 是系统级工具，Symfony 只负责生成可被 cron 调用的命令。你得自己在服务器上配 crontab，否则命令永远不会自动跑。
常见错误是以为运行 php bin/console app:send-reminder 就算“加了定时”，结果第二天发现没执行——因为没注册到系统 cron。
- 所有定时逻辑必须封装成 Symfony 命令（继承
Command类） - 命令必须可独立执行，不能依赖 HTTP 请求上下文（比如
$request或 session） - 避免在命令里调用
die()、exit()，会中断cron日志记录 - 推荐加日志输出：用
$this->logger->info('Cron job started')，方便排查是否真被触发
如何写一个可被 cron 调用的 Symfony 命令
命令类要放在 src/Command/ 下，命名建议带 Cron 或业务标识（如 SendDailyReportCommand），避免和交互式命令混淆。
关键点：不要依赖容器中非单例或易失效的服务（比如 Doctrine 的 EntityManager 实例需在 execute() 内获取，而不是构造函数里保存）。
- 使用
InputInterface和OutputInterface处理参数和输出，别用echo - 数据库操作前检查连接：可用
$em->getConnection()->ping()防止长连接超时中断 - 大任务记得设超时：
set_time_limit(300)（5 分钟），避免卡住整个 cron 队列 - 如果命令需锁机制防重复执行，用
cache.system缓存键 +lock（Symfony 自带Symfony\Component\Lock\Store\FlockStore）
示例片段：
protected function execute(InputInterface $input, OutputInterface $output): int
{
$em = $this->getDoctrine()->getManager();
if (!$em->getConnection()->ping()) {
$output->writeln('DB connection lost');
return Command::FAILURE;
}
<pre class="brush:php;toolbar:false;">// ... 执行业务逻辑
return Command::SUCCESS;}
crontab 怎么写才不踩坑
直接编辑用户级 crontab -e，别往 /etc/crontab 里硬写——权限、PATH、工作目录都不一样，90% 的“命令不执行”问题出在这儿。
典型错误：用相对路径 php bin/console ...，但 cron 默认工作目录是用户 home，不是项目根目录。
- 务必用绝对路径：
/usr/bin/php /var/www/myapp/bin/console app:send-daily-report --env=prod - 显式指定
--env=prod，避免意外加载 dev 环境配置 - 重定向 stdout/stderr：
> /dev/null 2>&1或更稳妥地写入日志文件：> /var/log/myapp/cron.log 2>&1 - 测试时先手动执行整条命令，确认返回码是 0，再加进 crontab
- 注意时区：服务器时区（
date输出）必须和你的业务预期一致，Symfony 不会自动转换
为什么生产环境不能只靠单个 cron 条目
当任务变多（比如每分钟清理缓存、每小时统计、每天归档），全堆在一个 crontab 条目里会难维护、难监控、难单独启停。
更合理的做法是分任务注册独立条目，用不同频率和日志路径隔离：
0 * * * * /usr/bin/php /app/bin/console app:clear-cache --env=prod >> /var/log/myapp/cache-cron.log 2>&130 2 * * * /usr/bin/php /app/bin/console app:generate-report --env=prod >> /var/log/myapp/report-cron.log 2>&1- 每行末尾加注释说明用途：
# Daily report generation at 02:30
复杂场景（依赖顺序、失败重试、可视化看板）就得换专用调度器，比如 supercronic（容器友好）或 redis + symfony/messenger 异步队列方案——但那是另一层复杂度了，基础 cron 能跑稳就先别跳。
