ThinkPHP模型只读字段设置方法防止价格字段被篡改

在电商、订单等涉及资金交易的业务系统中，价格字段的安全性至关重要。许多开发者习惯在ThinkPHP模型中配置 $readonly = ['price']，认为这能确保万无一失。然而现实情况更为复杂，这一配置更像一道“君子协定”，主要依赖框架的常规流程，难以抵御蓄意的恶意攻击。本文将深入解析其局限性，并系统阐述真正有效的多层防护策略。

核心观点先行：ThinkPHP模型的 $readonly 属性仅在通过模型对象调用 save() 或 update() 方法时生效。面对原生SQL执行、强制数据覆盖、字段命名不一致等场景，其防护作用完全失效。要有效防止客户端恶意篡改价格，必须依赖请求签名验证、专用业务方法封装等组合策略，而非单一依赖模型层的软性约束。

为何 $readonly = ['price'] 无法阻挡恶意篡改

本质上，$readonly 是ThinkPHP模型提供的一种便捷性设计，并非严格的安全机制。它仅在特定的数据持久化路径中起作用。以下常见场景均会导致其防护失效：

• 原生SQL直接操作：若客户端提交 {"id":123,"price":"999"} 数据，后端直接使用 Db::name('order')->update($data) 更新数据库，由于未实例化模型，$readonly 规则根本不会被执行。
• 强制数据覆盖：使用 $model->data($data, true)->save() 时，第二个参数 true 表示强制覆盖，这将跳过包括 $readonly 在内的所有字段过滤与检测机制。
• 字段命名风格不匹配：数据库实际字段名为下划线风格的 unit_price，而 $readonly 数组中配置的是驼峰式 unitPrice 或其他形式，框架在进行字段匹配时会失败，导致防护规则被绕过。
• 字段未在模型中定义：若前端传递了 price 字段，但该字段未包含在模型的 $schema 或 $field 属性定义中，$readonly 同样无法对其产生约束作用。

有效防护策略一：前置请求签名验证

第一道也是最重要的防线，是在请求进入核心业务逻辑前完成签名验证。此步骤应作为强制环节，通常置于全局或路由中间件中执行。

• 使用原始输入进行验签：务必通过 $this->request->rawInput() 获取原始的JSON请求体，或手动拼接 get() 与 post() 参数。避免使用 param() 方法，因其自动的参数合并与过滤可能改变原始数据，导致签名校验失败。
• 标准化参数拼接流程：对所有请求参数（除 sign 和 timestamp 外）按键名进行 ksort() 排序，对每个参数值进行 rawurlencode() 编码，然后拼接成待签名字符串，确保与服务端生成逻辑一致。
• 实施时效性与防重放机制：客户端提交的 timestamp 时间戳，服务端应校验其与服务器时间的偏差（例如±300秒内）。同时，利用 nonce 随机字符串并存入Redis（设置600秒过期），有效防止同一请求被重复提交攻击。
• 严格失败拦截：一旦签名验证失败，应立即返回401等状态码，并终止后续所有业务处理流程，不记录业务日志、不开启数据库事务，将潜在攻击拦截在系统最外层。

有效防护策略二：价格更新专用方法封装

即使签名验证通过，价格字段的修改也必须受到严格管控。所有涉及金额变更的业务操作，都应封装在独立的服务方法中，并内置完整的业务规则校验。

• 创建专用业务方法：例如定义 changePrice($newPrice) 方法。在该方法内部，首先校验当前订单状态是否允许修改价格（例如，仅允许在“待支付”状态下调价）。
• 执行价格合理性校验：对新价格进行范围与格式校验，例如 if ($newPrice 999999.99) { throw new Exception('价格超出允许范围'); }，防止异常数据注入。
• 强制记录操作日志：任何价格变更操作都必须生成详细的审计日志，记录操作人ID、时间戳、原始价格、新价格及变更原因。这不仅满足合规要求，也为事后追踪与问题排查提供完整依据。
• 谨慎使用模型事件钩子：避免在模型的 beforeUpdate 等事件中简单判断 $data['price'] 是否变化。因为数据可能在流程早期已被其他钩子修改，且钩子中难以区分变更来源是用户请求还是系统内部逻辑，容易引发误拦截或逻辑混乱。

数据库与模型层的辅助与兜底措施

$readonly 配置可作为辅助手段保留，但防护重心应置于更底层、更严格的约束上。

• 强化数据库层约束：在MySQL 5.7及以上版本，可考虑将 price 字段设置为 GENERATED ALWAYS AS (...) STORED 的生成列。若使用MySQL 8.0.16+，可添加 CHECK (price >= 0.01) 约束，利用数据库引擎进行强制校验。
• 精准配置只读字段：模型中的 $readonly 最好仅用于那些在业务生命周期内绝对不变的字段，如 create_time、order_sn。对于 price 等需要通过特定流程修改的敏感字段，若使用只读属性，必须确保其不会阻碍合法的后台管理或系统调价流程。
• 确保字段命名完全一致：若要使用 $readonly 保护 price 字段，务必确保配置的字段名与数据库表结构中的列名严格一致，建议统一使用全小写、下划线分隔的命名规范（如数据库列为 unit_price，模型配置即为 ['unit_price']）。
• 注意关联模型的数据更新：当通过关联预加载（如 $order->goods）获取关联模型对象后，直接修改其属性（如 $order->goods->price）并调用 save()，主模型（Order）中配置的 $readonly 规则对关联模型（Goods）是无效的，这是一个常见的安全盲区。

最后需要权衡一个常见矛盾：将 price 加入 $readonly 可能导致后台运营系统正常的调价功能失效。反之，若API层的签名验证存在遗漏，一旦接口暴露，价格字段极易成为攻击目标。因此，构建可靠的价格防篡改体系必须采用分层、纵深防御的思想。从请求入口的签名验证、到业务逻辑的专用方法封装，再到模型层的约束与数据库底层的校验，每一层都需履行职责，协同工作，方能形成坚实的安全防护网。