最近在用 ThinkPHP 开发内部清理接口的时候，遇到一个很容易忽略的问题：接口状态码返回 200，但是 data 偶尔是空，明明数据库里存在符合条件的数据。

一开始怀疑是定时任务没触发、curl 请求失败，反复调用接口测试，有时候能查到数据，有时候什么都查不到。

排查步骤：

1. 先打印 sql 语句，把生成的 SQL 拿到数据库工具直接执行，发现 SQL 本身是可以查出数据的，排除查询条件写错。
2. 检查时间条件，代码里用了time()做时间对比，服务器时区和数据库时区不一致，造成时间判断偏移。
3. 再看 chunk 分批查询逻辑，批量循环处理的时候，部分数据在循环内被提前处理，下一批查询就取不到这条记录。

解决办法： 统一服务器和数据库时区，在配置文件里设置 Asia/Shanghai；同时调整清理逻辑，查询和删除分开，避免边查边删带来的数据漏判。

额外注意点：做自动清理类接口，尽量不要在业务高峰期执行，防止锁表影响网站正常访问；每次执行可以简单记录日志，方便后续出问题回溯。

小结：接口返回 200 不代表业务逻辑正常，状态成功只是代表请求通过，数据是否符合预期，一定要打印 SQL、核对时区、检查循环逻辑。

再来一篇备用的，Nginx 主题：

标题：Nginx 反向代理后端超时问题优化笔记

搭建反向代理转发接口的时候，经常遇到请求长时间转圈、最后报 504 Gateway Time-out。

很多新手第一反应是后端程序崩了，其实大多是 Nginx 默认超时参数太短。 默认的 proxy_read_timeout 只有 60 秒，如果后端转存、文件处理耗时比较久，还没处理完，Nginx 直接断开连接抛出 504。

修改方案，在对应 location 代理配置里面增加参数：

proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;

修改后重载 Nginx 配置 nginx -s reload，不用重启服务，不中断在线业务。

坑点提醒：只改 Nginx 还不够，如果 PHP-FPM 的超时时间比 Nginx 更短，依然会报错，需要同步调整 php 的 max_execution_time。

适用场景：网盘转存接口、文件批量处理、耗时较长的后台任务。