Linux crontab 定时任务入门：从一条命令到自动化运维

很多重复性工作并不需要人工值守：每天凌晨备份数据库、每小时清理一次临时文件、每周一生成一次报表。这些需求在 Linux 上最常见的解法就是 crontab。它体积小、依赖少、几乎所有发行版都自带，学会它，就等于给服务器装上了一个可靠的闹钟。

先理解两层概念

cron 是系统里常驻的定时服务，它会按时间表唤醒任务；crontab 则是每个用户自己的时间表文件。用 crontab -e 编辑当前用户的时间表，用 crontab -l 查看，用 crontab -r 删除，操作之前一定要确认自己改的是哪个用户，因为 root 和普通用户的时间表是分开的。

五个时间字段怎么读

一行 crontab 记录一般由五个时间字段加一条命令组成，顺序是分、时、日、月、星期。星号表示每一个，斜杠表示步长，逗号表示多个值，连字符表示范围。例如 0 2 * * * 表示每天凌晨两点，*/10 * * * * 表示每十分钟，0 9 * * 1 表示每周一上午九点。记住这个顺序后，绝大多数定时需求都能直接写出来，不需要再去翻手册。

从一个安全例子开始

先不要直接写生产任务。建议先写一个只写日志的测试任务，例如每分钟向家目录的 cron-test.log 追加当前时间。保存后等两分钟，查看日志是否如期出现，再把时间改回真正需要的频率。这个习惯能帮你验证服务是否正常、时间是否符合预期，也避免一上来就误删文件或重复执行危险命令。

环境变量是最常见的坑

crontab 执行时的环境和交互式终端不一样，PATH 往往很短，家目录、语言环境也可能不同。因此脚本里尽量写命令的绝对路径，例如 /usr/bin/python3，而不是只写 python3；需要用到特定环境变量时，在脚本开头显式导出。另一个常见问题是相对路径：脚本里写 data.txt，实际工作目录未必是你以为的目录，改成绝对路径最稳妥。

输出一定要有去处

定时任务没有终端，标准输出和标准错误如果不处理，可能会被系统以邮件形式发给用户，甚至堆积起来。建议把输出重定向到日志文件，例如在命令后加上 >> /var/log/backup.log 2>&1。这样既能排查问题，也能确认任务到底跑没跑。日志要定期轮转，避免一个日志文件无限变大。

权限与测试清单

第一，确认脚本本身有可执行权限，必要时用 bash /path/to/script.sh 的方式调用；第二，确认脚本在手动执行时能成功，再交给 crontab；第三，确认定时任务的用户有读写相关目录的权限；第四，涉及数据库或远程服务时，先确认凭据和网络在非交互环境下也能用。把这四项过一遍，能避开大部分上线后才发现的问题。

什么时候不适合用 crontab

如果任务之间有严格依赖、需要失败重试、需要分布式调度或可视化监控，crontab 就会显得力不从心。这时可以考虑 systemd timer、Airflow 这类更强的调度工具。但对单机上的日常运维来说，crontab 仍然是成本最低、最容易维护的选择。先用它把流程跑通，再根据需要升级工具，是更务实的路线。

结语

定时任务的价值不在于写得多复杂，而在于稳定、可预期、可排查。从一条每分钟写日志的测试任务开始，逐步加上绝对路径、日志重定向和权限检查，你就能把重复劳动交给系统，把时间留给真正需要判断的工作。这正是 crontab 入门最值得养成的工作方式。