不能用 LIMIT 1 OFFSET 查上下条，因其依赖全局偏移而非逻辑相邻；应以主键或时间戳为锚点，用 WHERE + ORDER BY + LIMIT 1 范围查询，如 where('id', '

为什么不能用 LIMIT 1 OFFSET 直接查上一条或下一条

因为 LIMIT 1 OFFSET 依赖排序和全局位置，而“相邻”是相对于当前记录的值而言的——比如当前 id=100，上一条应该是 id=99（如果存在），不是第 99 条。一旦中间有删除、自增跳号、或按时间排序但主键不连续，OFFSET 就完全失效。

真实场景里，用户点「上一篇」时，期望的是逻辑上最靠近的那条，不是数据库物理顺序里的前一条。

怎么用主键范围查询找上一条（prev）和下一条（next）

核心思路：把“当前记录的主键值”当作锚点，用 WHERE 限定范围 + ORDER BY + LIMIT 1。前提是主键可比较（如整型 id 或时间戳 created_at）。

• 查上一条（比当前小的最大值）：where('id', 'order('id desc')->find()
• 查下一条（比当前大的最小值）：where('id', '>', $currentId)->order('id asc')->find()
• 如果主键是字符串（如 UUID），需确保它支持字典序比较；否则换用时间字段（如 created_at）做锚点
• ThinkPHP 6+ 中，find() 自动加 LIMIT 1，不用手动写

使用 created_at 替代主键时要注意什么

当主键不连续或不可排序（如雪花 ID 字符串），created_at 是更稳妥的锚点，但必须注意：

立即学习“PHP免费学习笔记（深入）”；

• 该字段要有索引，否则查询会变慢——尤其数据量大时
• 同一秒内多条记录？得加二级条件，比如：where('created_at', 'whereOr(['created_at', '
• 时区要统一，避免因 PHP 和数据库时区不一致导致查不到
• ThinkPHP 的 whereTime() 不适合这种精确相邻查询，它生成的是范围条件，容易漏掉边界记录

为什么查不到结果时不能直接返回 null 就完事

查不到 prev/next 很常见（比如已经是第一篇），但业务逻辑常需要区分「真没数据」和「查询条件写错了」：

• 检查是否忘了加索引——执行 EXPLAIN 看 type 是否为 range，key 是否命中索引
• 确认主键类型和变量类型一致：比如数据库 id 是 bigint，但 PHP 传了字符串 '100'，某些版本的 ThinkPHP 会生成错误的 SQL
• 如果用了软删除，记得加 withTrashed() 或提前排除已删除状态，否则看似存在的记录实际查不到
• 调试时可临时打印最终 SQL：$query->buildSql()，看生成的 WHERE 条件是否符合预期

相邻记录看着简单，真正上线后出问题，八成卡在索引缺失、类型隐式转换或软删除干扰上。别省这一步验证。