crontab -e 保存后不生效，首要排查 cron 服务状态、用户权限、日志输出及环境差异；必须用绝对路径、显式声明 PATH 和环境变量、指定解释器，并验证脚本在无交互环境下能否独立运行。
crontab -e 保存后不生效？先查日志和权限
绝大多数“配置了但没跑”的问题，不是语法错，而是 cron 守护进程根本没读到你的任务，或者没权限执行。别急着改 crontab 格式，先确认基础链路通不通。
-
systemctl status cron（或crond，取决于发行版）确保服务在运行 - 普通用户加的任务，必须用该用户执行
crontab -e；root 任务必须用sudo crontab -e，混用会导致静默失败 - 检查
/var/log/syslog或journalctl -u cron -n 50，搜索CRON关键字，看有没有(user) CMD (command)这类执行记录，没有就说明压根没触发 - cron 默认不加载用户的
~/.bashrc或~/.profile，PATH 极其有限（通常是/usr/bin:/bin），which python或which node找不到是常态
脚本路径、环境变量、Shell 解释器全得显式写死
cron 环境干净得过分——没 $HOME 自动补全，没别名，没 shell 函数，甚至 sh 不一定等于 bash。靠“本地能跑”推断 cron 能跑，基本等于碰运气。
- 所有路径必须用绝对路径：
/home/user/script.sh，不能写~/script.sh或./script.sh - 需要特定环境变量（比如
PYTHONPATH、NODE_ENV）？在 crontab 条目最前面定义，例如：PATH=/usr/local/bin:/usr/bin:/bin PYTHONPATH=/opt/myapp/lib * * * * * /usr/bin/python3 /opt/myapp/job.py - 如果脚本依赖
bash特性（如数组、[[），别依赖默认sh，显式指定解释器：* * * * * /bin/bash /path/to/script.sh - 重定向输出很重要：加
> /tmp/job.log 2>&1，否则失败时你连报错都看不到
分钟级任务总在整点触发？注意 cron 的时间字段顺序和取值范围
记错字段顺序或理解偏差，是低级但高频的错误。cron 表达式是「分 时 日 月 周」，不是「秒 分 时…」，而且周和月的日是「或」关系，不是「且」。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 常见误写：
0 9 * * 1-5是工作日上午 9 点，但0 9 * * 1,2,3,4,5才等价；0 9 * * 1-5,0并不会包含周日——因为0是周日，1-5是周一到周五，0单独写才有效 - 想每 5 分钟跑一次？写
*/5 * * * *，不是5 * * * *（后者是每小时第 5 分钟） - 想每月 1 号凌晨 2 点跑，且避开周末？不能靠
0 2 1 * *加逻辑判断——cron 本身不支持“且”条件，得在脚本里用date +%u检查星期几再退出 - 测试时别用
*频繁刷屏，先设成* * * * *（每分钟），验证通了再调回真实周期
Python 脚本在 cron 里报 ModuleNotFoundError？别猜路径，直接用虚拟环境完整路径
系统 Python、用户 pip install、venv、conda 环境混在一起时，cron 用的 python 很可能不是你预期的那个。ModuleNotFoundError 几乎都源于解释器和包环境不匹配。
- 不要写
python script.py，而要写/home/user/venv/bin/python /home/user/script.py—— 把 Python 解释器和脚本路径都绝对化 - 如果用了
pip install --user，模块装在~/.local/lib/python3.x/site-packages，但 cron 下$HOME可能未正确展开，不如直接进 venv 执行 - 临时调试：在 crontab 里加一行
* * * * * /bin/bash -c 'echo $PATH; which python; python -c "import sys; print(sys.path)"' >> /tmp/cron-env.log 2>&1，对比本地输出 - 避免用
source activate或conda run——它们依赖 shell 初始化，cron 不走那套流程；直接调用 conda 环境里的 python 更可靠
真正麻烦的从来不是写对那一行 cron 表达式，而是它背后那个没有交互、没有提示、不继承 shell 环境的黑盒执行上下文。每次加新任务，先问自己：这个命令脱离我的终端，能不能独立跑通？
