os.listdir()不可用于可重入批处理，因其返回无序且无时间戳，易致任务重复或遗漏；应改用os.scandir()获取DirEntry对象，直接读取mtime并加1秒缓冲筛选新文件。
为什么 os.listdir() 不能直接用于可重入批处理
因为它的返回结果无序且不带时间戳，同一目录多次执行可能拿到不同顺序的文件，导致任务重复或跳过。更关键的是，它无法区分“刚写完的文件”和“上一轮残留的未处理文件”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 改用
os.scandir()，它返回DirEntry对象，可直接访问entry.stat().st_mtime和entry.name，避免二次os.stat()调用 - 按修改时间升序遍历，并加 1 秒缓冲（例如只处理
mtime 的文件），防写入未落盘 - 跳过以
.tmp、~或.swp结尾的文件名，这些往往是编辑器或程序未完成写入的中间态
concurrent.futures.ThreadPoolExecutor 在批处理中如何避免状态污染
多线程共享内存，如果任务函数里用了模块级变量、全局字典或类静态属性，不同批次之间会互相干扰——比如上一批没清空的 processed_files 列表，下一批直接复用，就变成“假重入”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 所有中间状态必须绑定到单次任务的局部作用域，例如把文件路径传进函数，由函数内部打开、处理、关闭，不依赖外部缓存
- 禁用
functools.lru_cache或自定义缓存装饰器，除非明确设了maxsize=0或按批次 ID 隔离 key - 若必须共享资源（如数据库连接池），确保使用线程安全的封装，例如
threading.local()实例做连接句柄隔离
如何用 sqlite3 做轻量级可重入锁而非文件锁
文件锁（flock）在 NFS 或容器挂载卷上不可靠；而用临时文件标记“正在处理”又容易因崩溃残留，导致后续批次永远卡住。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 建一张
task_lock表，字段为job_id TEXT PRIMARY KEY, acquired_at REAL, pid INTEGER - 获取锁用
INSERT OR IGNORE INTO task_lock VALUES (?, ?, ?)，成功即获得锁；失败说明已有同 job_id 在跑 - 每次任务结束前执行
DELETE FROM task_lock WHERE job_id = ? AND pid = ?，并用PRAGMA journal_mode = WAL提升并发安全
重试逻辑里最常被忽略的幂等性破环点
不是所有“重试”都真正可重入。比如调用一次 shutil.move(src, dst) 成功后，第二次再调这个语句会报 FileNotFoundError 或静默覆盖，取决于 dst 是否已存在。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 移动前先检查
os.path.exists(dst)，存在则跳过；或者统一用shutil.copy2()+os.remove()分两步，失败时也容易回滚 - 对外部服务的调用（如 HTTP 请求）必须带唯一
idempotency-key请求头，并在服务端实现幂等判断 - 日志记录要包含原始输入哈希（如
hashlib.md5(json.dumps(input_data).encode()).hexdigest()），方便排查是否真重复执行
可重入真正的难点不在“怎么启动”，而在“怎么确认上一次确实结束了”。很多问题出在状态边界模糊——比如认为文件移动完成就算任务结束，却忽略了重命名系统调用也可能被信号中断。得把“完成”的定义落到原子操作上，而不是人眼可见的结果。
