# 平台商品审核接口

日期：2026-10-13。

## 修复原因

平台商品管理的审核开关曾调用 `PUT /chanting/food/changerecommend`。该方法为商家入口，要求商家 `token` 请求头、`@Auth` 和门店归属校验；平台使用 `Authorization: Bearer ...` 登录，因此出现缺少 `token` 的错误。不能把平台令牌伪装为商家令牌，也不能删除商家接口的身份/归属校验。

## 平台专用方法

`PUT /chanting/food/audit`

- 登录与授权：现有平台 Authorization 机制，沿用 `chanting:food:edit` 权限；非匿名接口，不读取商家 token。
- 请求 DTO 仅包含 `id`（正整数）与 `toExamine`（字符串 `"0"` 或 `"1"`）。`"1"` 为审核通过，`"0"` 为撤销审核；不改变商品本身的 `stackingUp` 上下架字段含义。
- 服务端只构造 `id/toExamine` 的更新对象，使用现有 UPDATE，不能插入不存在的商品，不处理或删除规格关联，不能借审核改门店、价格、名称、推荐或图片。
- 参数不合法返回本地化 `food.audit.invalid`；未更新到记录返回原 AjaxResult 失败格式。平台请求失败或取消确认时，审核开关恢复原值。
- 操作沿用平台更新日志；商家 `/changerecommend` 完全不变。列表、详情和通用商品编辑接口不在本次调整范围内。

```json
{"id":9137,"toExamine":"1"}
```

成功响应为现有 AjaxResult `code=200`，业务失败 `code=500`；HTTP 200 本身不代表审核已成功。无数据库字段、结构或菜单权限新增，无需执行 SQL。

## 验收

1. 平台使用具备商品编辑权限的账号，切换审核通过/撤销，应请求 `/chanting/food/audit`，不再报缺少商家 token。
2. 只有列表权限或未登录时不能执行审核；开关使用原商品编辑权限控制。
3. 刷新列表核对审核结果；同时确认价格、门店归属、推荐、商品上架字段和规格均未变化。
4. 非法 ID/状态、不存在商品、取消确认和请求失败不能产生错误成功提示；失败时开关恢复。
5. 原商家接口仍要求商家登录与归属校验。

自动测试使用模拟数据库访问，不连接实际数据库；部署后仍需验证真实平台登录、角色权限与数据库更新。

## 本次本地验证

- 已先复现原页面调用商家接口以及缺少平台审核方法的失败用例，再验证修复；商品审核新增 6 个 Java 用例和 2 个前端行为用例。
- JDK 21 商品 Controller 与商家认证定向测试通过；`mvn -pl ruoyi-admin -am test -q` 全回归通过（admin/system 报告合计 1155 项、0 失败、0 错误、0 跳过）。`mvn -pl ruoyi-admin -am -DskipTests package -q` 模块打包通过，打包命令本身不运行测试。
- 平台全部 Node 行为测试 27/27 通过；`food.js` ESLint 通过；staging 构建成功，保留既有两个 `.vue~` 备份文件和包体积警告，未修改无关文件。
- 未执行：真实平台登录、无权限账号拦截、实际 MySQL 更新和部署后页面冒烟。上述 MockMvc 使用独立 Controller，权限注解为契约校验，不代表已跑完整 Spring Security/真实令牌集成。