ThinkPHP中Model的只读字段_updateWhere条件限制【技巧】

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)，内部做好字段清洗和日志审计。既统一了入口，也方便后续追溯。