先确认 cron 服务状态和用户权限：运行 systemctl status cron（debian/ubuntu）或 systemctl status crond（centos/rhel），确保 active (running)；非 root 用户需检查 /etc/cron.allow（仅允许列表内用户）或 /etc/cron.deny（默认允许未被拒绝者）。
crontab -e 编辑后不生效？先确认服务状态和用户权限
绝大多数“配置了却没跑”的问题，根本原因不是语法写错，而是 crond 没在跑，或任务没落到对的用户上下文里。
- 运行
systemctl status crond（CentOS/RHEL）或systemctl status cron（Debian/Ubuntu），确保输出含active (running) - 非 root 用户执行
crontab -e，任务只会以该用户身份运行；想用 root 权限，必须用sudo crontab -e（不是crontab -u root -e，后者常被策略拒绝） - 检查
/etc/cron.allow和/etc/cron.deny：如果存在cron.allow，只有其中列出的用户才能用crontab；若只有cron.deny且为空，所有用户默认可用
脚本在终端能跑，但 crontab 里静默失败？重点查三件事
crond 启动时只加载极简环境：不读 ~/.bashrc，$PATH 是空的，也没你的 alias 或函数。所以“找不到命令”“ModuleNotFoundError”“Permission denied”基本都源于此。
- 命令和脚本路径必须写绝对路径：
/usr/bin/python3不能写成python3，/home/user/job.py不能写成./job.py或job.py - 显式声明环境变量：在 crontab 条目前加
PATH=/usr/local/bin:/usr/bin:/bin，或在脚本首行写#!/usr/bin/env python3并确保有执行权限（chmod +x job.py） - 重定向输出排查问题：
*/5 * * * * /usr/bin/python3 /home/user/job.py >> /tmp/job.log 2>&1—— 不加这句，错误全丢进邮件队列（多数系统默认关邮件），你根本看不到报错
/etc/crontab 和 /etc/cron.d/ 的区别在哪？什么时候该用哪个
用户级 crontab -e 简单直接，但无法指定执行用户；系统级配置则必须区分场景。
-
/etc/crontab：格式是分 时 日 月 周 用户名 命令，第六字段必须是用户名（如root）。适合需要明确以某用户身份运行、且影响全局的任务 -
/etc/cron.d/下的文件：每行也必须含用户名字段，文件权限必须为644（sudo chmod 644 /etc/cron.d/mytask），文件名不能带点（如mytask.conf会被忽略） - 直接编辑
/var/spool/cron/用户名文件风险高：需sudo，改完要重启crond（sudo systemctl restart crond），且文件权限必须是600、属主必须匹配对应用户
时间表达式怎么写才不会踩坑
看似简单的 * * * * * 字段，实际最容易出错的是分钟/小时组合逻辑和星期字段语义。
-
*/10 * * * *表示“每 10 分钟”，即 0、10、20、30、40、50 分各执行一次；10/10 * * * *是非法写法（起始值不能大于步长） - 想在每天 9–17 点之间每 30 分钟执行一次？别写
0,30 9-17 * * *—— 这会在 17:30 执行，超出业务范围；正确写法是0,30 9-16 * * *+0 17 * * * - 星期几字段：0 和 7 都表示周日，但部分老系统只认 0；建议统一用数字，避免用
SUN等缩写（发行版兼容性差）
真正让定时任务稳定跑起来的，不是写对那行 0 2 <em> </em> *，而是理解 crond 启动时那个空荡荡的 shell 环境、它不认你终端里的任何配置、也不帮你猜路径——所有依赖，都得你亲手写死。
