ThinkPHP中Model的只读字段_updateWhere条件限制【技巧】
ThinkPHP的$readonly属性仅对模型实例的save()/update()有效,而静态where()->update()可绕过此限制,造成字段未受保护。解决方案包括:显式指定允许更新的字段、使用allowField()设置白名单、在服务层封装方法进行字段校验,以及实施数据库级约束如默认值、触发器或生成列。
ThinkPHP的$readonly只对模型实例的sa ve()/update()生效,对where()->update()等静态批量更新无效;需通过allowField()、字段白名单或封装服务方法手动控制可更新字段。

在TP开发中,模型只读字段和where(...)->update()静态调用,其实是两条完全独立的执行路径。很多人踩过一个坑:明明在模型里老老实实声明了$readonly = ['create_time', 'status'],结果一个where()->update()就绕过去了,字段照样被改得面目全非。这不是Bug,而是机制决定的——$readonly只对实例化后的sa ve()或update()生效,对静态批量更新完全不设防。
只读字段不拦得住 where()->update()
$readonly的定义,只有在调用$model->sa ve()或$model->update()时,才会从待写入的数据数组中过滤掉那些字段。换句话说,只要你不走实例方法,它就干瞪眼。下面这几种写法,都能轻松绕过这个“只读”限制:
User::where('id', 1)->update(['status' => 9, 'create_time' => '2020-01-01'])Db::name('user')->where('id', 1)->update([...])User::update(['status' => 9], ['id' => 1])(静态update,不是实例方法)
这些操作都是直通SQL的,根本不会进入模型的数据组装和过滤环节。所以,$readonly在这种场景下,等于摆设。
想限制 where()->update() 的字段?得靠主动控制
没有现成的“自动只读”机制给你的静态更新保驾护航,只能人为划定更新范围。具体说,有几种做法:
- 显式控制传入字段,只写允许更新的部分:
User::where('id', 1)->update(['status' => 2, 'updated_at' => time()]),别手滑带上不该动的字段。 - 利用
allowField()配合模型静态update():User::update(['status' => 2, 'name' => 'xxx'], ['id' => 1], ['status', 'updated_at'])——第三个参数就是允许更新的字段白名单(TP6.0+支持)。 - 封装一个服务方法,在调用前做字段校验:
if (!in_array($field, ['status', 'remark'])) { throw new Exception('非法更新字段'); }。这是最彻底、也是团队协作中最推荐的做法。
条件筛选(WHERE)本身不依赖只读字段,但要注意逻辑陷阱
所谓的“updateWhere条件限制”,其实就是where()的使用方式。说几个最容易踩的坑:
- 误用了实例方法:
$user = new User(); $user->where(...)->update(...)——这样写根本不会生效,必须换成User::where(...)->update(...)静态调用。 - 把WHERE条件塞进了update的数据数组里:比如
User::update(['id'=>1, 'status'=>2])。想用id当筛选条件?那是主键更新,不是条件更新,结果完全不一样。 - 软删除记录也被顺手更新了:如果模型开启了
SoftDelete,where()->update()默认不会跳过已软删除的行。需要手动加上->where('delete_time', null)才能规避。
更安全的组合方案
单靠$readonly或者只用where()->update(),都是不够牢靠的。多上几道锁,才睡得踏实:
- 应用层:在模型里声明
$readonly,可以拦住大部分sa ve()场景。对于status这类关键字段,再配上验证规则rule('status', 'in:0,1,2'),双重把关。 - SQL层:数据库层面的硬约束更可靠。比如给
create_time加上DEFAULT CURRENT_TIMESTAMP,给update_time加上ON UPDATE CURRENT_TIMESTAMP。即便应用层没拦住,数据库也不会乱动。 - 执行层:批量状态更新统一走封装方法,比如
OrderService::batchUpdateStatus($ids, $newStatus),内部做好字段清洗和日志审计。既统一了入口,也方便后续追溯。


































