为什么值得从 cron 迁走
cron 的问题不在于「不能定时」，而在于可观测性几乎为零。任务失败时你在 /var/log/syslog 里翻一行被截断的文本，看不到退出码，也拿不到 stdout/stderr；任务是否正在运行、上次跑了多久、为什么被跳过，cron 一个都答不上。
环境变量也需要脑补。cron 的默认 PATH 极短，脚本里 which java 找不到东西只是因为 /usr/local/bin 不在里面。非交互式执行、没有 tty，很多程序还会因此走进不同的代码分支，这些坑排查起来非常费时间。
更致命的是漏跑不可见。机器在 03:00 宕机、04:00 重启，那个本该在 03:15 跑的任务就静默消失了，要等到第二天的数据对不上才会被发现。systemd timer 的 Persistent=yes 正是为这个场景而生：错过的时间点会在开机后立刻补跑一次。
最后是重复触发问题。crontab 里如果上一个任务还没跑完、下一个时间点又到了，两个实例会并发写同一个文件，轻则数据错乱，重则锁竞争雪崩。systemd 可以用 RefuseManualStart 之外的机制配合 service 单元的 RuntimeMaxSec 与 Restart=on-failure 约束，行为更可预期。
# 现状盘点：先看清这台机器上都有什么 cron 任务
crontab -l
ls -l /etc/cron.d/ /etc/cron.daily/ 2>/dev/null
systemctl list-timers --all最小可用形态：一个 timer 单元 + 一个 service 单元
核心心智模型只有一句：.timer 单元只负责「什么时候被触发」，.service 单元负责「跑什么」。两者同名，通过 Unit= 关联。timer 被触发时，systemd 会启动同名 service；如果 service 已在运行，默认行为是拒绝再次启动（这正是你想要的去重语义）。
注意 WantedBy= 在 timer 里指的是「timer 自己被谁拉起来」，通常是 timers.target；而 WantedBy= 在 service 里才是 multi-user.target。写错不报错，但 timer 永远不会被启用，这是最常见的「配了但不跑」原因。
Type=oneshot 是定时任务的标配：进程跑完就结束，systemd 直接认为成功。务必配合 SuccessExitStatus 或在命令末尾显式判断退出码，因为 oneshot 默认不重启，失败就是失败，你只能靠 systemctl status 发现。
文件放 /etc/systemd/system/（系统级）或 ~/.config/systemd/user/（用户级）。改完必须 daemon-reload，否则 systemd 读的还是内存里的旧版本；这一条忘一次就排查半小时。
# /etc/systemd/system/backup-db.service
[Unit]
Description=Nightly database backup
[Service]
Type=oneshot
User=appuser
ExecStart=/usr/local/bin/backup-db.sh
# 执行超时保护，避免任务卡死永久占位
RuntimeMaxSec=2h
# /etc/systemd/system/backup-db.timer
[Unit]
Description=Run database backup at 03:15
[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true
RandomizedDelaySec=300
Unit=backup-db.service
[Install]
WantedBy=timers.targetOnCalendar：比五字段 cron 强在哪
五字段 cron 的表达力上限很低——「每月最后一个工作日」「每月 15 日的 UTC 02:00」「周末」都写不出来。OnCalendar= 直接支持这些：Mon..Fri 09:00、*-*-01 00:00:00、weekly、以及 last/n..m 区间与「跳过不存在日期」的 ~ 后缀。
时区必须显式考虑，这是迁移时最容易翻车的地方。OnCalendar= 里的裸时间默认按**本地时区**解释，而服务器常跑 UTC。如果业务语义是「北京时间凌晨 3 点」，一定要写 OnCalendar=*-*-* 03:00:00 Asia/Shanghai，不要指望系统时区恰好正确。
OnCalendar= 可以写多行，每行都会被调度——这等价于一条 crontab 里的多个条目，但各自独立计时。配合 Persistent=true，每一条都有自己的补跑判断，比一个 0 3 * * * 里塞十个命令健壮得多。
别忘了 systemd-analyze calendar "*-*-* 03:15:00 Asia/Shanghai"：它会把表达式解析成「下次触发时间 + 距今秒数」，比反复 date 试算快得多，也是验证表达式是否被 systemd 接受的最直接方式。
systemd-analyze calendar "*-*-* 03:15:00 Asia/Shanghai"
systemd-analyze calendar "Mon..Fri 09:00"
# 输出示例：Next elapse: Fri 2026-10-02 03:15:00 CST
# In roughly 1 day 3h 12min 4sPersistent 补跑与其它关键指令
Persistent=yes 的语义要精确理解：它记录上次成功触发的时间戳，机器启动时如果发现「本应触发的时刻已经过去且未触发」，就立刻触发一次；反之若上次是正常触发的，就等下一个时间点。它只保证「至少跑过一次」，不保证「按原计划时刻跑」。
配套的三个指令解决重复与抖动问题：AccuracySec=（默认 1 分钟）让 systemd 把多个触发点合并以降低唤醒次数，想精确执行设 AccuracySec=1us；RandomizedDelaySec= 给每次触发加随机延迟，避免全网机器在同一秒同时打向一个外部服务；WakeSystem= 控制是否允许唤醒停机状态的机器（需要 root 且机器支持 RTC wake）。
AccuracySec 与 RandomizedDelaySec 的顺序是 Randomize 在 Accuracy 之上：实际偏移 = 随机值（0 到 RandomizedDelaySec）再对齐到 AccuracySec 边界。所以想让大批机器错峰，把 RandomizedDelaySec=1800 给足，比调 AccuracySec 有效得多。
对于「每 N 分钟」这类短周期任务，不要用 OnUnitActiveSec 硬拼——用 OnUnitInactiveSec= 更准确：它在**上一个实例结束**后计时 N 秒，因此天然不会出现任务堆积。OnUnitActiveSec 则是从开始计时，任务耗时超过间隔时同样会堆积。
# /etc/systemd/system/heartbeat.timer
[Unit]
Description=Heartbeat every 5 minutes after previous run ends
[Timer]
OnBootSec=2min
OnUnitInactiveSec=5min
AccuracySec=10s
Persistent=true
Unit=heartbeat.service
[Install]
WantedBy=timers.target从 crontab 平滑迁移的对照关系
迁移的正确姿势不是「删掉 crontab 重写一遍」，而是并行运行一段时间验证等价：先装 timer 并启用，但把旧 crontab 注释掉并保留备份（crontab -l > /root/crontab.bak），观察至少一个完整周期，确认执行时刻、退出码、输出都符合预期后再彻底删除。
几个常见条目的一对一对应关系：* * * * * → OnCalendar=*:0/1；*/15 * * * * → OnCalendar=*:0/15；0 3 * * * → OnCalendar=*-*-* 03:00:00；@reboot → OnBootSec= 加 Persistent=true；@daily → OnCalendar=daily（注意 daily 是本地 00:00，不是 03:00）。
环境变量不再自动继承 cron 的那套，需要显式声明。最省事的是把逻辑放进脚本，然后在 service 单元里用 Environment= / EnvironmentFile= 注入变量与 PATH，避免依赖登录 shell 的 profile。注意 EnvironmentFile= 指向的文件必须存在，否则 unit 直接启动失败（用 - 前缀可让缺失被忽略）。
迁移完务必做一次端到端验证：systemctl start <unit>.service 手动触发一次看输出，systemctl list-timers --all 确认下次触发时间合理，再 journalctl -u <unit>.service -n 50 确认日志落在 journal 里而不是 syslog。这三条都过了，才算真的迁完。
systemctl daemon-reload
systemctl enable --now backup-db.timer
systemctl start backup-db.service # 手动跑一次看输出
systemctl list-timers --all
journalctl -u backup-db.service -n 50 --no-pager
systemctl status backup-db.timer