ThinkPHP中废弃的查询表达式语法如何重构_使用原生查询构造器-ThinkPHP-PHP中文网

thinkphp 6+ 中 where('id', '>', 10) 报错是因为自6.0起移除了字符串字段名+操作符的隐式语法，要求字段名必须为未加引号的标识符或使用数组三元组形式，以提升安全性与类型明确性。

thinkphp中废弃的查询表达式语法如何重构_使用原生查询构造器

ThinkPHP 6+ 中 `where('id', '>', 10)` 这类字符串字段名写法为什么报错

因为 ThinkPHP 6.0 起彻底移除了对字符串字段名 + 操作符组合的语法支持，where('id', '>', 10) 会被解析为「字段名是字符串字面量 'id'」，而实际字段应是未加引号的标识符。底层 SQL 构造器不再做隐式转换，直接抛出 InvalidArgumentException 或生成错误 SQL。

这不是 bug，是设计上强制显式表达意图——避免字段名被误当值、SQL 注入风险和类型混淆。

必须改用数组三元组：where(['id', '>', 10]) 或链式 where('id', '>', 10)（注意：后者仅在 6.0+ 的 Query 对象中保留，但前提是第一个参数是未引号的字段名，即 where('id', '>', 10) 合法，而 where("'id'", '>', 10) 不合法）
旧项目升级时，全局搜索 where(\s*['"]\w+['"]\s*, 可快速定位问题点
如果字段名含点号或动态拼接（如 'user.status'），必须用数组形式：where(['user.status', '=', 1])，字符串写法会直接解析失败

原生查询构造器里 `whereRaw()` 和 `where()` 混用的边界在哪

whereRaw() 是绕过参数绑定、直插 SQL 片段的“逃生舱口”，但和普通 where() 混用时，执行顺序和绑定上下文容易混乱。

常见错误现象：条件没生效、SQL 报错 Unknown column 'xxx' in 'where clause'、数值被自动加引号变成字符串比较。

不要在 whereRaw() 里写带参数占位符又指望 where() 自动填充：whereRaw('status = ? AND created_at > ?', [1, time()]) 是 OK 的，但 whereRaw('status = ?')->where('id', '>', 10) 中的 ? 不会被后续 where() 捕获
安全前提下优先用 where() 数组形式：where([['status', '=', $status], ['created_at', '>=', $time]])，它自动参数绑定且可读性强
只有真正需要函数、子查询或复杂运算时才用 whereRaw()，例如：whereRaw('DATE(created_at) = CURDATE()') 或 whereRaw('(a + b) > ?', [$threshold])

从 `whereTime()` 这类快捷方法迁移到标准构造器要注意什么

whereTime()、whereBetweenTime() 等是 TP5 提供的语法糖，在 TP6+ 中虽仍存在，但底层已改为调用标准 where()，且部分行为有兼容性调整。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

最常踩的坑是时间格式和时区处理：TP5 默认按 Y-m-d H:i:s 解析字符串，TP6+ 更严格依赖 PHP 的 DateTime 解析逻辑，遇到模糊格式（如 '2023-01-01'）可能被解释为当天 00:00:00 或直接报错。

显式传 DateTime 实例最稳：whereTime('created_at', '>=', new \DateTime('2023-01-01'))
避免传字符串范围：whereBetweenTime('created_at', '2023-01-01', '2023-01-31') → 改成 whereBetween('created_at', [date('Y-m-d 00:00:00', strtotime('2023-01-01')), date('Y-m-d 23:59:59', strtotime('2023-01-31'))])
数据库时区与 PHP 时区不一致时，whereTime() 可能查不到数据；建议统一用 UTC 存储，查询时用 where('created_at', '>=', $utcTime)

重构后性能变慢？检查 `where()` 嵌套层级和索引匹配

把一堆字符串拼接的 where 拆成多个 where() 调用本身不伤性能，但若重构时无意中把本该单次执行的条件拆成多次 where() + or() 组合，就可能触发全表扫描。

典型表现：EXPLAIN 显示 type: ALL，慢查询日志里出现重复 WHERE 条件或冗余括号。

用 where() 数组一次传入多个条件，比链式多次调用更易被优化器识别：where([['a', '=', 1], ['b', '>', 10], ['c', 'like', '%x%']]) 优于 where('a', '=', 1)->where('b', '>', 10)->where('c', 'like', '%x%')（虽结果等价，但部分驱动下解析路径不同）
涉及 OR 时，务必用 where(function ($query) { ... }) 包裹，否则索引大概率失效：where('status', 1)->whereOr(['type' => 2, 'level' => 3]) 不如 where(function ($q) { $q->where('status', 1)->whereOr(['type' => 2, 'level' => 3]); })
字段上有联合索引（如 (user_id, status, created_at)），但 where() 条件顺序不匹配索引前缀，就会跳过索引；重构时顺手跑一遍 EXPLAIN 对比