systemd timer 的 OnCalendar 默认精度为1分钟，实际触发时间可能偏差达60秒；需通过AccuracySec参数调低至秒级或毫秒级以提升精度，但会增加CPU唤醒频率。
systemd timer 的 OnCalendar 默认精度是 1 分钟
systemd 在默认配置下会对 OnCalendar 触发时间做“对齐”处理，把所有计划在同分钟内的事件批量调度，最大允许误差达 60 秒。这不是 bug，而是设计选择：降低唤醒频率、减少系统抖动。但如果你写的是 OnCalendar=*-*-* *:*:30（每分钟第 30 秒触发），实际可能在 xx:xx:30–xx:xx:59 任意时刻运行——这对监控轮询、定时快照等场景已属不可接受。
修改 AccuracySec 可提升到毫秒级（但需谨慎）
AccuracySec 是 timer unit 中控制精度的核心参数，默认值为 1min。把它设为 1s 或 100ms 确实能缩小偏差，但要注意：
- 值越小，systemd 越频繁地唤醒并检查时钟，尤其在低功耗设备或虚拟机中会增加 CPU 唤醒次数
- 低于
1s时，systemd 不再保证严格准时（底层依赖clock_gettime(CLOCK_MONOTONIC)和内核定时器精度），实测AccuracySec=100ms在多数桌面环境可稳定控制在 ±200ms 内 - 必须写在 timer unit 文件的
[Timer]小节里，且不能和RandomizedDelaySec同时启用（后者会覆盖前者效果）
示例：
[Timer] OnCalendar=*-*-* *:*:00 AccuracySec=1s Persistent=true
OnCalendar 时间表达式本身不决定精度，只定义匹配规则
很多人误以为写 OnCalendar=*-*-* *:*:00.500（带毫秒）就能触发半秒级任务，但 systemd 解析器根本不支持小数秒语法，该行会被静默忽略或报错 Invalid argument。真正起作用的是：
-
OnCalendar仅用于生成下一个匹配时间点（按日历逻辑计算） - 最终是否在这个时间点执行，完全由
AccuracySec+ 当前系统负载 + 定时器队列状态共同决定 - 如果需要亚秒级重复调度（如每 500ms 采样一次），
OnCalendar不适用，应改用OnUnitActiveSec或外部工具（如sleep循环 +systemd-run --scope）
RealtimeClock=yes 并不能解决精度问题
有些文档建议启用 RealtimeClock=yes 来“使用硬件时钟”，但它只影响 timer 启动时的初始对齐行为（比如开机后第一次触发是否等待到整点），和后续每次触发的精度无关。它甚至可能引入 NTP 调整导致的跳变——例如 NTP 向后校正 1 秒，timer 可能直接跳过一次触发。除非你明确需要跨系统重启保持日历语义对齐（比如每日凌晨 2 点备份），否则不必开启。
真正影响长期稳定性的反而是 Persistent=true：它让 timer 在错过触发时间后（如机器休眠）补跑一次，但这会进一步放大延迟感知——你以为延迟了 2 小时，其实是 timer 在唤醒后立刻“补偿执行”，而非准时执行。
