# 用户审核不通过原因

## 背景

平台目前只支持“待审核”和“审核通过”两种用户审核状态，管理员无法明确记录商家或骑手资料审核不通过的原因。后续用户端需要根据审核结果提示用户补充资料，但本次不修改 App 前端。

## 目标

- 用户审核状态增加“审核不通过”。
- 管理员审核商家或骑手资料不通过时，必须输入具体原因。
- 原因随用户信息返回，供后续 App 展示和资料补充流程使用。

## 数据模型

- `info_user.audit_status` 状态语义：
  - `0`：待审核。
  - `1`：审核通过。
  - `2`：审核不通过。
- `info_user` 新增 `audit_reject_reason TEXT NULL`，Java 属性名为 `auditRejectReason`。
- 不对审核不通过原因设置应用层字符数限制。
- 当审核状态不是 `2` 时，保存操作必须将 `audit_reject_reason` 清空，避免旧原因与当前状态不一致。

## 平台管理端

- 修改商家审核页 `sjuser.vue` 和骑手审核页 `peisus.vue`。
- 审核状态选项增加“审核不通过”。
- 选择“审核不通过”时显示多行文本输入框，由管理员按实际情况自由填写。
- 原因去除首尾空白后为空时禁止提交，并显示国际化错误提示。
- 选择“待审核”或“审核通过”时隐藏原因输入框，提交前清空旧原因。
- 新增用户可见文本必须补齐简体中文、繁体中文、英文和越南语。

## 后端行为

- 平台新增和修改用户接口继续使用 `POST /infouser/user`、`PUT /infouser/user`，两者执行同一审核原因校验。
- 当 `auditStatus = "2"` 时，`auditRejectReason` 去除首尾空白后必须非空；否则返回国际化业务错误，不更新用户。
- 当 `auditStatus` 不等于 `"2"` 时，后端主动将 `auditRejectReason` 设为 `null`，不能只依赖前端清理。
- 用户列表、平台用户详情和 App 用户信息接口沿用现有 `InfoUser` 返回结构，新增返回 `auditRejectReason`。
- App 资料更新接口 `/infouser/user/setuser` 不接受客户端提交的审核状态，防止用户自行改变审核结果。
- `/infouser/user/setuser` 接收非持久化标记 `updateUserInfo`；仅当资料保存成功、该标记为 `true` 且数据库当前审核状态为 `2` 时，将审核状态原子更新为 `0` 并清空 `auditRejectReason`。
- `updateUserInfo` 为 `false`、`null`，或用户当前并非审核不通过时，不改变审核状态。
- Entity、MyBatis `resultMap`、查询、插入和更新映射全部补齐该字段。

## 数据库变更

- 只将迁移 SQL 写入 `updatesql/sql.md`，不直接执行数据库变更。
- SQL 为 `info_user` 新增 `audit_reject_reason TEXT NULL`。
- 为 `sys_user_audit` 字典新增值 `2`，标签为“审核不通过”，供平台审核状态选项使用。

## 验收标准

1. 商家和骑手审核页均能选择“审核不通过”。
2. 选择“审核不通过”但未填写有效原因时，前端和后端都拒绝保存。
3. 填写原因后可以保存，重新打开用户资料时能正确回显。
4. 将状态改为“待审核”或“审核通过”后，数据库中的旧原因被清空。
5. `getuserinfo` 等返回用户信息的现有接口包含 `auditRejectReason`。
6. 本次不修改商家或骑手 App 前端。
7. 审核不通过的用户携带 `updateUserInfo=true` 成功补充资料后恢复为待审核并清空旧驳回原因；普通资料更新不改变审核状态。

## 非目标

- 不提供固定原因或预设原因选项。
- 不建立审核历史记录表。
- 不记录每次审核的管理员、时间或历史原因。
- 不实现 App 端红色提示、资料高亮或字段只读控制。