task_id不能仅由客户端传入，因其可伪造、重放或重复提交，必须由服务端生成（如UUIDv4）或结合业务上下文二次校验，并在数据库加唯一约束作为幂等第一道防线。
为什么 task_id 不能只靠客户端传入
因为客户端可伪造、重放或重复提交，单靠传来的 task_id 做去重，等于把幂等性交给了不可信边界。真实任务系统必须在服务端生成或校验唯一性锚点。
实操建议：
- 用服务端生成的
task_id（如 UUIDv4 或基于时间+随机数的组合），避免客户端控制主键 - 若必须接受外部
task_id（如对接第三方系统），需配合业务上下文做二次校验，比如：(task_id, user_id, action_type)联合唯一 - 数据库层面加唯一约束，不是“可选优化”，而是幂等落地的第一道防线 —— 比如 PostgreSQL 的
UNIQUE (task_id)或 MySQL 的唯一索引 - 注意：UUIDv1 含时间戳和 MAC 地址，部分场景有隐私/可预测风险；UUIDv4 更安全，但纯随机不保证全局有序，日志排查略不便
SELECT ... FOR UPDATE 在事务中真能防并发重复执行吗
能，但仅限于同一行被锁住、且所有路径都走同一锁粒度时。漏掉条件、跨表、或锁了 A 行却写 B 行，照样出问题。
常见错误现象：两个请求同时查不到记录 → 都走创建逻辑 → 数据库报唯一冲突 → 其中一个失败 → 但业务已发消息、调远端 API，副作用无法撤回。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 锁必须覆盖整个判断+写入路径，例如：
SELECT * FROM tasks WHERE task_id = %s FOR UPDATE，然后检查是否存在，再 INSERT 或 UPDATE - 不要先
SELECT判断存在性，再另起语句INSERT—— 这中间有竞态窗口 - MySQL 默认是 RR 隔离级别，
SELECT ... FOR UPDATE会加间隙锁，可能引发死锁；PostgreSQL 用行级锁更轻量，但需确保查询带索引，否则升级为表锁 - 如果任务状态流转复杂（如 pending → running → done），建议用状态机 + CAS 更新：
UPDATE tasks SET status = 'running' WHERE task_id = %s AND status = 'pending'，返回影响行数判断是否抢到执行权
Redis 的 SETNX 和 Redlock 哪个更适合任务幂等
95% 的场景用 SETNX 就够了，Redlock 是为跨多个 Redis 实例的强一致性设计的，反而引入延迟和运维负担，对单任务幂等属于过度工程。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
使用场景：需要快速拦截重复请求（比如用户连点提交）、且允许极短时间窗口内（毫秒级）的误判（即两个请求几乎同时过 Redis，其中一个被后续 DB 唯一约束兜底）。
实操建议：
- 用
SET key value EX 300 NX设置带过期的锁，value 必须是随机字符串（如 UUID），避免误删别人设的锁 - 别用
DEL直接删，要用 Lua 脚本比对 value 再删，防止释放了别人的锁 - Redis 故障时，这套机制失效，所以它只是“加速判断”，不能替代 DB 层的最终一致性保障
-
Redlock在 Python 里要用redis-py-cluster或手动轮询多个 client，但任务幂等不需要跨实例强一致 —— 单实例 Redis + DB 最终校验，足够健壮
幂等 Key 设计不当导致“看似成功、实际漏执行”
最典型的坑：用 user_id + timestamp 当幂等 key，结果同一用户一秒内发起两次合法请求，第二个被当成重复直接跳过，但业务上它们处理的是不同数据。
关键点在于：幂等 key 必须反映“操作意图的完全等价”，而不是“操作发起者的粗略标识”。
实操建议：
- 优先用业务自然主键组合，比如：
order_id + action_type（支付订单）、file_hash + convert_format（文件转码） - 避免含时间、随机数、session_id 等易变字段，除非该变化本身就是业务差异点
- 如果请求体大、字段多，可对关键字段做确定性哈希（如
hashlib.sha256(json.dumps(sorted_fields)).hexdigest()[:16]），但要注意浮点数序列化精度、字典 key 顺序等陷阱 - 调试时打日志一定要输出最终计算出的幂等 key，而不是原始参数 —— 很多问题都是 key 计算逻辑和预期不一致，但没人验证过实际值
真正难的从来不是“怎么加锁”或“怎么设 key”，而是想清楚：这一次调用，和上一次，到底是不是同一个“逻辑操作”。这个判断一旦错，后面所有技术手段都在加固错误。
