# BUFF 选品配置表设计思路

## 1. 背景与目标

- **当前行为**：「BUFF选品」界面中的「保存配置信息」将**检索条件**（步枪、手枪、品质、外观、收藏品、排除/指定商品 id）与**选品条件**（Steam 卡价比例、利润率、BUFF 价格/销量区间、智能选品助手等级）保存到**浏览器 localStorage**，仅本机生效、换设备或清缓存即丢失。
- **目标**：用**数据库表**持久化上述配置，实现「按用户存储、多端同步、可选多套配置」。

---

## 2. 数据范围梳理

需要落库的字段与前端 form 一致，分为两类：

| 类别 | 字段 | 类型 | 说明 |
|------|------|------|------|
| **检索条件** | rifle, pistol, smg, shotgun, machinegun | string[]（存 JSON） | 武器类型多选 value |
| | quality, category, exterior, collection | string[]（存 JSON） | 品质/类别/外观/收藏品多选 value |
| | excludeIds | string | 排除的商品 id，多行文本 |
| | specifiedIds | string | 指定商品 id，多行文本 |
| **选品条件** | steamCardRatio | number | Steam 卡价比例 |
| | profitRate | number | 利润率（%） |
| | buffPriceMin, buffPriceMax | number | BUFF 价格区间 |
| | buffSalesMin, buffSalesMax | number | BUFF 销量区间 |
| | assistantLevel | string | 智能选品助手：low/standard/high |

---

## 3. 设计要点

### 3.1 与用户关联

- 配置必须**按用户**隔离，表中有 **user_id**（或等价登录标识），与现有 users 表一致。
- 未登录时仍可沿用「仅写 localStorage」或提示先登录再保存到云端。

### 3.2 单套 vs 多套配置

两种常见方式：

- **方案 A：每用户仅一套配置**  
  - 一用户一行，每次保存覆盖。表结构简单，无需「配置名称」「默认配置」等字段。
- **方案 B：每用户多套配置（推荐）**  
  - 一用户多行，每条配置有**名称**（如「默认」「高利润」「步枪专选」），便于区分场景；可增加 **is_default** 标记「当前默认加载哪一套」。

建议采用**方案 B**，便于后续扩展「配置列表 + 切换」而不必改表结构。

### 3.3 存储形式：JSON vs 纵表

- **JSON 一列存整份配置**  
  - 优点：与前端 form 结构一致，扩展方便（新增筛选项或选品参数只需改前端，后端只存 JSON）。  
  - 缺点：无法按「某个筛选项」做 SQL 统计或检索。
- **纵表 / 多列**  
  - 优点：可对单字段建索引、做统计。  
  - 缺点：字段多、表结构随前端 form 变更频繁，且多选数组仍需 JSON 或关联表。

**推荐**：**主表 + 单列 JSON 存「检索条件 + 选品条件」**。若未来需要对某几项做查询，再考虑在表上增加个别冗余列或独立统计表。

---

## 4. 推荐表结构（思路）

### 4.1 表名

- **buff_selection_config**（BUFF 选品配置表）

### 4.2 字段建议

| 字段 | 类型 | 说明 |
|------|------|------|
| id | bigint unsigned, PK, AUTO_INCREMENT | 主键 |
| user_id | int unsigned, NOT NULL | 用户 ID，关联 users.id |
| name | varchar(64), NOT NULL | 配置名称（如「默认」「高利润」），同用户下建议唯一 |
| config_json | text/json, NOT NULL | 整份配置的 JSON：包含 rifle、pistol、…、excludeIds、specifiedIds、steamCardRatio、profitRate、buffPriceMin/Max、buffSalesMin/Max、assistantLevel，与前端 form 结构一致 |
| is_default | tinyint(1), DEFAULT 0 | 是否该用户的默认配置：0-否，1-是；同用户至多一个为 1 |
| is_deleted | tinyint(1), DEFAULT 0 | 软删：0-否，1-是 |
| created_at | datetime | 创建时间 |
| updated_at | datetime | 更新时间 |

### 4.3 约束与索引

- **唯一约束**：`(user_id, name)`，且仅当 `is_deleted = 0` 时唯一（若数据库支持条件唯一索引则可加，否则在业务层保证「同用户下未删除的 name 不重复」）。
- **索引**：`user_id`、`user_id + is_default`（便于查某用户的默认配置）。

### 4.4 config_json 内容示例

与当前前端保存的 JSON 保持一致即可，例如：

```json
{
  "rifle": ["weapon_ak47", "weapon_awp"],
  "pistol": [],
  "smg": [],
  "shotgun": [],
  "machinegun": [],
  "quality": ["ancient_weapon", "legendary_weapon"],
  "category": [],
  "exterior": ["wearcategory0", "wearcategory1"],
  "collection": ["set_community_36"],
  "excludeIds": "123\n456",
  "specifiedIds": "",
  "steamCardRatio": 0.85,
  "profitRate": 10,
  "buffPriceMin": 10,
  "buffPriceMax": 500,
  "buffSalesMin": null,
  "buffSalesMax": null,
  "assistantLevel": "standard"
}
```

---

## 5. 与现有流程的关系

- **保存**：点击「保存配置信息」时，若已登录，可调后端接口：传 `name`（可选，默认如「默认」）、`config_json`、是否设为 `is_default`；后端按 user_id 写入或更新 `buff_selection_config`。
- **加载**：进入「BUFF选品」页时，若已登录，可先请求「当前用户的默认配置」或「配置列表」，回填 form；未登录或未拉取到配置时，再回退到 localStorage。
- **本地与云端**：可保留「先写 localStorage、再异步同步到服务端」的策略，减少未登录或网络异常时的体验损失。

---

## 6. 小结

| 项目 | 建议 |
|------|------|
| 表名 | buff_selection_config |
| 与用户 | user_id 必填，按用户隔离 |
| 多套配置 | 支持，用 name 区分，is_default 标记默认 |
| 内容存储 | 单列 config_json，与前端 form 结构一致 |
| 软删 | is_deleted，便于「删除」后保留历史或恢复 |

按此思路可实现「保存配置信息」落库、多端同步与多套配置，且与当前前端数据结构兼容，后续若要对部分字段做统计再在表或统计库中做冗余即可。