ThinkPHP 8.1 分布式定时任务必须依赖外部协调，禁用多机同配crontab；推荐Redis分布式锁（SETNX+唯一key+Lua安全解锁）或中心化调度平台（如XXL-JOB），辅以数据库唯一约束兜底，杜绝重复执行。
ThinkPHP 8.1 本身不支持分布式定时任务调度，框架内无锁机制、无节点协调能力，若直接在多台服务器上都配置相同 crontab，必然导致同一任务被多个实例同时执行——比如发重复通知、扣双倍库存、清两次缓存。要保证“只执行一次”，核心不是改 TP 代码，而是把调度权交给外部统一协调层。
用分布式锁控制任务入口（最轻量实用）
在 execute() 方法开头加一层原子性校验，确保同一时刻仅一个节点能进入业务逻辑：
- 用 Redis 实现 SETNX + 过期时间：执行前尝试 set key=“task:sync_order:20261022” value=“server-a” ex=3600 nx；失败则直接 return 0（已有人在跑）
- 成功获取锁后，任务结束前主动 del key，或依赖自动过期兜底（防进程崩溃残留）
- 注意：Redis 必须是单点或强一致集群（如 Redis Sentinel 主从切换时可能短暂脑裂，建议用 Redis Cluster 或加二次校验）
由中心化调度器统一下发（推荐中大型项目）
放弃各节点自管 crontab，改用专业调度平台接管“触发权”：
- 部署 XXL-JOB 或 PowerJob，把你的 ThinkPHP 命令封装为 HTTP 接口（如 POST /api/cron/clear-cache）或 Shell 任务（curl -X POST ... 或 ssh user@target php think cron:clear）
- 调度平台负责分片、故障转移、执行记录、失败重试和告警，TP 节点只做纯净执行器
- 优势明显：可动态启停任务、查看历史执行日志、设置执行超时、指定路由到某组服务器（如只让 admin 节点执行报表任务）
利用数据库唯一约束做天然屏障（适合低频关键任务）
对必须幂等且执行频率不高（如每天一次）的任务，用 DB 层兜底：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
- 建一张
cron_execution_log表，字段含 task_name（唯一索引）、exec_date（date）、status - execute() 中先 insert ignore into cron_execution_log (task_name, exec_date, status) values ('cron:send-daily-report', '2026-10-22', 'running')；影响行为 0 则说明当日已执行，直接退出
- 插入成功后再执行主逻辑，完成后 update status = 'success'
- 简单可靠，不依赖额外中间件，但不适合秒级/分钟级高频任务
禁用非中心化方案（避坑提醒）
以下做法在分布式环境下一律不可用：
- 各机器都配相同 crontab —— 必然重复
- 用文件锁（flock）或本地缓存锁 —— 锁只在本机生效，跨机器无效
- 靠配置开关（如 config.php 写 “enable=true”）手动控制某台启用 —— 运维成本高、易出错、无法自动容灾
- think-crontab 或基于 sleep 的轮询脚本 —— 无进程守护、不可靠、不支持分布式
本质上，TP8.1 定时任务的分布式问题，是调度模型问题，不是框架缺陷。选对协调方式，比纠结“TP 怎么改”重要得多。小团队可用 Redis 锁快速落地；业务关键、需审计追踪的，直接上 XXL-JOB 更省心。
