超时主因是循环内反复建连接、查数据库和写日志，而非循环本身；应改用批量查询（IN 或 BETWEEN）、DateTime 对象递增日期、关闭调试与实时日志。
ThinkPHP 5.1 中两个日期循环（比如按天遍历起止日期 + 每天查数据库）超时，根本不是“循环慢”，而是**在循环里反复建连接、发查询、等响应**——每轮都走完整 HTTP 生命周期或 PDO 连接/释放流程，100 天就是 100 次 round-trip，必然超时。
别在循环里调 Db::table()->where('date', '2026-08-01')->select()
这是最常见也最致命的写法。每次 select() 都会触发一次完整查询：连接复用失败（尤其 CLI 下）、SQL 解析、执行、结果集 fetch、连接归还。哪怕单次 200ms，100 天就是 20 秒，PHP 默认 max_execution_time=30，再加点网络抖动就直接 504。
- 改用批量日期构造 IN 查询：把所有目标日期拼成数组，
Db::name('log')->where('date', 'in', $dateList)->select()，一次查完 - 如果日期跨度大（如跨年）、数据量大，改用时间范围查询：
where('date', 'between', [$start, $end])，配合date字段有索引 - 绝对不要在循环里 new Model() 或重复调用
Db::connect()—— TP5.1 的连接池默认不自动复用 CLI 进程中的长连接，容易新建一堆闲置连接
用 date_create_immutable() + modify() 替代 strtotime() 和字符串拼接
strtotime('+1 day') 在循环中反复调用，内部要解析字符串、校验时区、处理夏令时，性能比原生 DateTime 对象低 3–5 倍。尤其当循环上千次，开销明显。
- 初始化一次：
$date = date_create_immutable('2026-08-01'); - 循环中只做：
$date = $date->modify('+1 day');，返回新对象，无副作用 - 避免
date('Y-m-d', strtotime(...))这种嵌套，直接$date->format('Y-m-d') - 如果只是生成日期列表，用
range()+array_map()也比 while 循环 + strtotime 快
CLI 模式下必须关掉调试、开 opcache、禁用日志实时刷盘
TP5.1 在命令行跑定时任务时，默认仍加载调试组件、开启 trace 日志、每条 Log::info() 都 fwrite() 到磁盘 —— 这些在 Web 请求里不显眼的开销，在长循环里会被放大数十倍。
立即学习“PHP免费学习笔记（深入）”；
- 确保
APP_DEBUG = false，否则think\Debug会全程收集内存和 SQL 耗时，吃光 CPU - 确认
opcache.enable_cli = 1，并执行过php think optimize:autoload，否则类文件反复 require_once - 临时关闭日志写入：
Log::close();或配置日志驱动为'type' => 'test'，避免每轮都触发磁盘 I/O - 如果必须记日志，攒够 10 条再
file_put_contents(..., FILE_APPEND)，别每次Log::write()
真正卡住的从来不是“for 循环本身”，而是循环体内隐式触发的连接、I/O、解析动作。盯住 Db:: 调用和 Log:: 调用，把它们从循环里拎出来，90% 的超时问题就消失了。
