项目标题: thinkphp5结合Workerman的定时器实现定时任务在某一时间执行
写这篇文章的人，十有八九都经历过这样的场景：用户下单后超过30分钟未支付，订单要自动关闭；某场秒杀活动在某个整点准时开始；会员到期后当晚凌晨自动重置状态。你用Crontab写好了脚本，结果发现时间粒度只能精确到分钟，秒级的「到点触发」根本做不到。或者你干脆在请求里sleep轮询，结果把PHP-FPM的进程给活活拖垮了。
我前几年也在某个电商项目里撞上这类需求，试了一圈方案后，最终选了ThinkPHP5结合Workerman的Timer定时器来做。这套方案的核心思路不复杂：让Workerman作为常驻进程常驻内存，由它内部的事件循环帮你盯着时间，到点就触发回调。ThinkPHP5则负责业务逻辑和模型层，两者通过一个入口脚本桥接起来。今天把这套实现从头到尾拆开写清楚，包含完整的代码、延迟秒数的计算方式、防重复执行的细节，以及我踩过的坑。
1. 场景还原与方案选型
1.1 为什么会需要“到点执行”的定时需求
首先要搞清楚一个概念：传统Linux Crontab其实解决的是「周期性任务」，最小粒度是分钟，而且它触发的是另一个独立进程。如果你有秒级任务、精确到某一时刻执行某个业务动作、或者任务执行结果需要写回当前系统数据库，Crontab用起来就很别扭。
最常见的例子：订单未支付自动关闭。用户下单时间是21:30:45，你希望21:45:00之后检查一次，但如果Crontab配置成每分钟执行，你最多只能做到「每分钟检查一次哪些订单超时了」。数据量小还可以，但如果你的数据库里积累了上百万订单，每分钟全表扫描一次未支付订单，这开销想想都可怕。
更好的做法是：下单时精确计算「该订单应该在哪个时间点被处理」，到点后只处理那一条订单。这种单点触达的需求，Crontab做不到，需要的是「延迟任务调度」，而Workerman的Timer::add一次性定时器正好是干这个的。
1.2 为什么用Workerman而不是Swoole
同类型常驻内存方案里，Swoole是绕不开的对比对象。我的选择理由比较实际：
- 团队维护成本：Workerman纯PHP实现，没有Zend扩展，出问题下载源码就能看；Swoole是C扩展，二次排查门槛高。
- 与ThinkPHP5的贴合度：官方生态里有
topthink/think-worker扩展包，虽然功能不算花哨，但胜在稳定，能直接把Timer嵌进Worker生命周期。 - 部署简单：一个
php start.php start就起来了，不需要改PHP运行模式。 - 内存和性能：对定时任务这个场景，Workerman的事件驱动模型完全够用，没有必要为一个Cron调度器引入更重的运行时。
Swoole绝对不是不好，但在「TP5框架下做一个到点触发的定时任务」这个具体场景里，Workerman是性价比最高的解法。
1.3 Timer定时器与Crontab的本质差别
Crontab是操作系统层的调度器，它做的事是「到了时间，启动一个进程执行命令」。每次执行都是独立进程，PHP代码里的静态变量、数据库连接池状态全部清零，执行完进程销毁。
Workerman的Timer则运行在常驻进程内部。它由事件循环统一调度，本质上是「在进程的内存空间内，到点后调用一个回调函数」。这带来了几个关键差别：
- 状态共享：同一个进程内的静态变量、内存缓存，定时任务和业务代码能共享。
- 启动开销：没有重新拉起进程的过程，回调直接执行，纳秒级响应的前提。
- 秒级精度：Timer的调度基于事件循环内部的时间计算，秒、毫秒级别都能支持。
- 生命周期绑定：Worker进程停了，定时器就没了；Worker重启，定时器重新注册。
理解了这个差别，后面写代码时的很多坑就能提前规避。比如：定时器是注册在进程内的，进程挂了任务就丢了；再比如：多进程模式下每个进程都会注册一份定时器，任务会重复执行。
2. 环境准备与依赖安装
2.1 确认PHP扩展、安装Workerman
Workerman在Linux环境运行需要两个关键扩展：pcntl和posix。Windows下只支持单进程且部分功能不可用，所以现在的生产环境基本都是跑在Linux上。
检查扩展是否可用，命令行直接敲：
php -m | grep -E "pcntl|posix"如果没输出，需要先安装。以最常见的CentOS为例：
yum install php-pcntl php-posix # 或者如果是编译安装的PHP cd /usr/local/src/php-7.x.x/ext/pcntl phpize ./configure --with-php-config=/usr/local/php/bin/php-config make && make install安装完别忘了在php.ini里加上extension=pcntl.so，然后重启PHP-FPM或验证CLI模式。
依赖安装我用的是Composer，在项目根目录直接：
composer require workerman/workerman这里要注意版本。Workerman 4.x和3.x的API在Timer上差异不大，但在Worker事件上有些调整。如果项目是ThinkPHP5.x，我建议锁定workerman/workerman:^3.5，因为官方topthink/think-worker的1.x版本对Workerman 3.x兼容性最稳。
2.2 安装think-worker扩展（或手工桥接）
ThinkPHP5官方提供了一个专用扩展topthink/think-worker：
composer require topthink/think-worker安装完成后，框架里会多出几个命令。最常用的启动命令是：
php think worker:server这个命令本质上就是启动了一个Workerman Worker，并且把ThinkPHP5的应用容器加载到了Worker进程中。这样你在定时任务回调里写业务，可以直接用TP5的门面（think\Db、think\Cache、模型等）。
如果你不想依赖这个扩展，也可以手工桥接，后面第4章我会给出完整的启动脚本。但如果你是第一次做这个方案，强烈建议先用官方扩展把链路跑通，再考虑手工桥接。
2.3 最小化启动脚本的结构
不管用不用官方扩展，启动流程的内核是不变的。先定义一个普通的Worker，然后在onWorkerStart事件里注册定时器：
// start.php require_once __DIR__ . '/vendor/autoload.php'; use Workerman\Worker; use Workerman\Timer; $worker = new Worker(); $worker->count = 1; $worker->onWorkerStart = function ($worker) { // 在这里注册定时任务 }; Worker::runAll();配置文件里默认$worker->count = 1，这个很关键。如果你开了多个进程，每个进程都会触发onWorkerStart，定时器就会被重复注册，任务会执行多次。后面第4章专门讲如何规避。
3. 定时器核心原理与延迟计算
3.1 Timer::add四个参数逐一拆解
Workerman的Timer::add方法签名如下：
Timer::add(float $time_interval, callable $callback, array $args = [], bool $persistent = true)四个参数分别解释：
$time_interval：定时器的间隔时间，单位是秒，可以是小数。比如0.5表示半秒。对于一次性定时任务，这里传的是「从现在到目标时刻的秒数差」。$callback：到点后要执行的回调函数。$args：回调函数接收的参数数组，会按顺序传给回调函数。$persistent：是否持久执行。true表示每隔$time_interval秒执行一次，类似setInterval；false表示只执行一次就销毁，类似setTimeout。
这个第四个参数就是实现「到点执行」的关键。想要任务只触发一次，$persistent必须传false。
官方文档里还有一种写法是用Timer::del手动删除定时器，但一次性定时器会在回调执行后自动从事件循环中移除，没必要再手动删一遍。
3.2 一次性定时器的两个注意点
第一个注意点：$time_interval如果传的是0或负数，定时器会立即触发。这不是问题，但你要知道这个特性。在动态注册定时器时，如果目标时间已经过去，回调会立刻执行，这有时不是你想要的，需要加判断。
第二个注意点：一次性定时器执行完之后，它会从定时器列表中移除，但这个Worker进程并不会退出，还会继续监听事件。也就是说，定时器只是「在该执行的任务」，不是「整个进程的寿终正寝」。我在早期接触Workerman时一直以为Timer::add(..., false)执行完进程会退出，其实完全不是这么回事。如果你的应用就只有这一个定时任务，执行完进程就干瞪眼，这没问题；但如果还有别的任务，它们会继续正常调度。
3.3 目标时间与当前时间的秒数差计算
定时器需要的是「延迟多少秒后执行」，而业务需求通常给的是「某个具体时间点」。所以核心动作就是做一次减法：
$targetTime = strtotime('2025-01-20 10:00:00'); $currentTime = time(); $delay = $targetTime - $currentTime; if ($delay > 0) { $timerId = Timer::add($delay, function () { // 到点执行 }, [], false); } else { // 目标时间已过，根据业务决定是立即执行还是丢弃 }如果目标是当天某个固定时刻（比如每天上午10点），可以用mktime来构造：
$targetTime = mktime(10, 0, 0, date('m'), date('d'), date('Y')); $delay = $targetTime - time();这里有个非常容易被忽略的坑：date()函数和strtotime()依赖的是PHP默认时区。如果服务器时区是UTC，而业务时区是北京时间，计算出来的延迟秒数会整整偏差8小时。所以在任务进程的开始处，一定要显式配置：
date_default_timezone_set('Asia/Shanghai');或者在你的ThinkPHP5配置app.default_timezone里已经设置了也一样，但Workerman命令行进程不会经过HTTP入口，所以这个配置必须在启动脚本里再强调一次。
4. 完整实现：ThinkPHP5 + Workerman 定时任务
4.1 编写启动Worker入口脚本
我不太推荐一上来就依赖think-worker的封装，因为一旦出了问题，你不知道是扩展的问题还是自己代码的问题。先手工桥接一遍，整个流程就彻底通了。
在项目根目录建一个timer.php脚本：
<?php /** * 定时任务启动脚本 * 用法: php timer.php start * 停止: php timer.php stop * 重载: php timer.php reload */ require_once __DIR__ . '/thinkphp/base.php'; require_once __DIR__ . '/thinkphp/library/think/Loader.php'; use think\Loader; use think\Config; use Workerman\Worker; use Workerman\Timer; // 注册TP5自动加载 Loader::register(); // 加载应用配置，保证时区、数据库连接等配置生效 Config::load(__DIR__ . '/application/config.php'); // 显式设定时区，避免strtotime计算偏差 date_default_timezone_set(Config::get('default_timezone')); // 创建Worker，监听tcp端口，这里端口随便填一个不影响业务的 $worker = new Worker('tcp://0.0.0.0:8686'); $worker->count = 1; $worker->name = 'Tp5TimerWorker'; $worker->onWorkerStart = function ($worker) { // 注册各类到点任务 registerDelayTasks(); registerDailyTasks(); }; Worker::runAll();这个脚本里有一个我特别强调的点：必须require_once thinkphp/base.php并注册加载器，否则你在定时任务回调里没法用TP5的模型、Db门面和配置项。很多人卡在这一步，原因就是只加载了Composer的autoload，没把TP5框架本身拉进来。
4.2 在onWorkerStart中注册到点任务
在onWorkerStart里，我们注册两类任务：一类是从数据库里读出来的「延迟任务」（比如订单关闭），另一类是固定的「每日任务」（比如凌晨重置）。
注册延迟任务的逻辑通常是：
function registerDelayTasks() { // 从数据库待执行任务表中读取未执行的任务列表 $tasks = \think\Db::name('async_task') ->where('status', 0) ->where('execute_time', '>', time()) ->limit(100) ->select(); foreach ($tasks as $task) { $delay = $task['execute_time'] - time(); if ($delay <= 0) { continue; } Timer::add($delay, function () use ($task) { executeTask($task); }, [], false); } }看到了没？每隔一段时间，这个Worker会去数据库里捞一遍未来要执行的任务，为每一条注册一个一次性定时器。
这里有个问题：任务表里可能随时会有新任务进来，但onWorkerStart只在进程启动时执行一次，新任务不会被加载。解决方案有三个：
- 方案一：往Worker进程内写一个
addTimerTask方法，业务代码里通过TCP或内部通信接口动态注册。复杂，但实时性最好。 - 方案二：写一个单独的「调度器」定时器，每秒检查一次数据库里有没有新的待执行任务，有就马上注册定时器。实现简单，多消耗一点数据库查询。
- 方案三：干脆不用一次性定时器，而是用持久化的秒级定时器「每秒钟轮询一次任务表，把到期的任务拉出来执行」。这个我在第5章详细讲。
实际项目里，方案三最稳定，也最好理解。因为一次性定时器是「时间到了就执行回调」，但如果你在回调里做的是网络请求或数据库操作，这次执行可能瞬间就过了。而秒级轮询则天然支持「把当前时刻所有到期任务批量取出来处理」，容错率高很多。
4.3 在任务回调中调用TP5的业务代码
定时器回调里怎么执行TP5的模型方法，很多人会在这里卡一下。以关闭未支付订单为例：
function executeTask($task) { try { // 记录执行日志，保存到数据库 \think\Db::name('task_log')->insert([ 'task_id' => $task['id'], 'status' => 1, 'execute_time' => date('Y-m-d H:i:s'), 'created_at' => date('Y-m-d H:i:s'), ]); // 根据任务类型分发处理 switch ($task['type']) { case 'close_order': $orderId = $task['params']; \think\Db::name('order') ->where('id', $orderId) ->where('status', 1) // 仅关闭待支付的 ->update(['status' => 4, 'update_time' => date('Y-m-d H:i:s')]); break; // 其他类型... } } catch (\Throwable $e) { // 记录失败日志 \think\Db::name('task_fail_log')->insert([ 'task_id' => $task['id'], 'error' => $e->getMessage(), 'created_at' => date('Y-m-d H:i:s'), ]); } }这里有一个细节：如果你用了TP5的Db::name()门面，要确保在Worker启动时已经初始化了数据库连接。Workerman的onWorkerStart里，框架已经加载完毕，Db的门面会惰性创建连接，所以问题不大。但有一点要小心：Workerman是常驻进程，一个进程里的PDO连接会一直保存，如果数据库做了断连（比如MySQL的wait_timeout），这个连接会变成死连接。TP5的Db在使用时会Ping一下连接，一般能自动重连，但还是要留意日志里有没有SQLSTATE[HY000]这类报错。
4.4 多进程防重复执行处理
如果我们把$worker->count设置成2以上，会发生什么？每个子进程都会执行onWorkerStart，都会注册一遍定时器。假设你注册了10个一次性任务，每个进程都注册一次，结果就是同一个任务被执行了count次。
解决办法有很多，我推荐两种：
最简单的一种是：限制$worker->count = 1。如果你的定时任务量级不大，单进程完全够用。PHP本身是单线程的，但回调执行很快，1000个定时任务都够跑。
另一种是用Redis加锁：
$worker->onWorkerStart = function ($worker) { if ($worker->id === 0) { // 只有第一个进程才注册定时任务 registerAllTimers(); } };这种写法可以配合多进程跑，确保只有ID为0的进程会注册定时器。进程重启时依然只有id=0的进程执行注册逻辑，不会重复。
如果你的服务器需要高可用、希望一个进程挂了另一个补上，那就不能简单用id === 0了，需要引入真正的分布式锁。但说句实在话，对绝大多数定时任务场景，单进程已经足够稳定，Workerman单进程能支撑上千个定时器同时工作，瓶颈在数据库不在进程数。
5. 进阶：用排队机制处理多条“到点任务”
5.1 一次性延迟任务的任务表设计
定时器好在时间精确，但它的缺点是「任务在内存里」。如果Worker重启，所有未执行的一次性定时器全部丢失。所以真正可靠的做法是：把任务持久化到数据库，Worker启动时把未完成任务重新捞出来注册，执行完标记完成。
推荐的表结构如下：
CREATE TABLE `async_task` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `type` varchar(50) NOT NULL DEFAULT '' COMMENT '任务类型', `params` text COMMENT '任务参数，JSON格式', `execute_time` int(11) NOT NULL COMMENT '目标执行时间戳', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待执行 1执行中 2已完成 3失败', `retry_count` tinyint(4) NOT NULL DEFAULT '0' COMMENT '已重试次数', `created_at` int(11) NOT NULL DEFAULT '0', `updated_at` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), KEY `idx_status_time` (`status`, `execute_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;下单后30分钟未支付关闭订单的做法就变成了：
// 用户下单时 \think\Db::name('async_task')->insert([ 'type' => 'close_order', 'params' => json_encode(['order_id' => $orderId]), 'execute_time' => time() + 1800, 'status' => 0, 'created_at' => time(), 'updated_at' => time(), ]);Worker启动时读一次表，把待执行任务全部注册成一次性定时器：
function loadPendingTasks() { $tasks = \think\Db::name('async_task') ->where('status', 0) ->where('execute_time', '>', time()) ->select(); foreach ($tasks as $task) { $delay = $task['execute_time'] - time(); Timer::add($delay, function () use ($task) { executeTask($task); }, [], false); } }5.2 每秒轮询+到期触发
上一种方式的问题是：重要任务如果因为Worker重启而丢失，就要靠启动时重新加载来弥补。但如果任务是在「上次加载之后才入库」的呢？进程不会主动感知新任务。
更稳健的方案是：把一次性定时器作为「调度器」，让它每秒触发一次，轮询任务表：把execute_time小于等于当前时间、status=0的任务全部取出来，标记为执行中，然后逐条执行。
function startScheduler() { Timer::add(1, function () { $now = time(); $tasks = \think\Db::name('async_task') ->where('status', 0) ->where('execute_time', '<=', $now) ->order('execute_time asc') ->limit(50) ->select(); foreach ($tasks as $task) { // 先标记为执行中，防止其他进程重复执行 $updated = \think\Db::name('async_task') ->where('id', $task['id']) ->where('status', 0) ->update(['status' => 1, 'updated_at' => time()]); if ($updated) { // 拿到锁的任务才执行 executeTask($task); } } }, [], true); }这里用到「乐观锁」的思想：update ... where status = 0，如果影响行数为0，说明任务已经被别的进程抢走了，这个进程直接跳过。这个方案的好处：
- 不依赖一次性定时器的内存生命周期。
- Worker崩溃重启后，未完成任务还在表里，新进程起来后继续调度。
- 支持多进程同时跑，用数据库条件天然做了互斥。
- 批量处理能力上限高，哪怕有10万个任务积压，也能每秒钟处理一批。
缺点是：轮询频率是1秒，所以「到点执行」的精度是秒级。对绝大多数业务场景（订单关闭、会员到期、活动开始）来说，一秒的误差完全能接受。
5.3 任务失败重试与执行记录
轮询方案确定后，还要考虑失败重试。我的习惯是：执行任务时用try/catch捕获异常，失败后不直接置为失败状态，而是把retry_count加1。如果重试次数小于等于3，就放到下一次轮询继续执行，同时把execute_time设置为当前时间延迟一段时间（比如time() + 5 * $retry_count），实现退避重试。如果重试次数超过3，状态置为3（失败），留待人工处理。
代码大致这样：
function executeTask($task) { try { // 业务处理... \think\Db::name('async_task') ->where('id', $task['id']) ->update(['status' => 2, 'updated_at' => time()]); } catch (\Throwable $e) { $retryCount = $task['retry_count'] + 1; if ($retryCount > 3) { \think\Db::name('async_task') ->where('id', $task['id']) ->update(['status' => 3, 'updated_at' => time()]); } else { \think\Db::name('async_task') ->where('id', $task['id']) ->update([ 'retry_count' => $retryCount, 'execute_time' => time() + 10 * $retryCount, 'status' => 0, 'updated_at' => time(), ]); } } }这里有个细节：任务表里的execute_time在重试时被改成了未来时间，所以下一轮调度只会捞到重新到期的任务，不会重复堆积。而且因为重试次数增加了退避间隔，避免频繁失败的任务把资源耗尽。
6. 常见问题与排查技巧实录
6.1 定时器不触发的排查清单
这是新手最常见的痛苦经历：代码写了，Worker起来了，日志打印了「start」，但定时器就是不执行。排查思路按顺序来：
第一，确认命令行执行的是php timer.php start而不是php timer.php。Workerman裸跑如果没有参数，默认会启动但不会进入监听，需要显式传入start命令。
第二，确认Worker进程真的活着：ps aux | grep timer.php。如果进程退出了，大概率是代码里出现了致命错误，比如TP5加载失败。用php timer.php start直接看终端输出，不要用daemon模式。
第三，确认onWorkerStart里的代码真的执行到了。在回调里加一行file_put_contents在/tmp目录，每次Worker启动都写日志，确认事件触发。
第四，检查你注册的是持久定时器还是一次性定时器。如果Timer::add的第四个参数传了true，而且delay秒数早就过了，这个定时器会每秒钟疯狂执行回调，日志都会被刷爆。反过来，如果传了false且delay是未来时间，那它就会老老实实等时间。
第五，检查回调内部是否有exit或die。一旦在Workerman的回调里调用了exit，整个Worker进程会直接崩溃退出，后面的所有定时器全部失效。这是Workerman的大忌，任何代码路径上都不能出现exit。
6.2 时间偏差与服务器时区问题
前面提到过时区问题，这里再补充一个典型场景。我遇到过一台部署在境外区域的服务器，系统时区是UTC，而业务库里存的时间都是北京时间。任务回调里用date('Y-m-d H:i:s')直接写数据库，所有日志时间看起来都慢了8小时，定位问题时就非常迷惑。
解决办法是双管齐下：
- 在启动脚本开头设置
date_default_timezone_set('Asia/Shanghai')。 - 在ThinkPHP5的
config.php里也把'default_timezone' => 'Asia/Shanghai'配置好，并确保数据库连接时间也是同一个时区。
另外，如果服务器时间本身和标准时间有偏差，可以使用NTP同步。长时间运行的服务器，时间漂移可能达到几十秒，对严格到点执行的定时任务会有影响。我一般是配置crontab每5分钟同步一次NTP时间。
6.3 长驻进程内存增长与平滑重启
Workerman是常驻进程，PHP的内存不会自动释放得像传统PHP-FPM每次请求后那么彻底。如果一个回调里循环处理了10万条数据，或者某个类里有静态数组不断累积数据，进程内存会慢慢上涨。
解决思路：
- 在回调函数里，大数组处理完毕尽量
unset，并手动gc_collect_cycles()。 - 用Workerman自带的
--daemon运行时，配合--reload重载代码，不影响业务中断。 - 在部署脚本里写一个守护脚本，监控Worker进程的RSS内存，超过阈值就执行
php timer.php reload，平滑重启。
Workerman的reload实际上是逐个重启子进程，主进程不退出，所以在定时任务场景下用是安全的。不过要注意：如果你的定时器是在onWorkerStart里注册的，重启后会自动重新注册，未执行的数据库任务也会重新捞出来，所以不会有任务丢失问题。
我把内存监控脚本写成这样：
#!/bin/bash PID=$(cat timer.pid) RSS=$(ps -p $PID -o rss --no-headers) if [ "$RSS" -gt "262144" ]; then php timer.php reload fiRSS单位是KB，262144表示256MB。可以根据任务负载调整阈值。
6.4 任务执行缓慢阻塞后续定时器
Workerman的单进程模式下，定时器回调是串行执行的：如果第一个定时器回调里有个file_get_contents远程请求，超时时间设置了60秒，那么后面所有的定时器都会在这60秒内被阻塞，无法按时执行。
解决办法是把耗时任务转移出主进程。Workerman提供了Workerman\Lib\Timer之外的另一套机制，就是Worker进程池。你可以专门开一组干活Worker，定时器只管把任务推给它们，不阻塞主事件循环。
use Workerman\Worker; use Workerman\Connection\TcpConnection; // 任务消费进程 $taskWorker = new Worker(); $taskWorker->count = 4; $taskWorker->name = 'TaskConsumer'; $taskWorker->onMessage = function (TcpConnection $connection, $data) { // 在这里异步处理耗时任务 $connection->send('done'); }; // 在onWorkerStart里把这个taskWorker的通信端口暴露给定时器不过这套机制稍微复杂，如果你的任务本身只是几条SQL操作，完全不必上进程池。只有任务里包含远程HTTP请求、文件处理或者其他IO密集操作时，才建议把任务拆出去。
7. 项目落地后的运维经验
7.1 日志是定时任务的“第一盘录像带”
定时任务不像Web请求，有Nginx或Apache帮你记一条访问日志。Workerman跑在命令行，所有输出都进入stdout，如果不加处理，重启后日志就找不回来了。
我的习惯是，启动脚本用--daemon跑，然后额外写一个简单的日志类，在任务开始、成功、失败时分别写入不同的日志文件。日志里必须包含：定时任务的类名、任务ID、触发时间、执行耗时、错误信息。
日志文件建议按天切割，保留30天就够了。定时任务这种低频操作的日志量不会很大，但排查问题时没有日志会非常被动。
7.2 部署时注意防火墙与端口占用
Workerman需要监听一个TCP端口，如果端口被占用，启动会直接失败。检查端口占用用：
ss -lntp | grep 8686端口本身不对外暴露的话，建议在防火墙里把端口限制成仅本机访问，或者干脆监听内网IP：tcp://127.0.0.1:8686。这样既避免端口扫描攻击，也不影响功能。
7.3 与ThinkPHP5路由和中间件的关系
很多人担心：在Workerman里调用TP5的模型、Service、门面时，会不会触发路由和中间件？我的理解是：不必担心。think\Db、模型、门面这些是底层ORM，和路由中间件完全无关。你在定时任务里写\think\Db::name('order')，走的是数据库访问层，不会经过控制器分发，也不会有鉴权中间件插手。所以定时任务里可以直接操作数据库，但要自己写好权限校验，因为没有人帮你鉴权。
我遇到的一个问题是：TP5的模型事件（比如模型写入时的autoWriteTimestamp）在命令行环境下会照常触发，所以写入时间和HTTP请求下的表现一致，这个不用特判。
7.4 定时任务与业务代码分离
最后一个提醒：不要把定时任务的业务逻辑直接写在onWorkerStart里，那样代码很快会变成一坨屎。我的目录结构是这样分割的：
application/ ├── timer/ │ ├── scheduler.php // 调度器入口，负责注册定时器 │ ├── tasks/ │ │ ├── CloseOrderTask.php │ │ ├── ResetMemberTask.php │ │ └── SendNoticeTask.php │ └── logger.php // 任务日志处理每个任务类都实现一个handle($task)方法，调度器只负责分发，任务类自己处理参数解析和业务逻辑。这样每增加一个定时任务，只需要新增一个任务类，不需要动调度器代码。
记得在一个任务里处理完订单关闭，顺手把相关用户的通知消息也一并写入消息表，这样定时任务和非定时业务能很好地接力协作。
这套方案我在实际项目中运行了大半年，稳定性没问题，线上几万条延迟任务跑下来，时间偏差在可接受范围内，极少出现丢任务的情况。如果你也需要在ThinkPHP5里实现某个时刻的定时任务，Workerman这套方案值得参考。最后再分享一个小技巧：任务回调里尽量把所有异常都catch住，并且记录下来，这样即使某个任务反复失败，整个Worker进程依然能稳定运行，不会因为一条脏数据把整个调度器搞崩。
