<p>每分钟执行任务需在crontab中设置 *，并确保脚本有可执行权限、使用绝对路径、指定shebang、重定向日志，且避免环境变量缺失问题。</p>
crontab -e 添加 * * * * * 行是最直接的方式
每分钟执行的核心就是 cron 表达式中第一个字段设为 *，即 * * * * *。这个表达式不依赖具体时间点，只要 cron 服务在运行，就会严格按秒级精度触发（实际最小粒度为 1 分钟）。执行 crontab -e 后，在文件末尾新增一行即可，例如：* * * * * /home/user/backup.sh。注意：这一行不能有空格开头，也不能以 # 开头（会被当成注释忽略）。
脚本必须有可执行权限且用绝对路径调用
常见失败不是表达式写错，而是脚本本身跑不起来。cron 启动时的环境非常精简——PATH 通常只有 /usr/bin:/bin，不会加载你的 ~/.bashrc 或 $HOME 下的配置。所以：
- 确保脚本第一行是正确的 shebang，比如
#!/bin/bash - 运行
chmod +x /path/to/script.sh赋予执行权限 - crontab 中必须写完整绝对路径，不能用
~/script.sh或./script.sh - 脚本内部也尽量用绝对路径调用命令，比如用
/bin/date而非date
日志重定向和错误捕获不能省略
没有输出重定向的 cron 任务就像黑盒——它可能每分钟都在失败，但你完全不知道。默认情况下，标准输出和标准错误会通过邮件发送给当前用户，但多数系统没配本地邮件服务，结果就是静默丢弃。稳妥做法是显式重定向：
* * * * * /home/user/check.sh >> /var/log/check.log 2>&1
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
这样所有输出（包括报错）都会追加进日志。检查是否生效，别等一分钟：先手动运行一遍 /home/user/check.sh，确认能正常执行；再等 60 秒后用 tail -n 1 /var/log/check.log 看是否有新内容。
系统级 /etc/crontab 和用户 crontab 的字段数差异容易出错
如果你误用 sudo crontab -e 或直接编辑 /etc/crontab，格式就变了。用户级 crontab -e 是 5 字段 + 命令，而 /etc/crontab 是 5 字段 + 用户名 + 命令（共 7 字段）。写成 * * * * * /path/to/script.sh 在 /etc/crontab 里会报错或被当成“以用户 * 身份运行命令 *”，根本不会执行。除非你明确需要指定用户（比如让脚本以 www-data 身份跑），否则坚持用普通用户的 crontab -e，最安全。
真正容易被忽略的是环境变量缺失导致的隐性失败——比如脚本里用了 python3，但 cron 环境里 which python3 返回空；或者依赖某个自定义 PATH 下的二进制。这种问题不会报“command not found”，而是卡在某一步静默退出。解决办法不是猜，是在脚本开头加一句 env > /tmp/cron_env.txt，对比手动执行时的 env 输出，补全缺失项。
