ShedLock注解未生效的根本原因是@SchedulerLock方法未被Spring AOP代理——必须为public方法，且不能在同类中被非调度方法直接调用；@EnableSchedulerLock需显式设置proxyMode=PROXY_METHOD，同时确保LockProvider Bean正确注册、共享存储（如Redis或shedlock表）可用且配置无误。
ShedLock 注解没生效，任务还是重复跑
根本原因通常是 @SchedulerLock 方法没被 Spring AOP 代理到——它必须是 public 方法，且不能在同一个类里被其他非调度方法直接调用（否则绕过代理）。@EnableSchedulerLock 的 proxyMode 必须显式设为 SchedulerLock.ProxyMode.PROXY_METHOD，否则默认的 PROXY_TARGET_CLASS 在某些 JDK 版本或 Lombok 场景下会失效。
检查点列表：
-
@Scheduled和@SchedulerLock必须同时加在同一个 public 方法上，不能拆开 - 方法不能是 static、private 或 final；Lombok 的
@SneakyThrows无影响，但@Accessors(chain = true)不影响代理 - 确保
LockProviderBean 已正确注册，且底层存储（如 Redis）可连通——ShedLock 拿不到锁时静默跳过，不会报错 - 日志里搜
Could not acquire lock或Skipping execution，确认是否真在抢锁
flock 在多容器场景下完全失效
flock 是基于文件系统 inode 的锁，Docker 多副本、K8s 多 Pod、甚至同一主机上不同用户运行的 cron 进程，看到的都不是同一个文件句柄。你写 /tmp/myjob.lock，每个容器里都是独立挂载的 /tmp，锁形同虚设。
真正能跨实例起作用的只有外部共享存储：
- Redis：用
SET key value NX PX 30000+ Lua 安全释放，value 必须唯一（如host:pid:timestamp） - 数据库：建
shedlock表，靠唯一索引 + INSERT IGNORE 或 SELECT FOR UPDATE 实现抢占 - ZooKeeper / etcd：利用临时顺序节点和 Watch 机制，适合强一致性要求场景
别试图用 NFS 共享 /tmp 来“修复” flock——NFS 的缓存和锁语义不可靠，实测容易出现假死锁。
lockAtMostFor 和 lockAtLeastFor 参数反直觉
这两个参数不是“最多等多久”“至少等多久”，而是控制锁本身的生命周期：
-
lockAtMostFor（或lockAtMostForString）：锁的绝对过期时间，比如设成"PT30S"，30 秒后无论任务是否结束，锁自动释放。这是防止单点崩溃导致全局阻塞的保险阀 -
lockAtLeastFor（或lockAtLeastForString）：锁的最小持有时间，比如设成"PT5S"，即使任务 1 秒就跑完，锁也得挂满 5 秒，避免高频任务反复争抢
典型误配：lockAtMostFor = "PT5S" 且任务平均耗时 8 秒 → 锁提前释放，其他实例趁机插入执行；lockAtLeastFor = "PT10S" 但 cron 间隔是 5 秒 → 任务永远被跳过。
Spring Boot 启动时没加载 ShedLock 配置
常见漏点：只加了依赖和注解，但没配 LockProvider Bean。ShedLock 不会自动 fallback 到“无锁模式”，而是直接跳过锁逻辑——表现就是“好像没加锁”，其实根本没初始化成功。
以 Redis 为例，必须提供：
@Configuration
public class ShedLockConfig {
@Bean
public LockProvider lockProvider(RedisConnectionFactory factory) {
return new RedisLockProvider(factory);
}
}
如果用 JDBC，要额外建表、注入 DataSource，且表名必须是 shedlock（大小写敏感，MySQL 默认小写），字段名不能改。表结构缺失或字段类型不匹配（比如 lock_until 不是 TIMESTAMP(3)），ShedLock 会静默失败。
