应将幂等键设为业务ID而非请求体哈希，即提取$orderNo或$data['biz_id']等语义唯一标识，拼接为"idempotent_{$bizId}_{$controller}_{$action}"格式，Redis TTL需按业务生命周期设定（如支付类2小时、发券类1天），校验必须基于Redis原子操作，日志仅作审计且须在Redis成功后写入。
ThinkPHP 接口幂等键怎么设成业务 ID 而不是请求体哈希
直接用 Request::instance()->getContent() 做幂等键会出问题：相同业务逻辑的多次合法请求（比如重试）可能因时间戳、trace_id 等字段不同导致哈希值不一致，去重失效。必须把键从“整个请求”收缩到“业务语义唯一标识”上。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在控制器方法开头，手动提取业务 ID 字段，比如
$orderNo = $this->request->param('order_no')或从 JSON body 解析后取$data['biz_id'] - 幂等键格式统一用
"idempotent_{$bizId}_{$controller}_{$action}"，避免跨接口冲突 - 别依赖框架自动解析的
input()，它可能已触发过参数过滤或类型转换，导致和原始请求不一致 - 如果业务 ID 是加密字符串（如 base64 或 AES 加密），解密后再参与拼键——否则同一业务多次请求解密结果不一致，键就失效
Redis 存幂等键时 TTL 设多少才安全
TTL 太短，用户重试窗口内键过期，重复提交被放过；太长，无效键堆积，占用内存还可能误拦截后续合法请求（比如订单号复用场景）。没有固定值，得按业务生命周期定。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 支付类接口：TTL 至少覆盖「支付渠道回调最大延迟 + 人工干预周期」，通常设
7200（2 小时）起步 - 创建类接口（如发券、下单）：按业务单据状态流转时效定，比如券 24 小时内可核销，TTL 可设
86400（1 天） - 千万别写死
3600全局通用——订单创建和短信发送的幂等周期根本不是一个量级 - 用
SET key value EX 3600 NX命令，而不是先EXISTS再SET，避免竞态
为什么用 Db::name(‘idempotent_log’) 记日志还是漏记录
单纯写数据库日志不能替代 Redis 键判断，因为 DB 写入有延迟、事务回滚、主从同步延迟，会导致「查不到日志 → 认为没提交 → 放行重复请求」。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 日志表只做审计，不做判断依据；所有幂等校验必须走 Redis 的原子操作
- 写日志要放在 Redis 成功 SET 之后、业务逻辑执行之前，且用
try...catch包裹，失败就删掉刚写的 Redis 键（不然键存在但无日志，排查困难） - 字段至少包含：
biz_id、request_id、ip、created_at，别省略request_id，否则无法关联链路追踪 - 表引擎必须是
InnoDB，且biz_id加唯一索引——防并发插入重复，但注意这不能代替 Redis 校验
ThinkPHP 中间件里怎么提前拦截重复请求
把幂等逻辑塞进中间件看似优雅，但容易踩坑：中间件执行时机早于参数绑定，$request->param() 拿不到 POST JSON 字段；而且全局中间件无法区分哪些接口需要幂等，硬加会影响性能。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用闭包中间件或行为扩展，只绑定到具体路由，比如
Route::post('order/create', 'Order/create')->middleware('idempotent:biz_id') - 中间件里用
$request->rawInput()拿原始 body，再json_decode($raw, true)提取业务 ID，别碰input() - 校验失败时，直接
return json(['code' => 409, 'msg' => 'Duplicate request'], 409)，别 throw 异常——异常会走完整错误处理流程，延迟明显 - 别在中间件里做业务逻辑，只做「判重 + 拦截」，业务代码保持干净
业务 ID 的提取位置、Redis 键的拼接粒度、TTL 的业务对齐——这三个点只要一个没对准，幂等就形同虚设。尤其是当接口要对接外部系统时，他们传的「业务 ID」字段名可能随时变，得留好配置项兜底。
