构造代码块不适合做全局唯一ID注入，因为它每次new对象都执行、无上下文访问能力、不线程安全；应改用Redis原子自增+时间戳生成63位结构化ID，并在请求入口通过Redis NX指令实现防重。
构造代码块本身不能直接用于注入全局唯一序列号或做防重处理，它只是 Java 类初始化阶段的一部分，执行时机早、无参数、无法访问外部上下文（如 Spring 容器、Redis 连接），也不具备线程安全控制能力。真正可行的方案是把“生成唯一 ID”和“防重校验”逻辑放在业务入口处，用合适机制支撑，构造代码块仅适合做轻量、无依赖、单例内部的静态初始化。
为什么构造代码块不适合做全局唯一 ID 注入
构造代码块在每次 new 对象时执行，不是单例专属；它无法感知请求上下文、无法调用 Redis 或数据库、不能加锁或设过期时间。若强行在其中调用 INCR 或生成时间戳+序列号，会导致：
- 每次新建对象都触发一次 ID 生成，ID 被浪费且不可控
- 多线程并发 new 对象时，序列号生成逻辑若未同步，仍可能重复
- 无法绑定请求生命周期，做不到“一次请求一个 ID，用完即失效”
真正可用的全局唯一序列号生成方式
应使用线程安全、可扩展、带时间维度的结构化 ID 方案，例如基于 Redis 的自增 + 时间戳拼接：
- 用
INCR key获取每秒内单调递增的序列号（Redis 天然原子） - 取当前秒级时间戳（31 位），左移 32 位后与序列号按位或，组成 63 位 long 型 ID
- 高位为 0（符号位），保证正数；含时间信息，便于问题追溯
- 该 ID 可作为业务主键、幂等键或请求唯一标识，写入数据库前先存入 Redis 并设 TTL（如 5 分钟）
防重处理必须结合请求标识与状态存储
防重不是靠对象构造，而是靠请求粒度的状态管理：
- 客户端提交时携带唯一请求 ID（如前端生成 UUID 或服务端下发 token）
- 服务端收到后，用
SET key value EX 300 NX尝试写入 Redis，NX 保证仅首次成功 - 写入失败说明该请求已存在，直接返回重复提示；成功则继续执行业务，并在事务完成后标记完成
- 不依赖构造代码块，而是封装成 AOP 切面或统一网关过滤器，在 Controller 方法执行前拦截校验
如果非要关联到对象初始化，可这样做
仅限于单例 Bean 内部的轻量初始化，比如预热一个本地计数器或加载配置，但不能用于核心防重逻辑：
- 在 Spring 管理的 @Service 类中，用
@PostConstruct替代构造代码块，确保只执行一次 - 初始化一个
AtomicLong作兜底（非分布式场景），或初始化 RedisTemplate 实例引用 - 真正的 ID 生成和防重动作，仍放在具体方法里，例如
createOrder(IdempotentRequest req)中调用idGenerator.next()和idempotencyChecker.check(req.getToken())
