crontab -e 编辑后不生效，首要检查 cron 服务状态（systemctl status cron/crond）和用户权限（/etc/cron.allow、/etc/cron.deny），其次确认环境变量与绝对路径，再排查时间格式及日志输出。
crontab -e 编辑后不生效？先看 crond 服务和权限
任务写完保存，却没执行——大概率不是语法错了，而是 crond 没跑起来，或者你没权限用它。
- 运行
systemctl status crond（CentOS/RHEL）或systemctl status cron（Ubuntu/Debian），确认状态是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 是空的，python3 或 node 这类命令大概率找不到。
- 所有命令、脚本路径必须写绝对路径：
/usr/bin/python3，不是python3；/home/user/script.sh，不是./script.sh或~/script.sh - 显式声明
PATH：在 crontab 条目前加一行，例如PATH=/usr/local/bin:/usr/bin:/bin - 或在脚本第一行写
#!/usr/bin/env python3，并确保脚本有执行权限：chmod +x script.sh - 务必重定向输出排查问题：
*/5 * * * * /usr/bin/python3 /home/user/job.py >> /tmp/job.log 2>&1；不加这句，错误全进邮件队列（多数系统默认关邮件）
时间表达式写对了但执行频率不对？分钟/小时字段逻辑容易错
看似简单的时间字段，实际匹配规则很严格，尤其“每 N 分钟”和“跨小时范围”的组合最容易翻车。
-
*/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等缩写
该用用户级 crontab 还是 /etc/cron.d/？看是否需要指定用户和权限隔离
用户级 crontab -e 最常用，但不适合需要明确指定运行用户、或需版本控制/多任务分组的场景。
- 普通个人任务（如自己写的备份脚本）：用
crontab -e，配置存于/var/spool/cron/用户名 - 需要以特定用户（如
www-data、postgres）运行的任务：放/etc/cron.d/mytask，格式必须含用户名字段，例如0 9 * * 1 www-data /usr/bin/python3 /opt/scripts/report.py -
/etc/cron.d/下的文件权限必须是644，且不能有 BOM 或末尾空格，否则整个文件被忽略 - 系统级全局任务（如日志轮转）优先走
/etc/crontab，它支持SHELL、PATH、MAILTO等全局变量设置
真正卡住人的，从来不是时间格式怎么写，而是 crond 拿到的环境跟你终端里完全两样。哪怕一行 echo "ok"，不加 >> /tmp/log 2>&1，你也看不到它到底有没有跑、卡在哪一步。
