# 微信注册简化与联系方式补全方案

> 状态：已定稿，按本文实施  
> 范围：微信注册放宽手机/邮箱；「我要下单 / 揽收订单」入口强制补全；RBAC 账号改为客户编号  
> 相关代码：前端 `oms0414`，后端 `oms0414-back`

---

## 1. 目标

1. **提高转化**：微信注册不再强制填手机、邮箱，缩短注册路径。  
2. **保证可联系**：进入「我要下单」「揽收订单」时，若缺手机或邮箱，必须补全后才能继续。  
3. **交互明确**：说清「为什么要填」，补全后自动回到原流程，不丢草稿。  
4. **防绕过**：前端入口拦截 + 后端下单/揽收接口兜底。

---

## 2. 已拍板决策

| 项 | 决策 |
|----|------|
| 补全字段 | **手机 + 邮箱都要** |
| 拦截时机 | **一进入**「我要下单 / 揽收」流程就弹；提交时后端再拦 |
| 登录账号 | 微信注册创建的 RBAC `Account = CustomerCode` |
| 注册范围 | **仅微信注册**放宽；PC 注册 / 后台建客 / 子客户仍必填手机+邮箱 |
| 空值存储 | 未填一律存 **`NULL`**，禁止 `''`（避免唯一索引冲突） |

---

## 3. 现状与痛点（摘要）

- 微信注册：`CustomerName / Phone / Email / Password` 全必填；RBAC `Account = Phone`；注册后用手机号自动登录。  
- `t_customer.Phone`：`NOT NULL` + `uk_cus_phone`；`Email` 可空 + 唯一。  
- 「我要下单 / 揽收」校验的是**收件人/寄件地址电话**，**不看**客户资料手机邮箱。  
- 因此：放开注册后，**不会自动出现**「缺联系方式」拦截，必须新增门禁。

---

## 4. 方案设计

### 4.1 微信注册（简化）

**表单保留**

- 客户名称（必填）  
- 密码（必填，≥6，建议保持字母+数字规则）  
- 微信 OAuth 资料（openid 等）  
- 邀请码（可选，来自 `?ref=`）

**表单去掉必填（可不展示）**

- 手机、邮箱：注册请求可不传或传空 → 后端存 `NULL`

**后端**

- `WeChatCustomerRegisterInput`：`Phone`、`Email` 改为可选；有值时仍做格式与唯一性校验。  
- RBAC：`Account = customerCode`，`Email` 有则写入，无则按 RBAC 允许的空策略处理。  
- `Customer.Phone` / `Email`：可空。  
- 返回或保证前端能拿到 `customerCode`，用于自动登录。

**注册成功自动登录**

- 使用 **`customerCode + password`** 调客户登录（不再用手机号）。  
- 成功页文案提示：可用「客户编号」或微信扫码登录；建议尽快在下单前完善手机与邮箱。

### 4.2 资料完整度

新增只读接口（命名可微调）：

```
GET /customer/profile-completeness
→ {
    phoneFilled: boolean,
    emailFilled: boolean,
    needContact: boolean,   // !phoneFilled || !emailFilled
    customerCode: string
  }
```

判定：`Phone` / `Email` trim 后非空即算已填。

### 4.3 补全接口

优先复用 `/customer/update`；若更新契约过重，可增加：

```
POST /customer/complete-contact
Body: { phone: string, email: string }
```

规则：

- 手机、邮箱均必填（补全场景）  
- 格式校验 + 排除自身的唯一性校验  
- 同步更新 RBAC 用户 Email（若框架支持）；**不改** RBAC Account（仍为客户编号）  
- 成功后 `needContact = false`

### 4.4 入口拦截（前端）

**触发点（一进流程）**

| 端 | 触发 |
|----|------|
| H5 | 打开「我要下单」总流程（含物流下单 / 揽收创建）；发货指引里进入「创建揽收」 |
| PC | 进入「我要下单」「揽收订单」页或点创建同类入口 |

**不拦截**

- 仅浏览订单列表、揽收列表（只读）  
- 查价、客服、充值（本期不做强制；后续可扩展）

**交互**

1. 半屏/弹窗标题：补充联系方式  
2. 说明：下单与揽收前请留下手机号和邮箱。清关补料、派送异常或费用确认时，我们会优先通过这些方式与您确认，避免延误。  
3. 表单：缺啥填啥（两项都缺则两项都填）；实时格式校验。  
4. 主按钮：保存并继续；次按钮：取消（关闭流程，不提交订单）。  
5. 保存成功：关弹层，**自动继续**原动作（保留下单/揽收草稿）。  
6. 唯一性冲突：明确提示「手机号/邮箱已被占用」。

### 4.5 后端兜底

在以下接口进入业务逻辑前校验主客户联系方式：

- 小包/物流下单创建（如 `parcel/create`）  
- 揽收单创建（如 `pickup` create）

缺手机或邮箱时抛业务异常，建议稳定文案或错误码：

- 文案：`请先完善手机号和邮箱后再下单`  
- 码（可选）：`CUSTOMER_CONTACT_REQUIRED`

前端捕获后同样打开补全弹层。

### 4.6 数据库

```sql
-- Phone 改为可空（存量数据不变）
ALTER TABLE t_customer
  MODIFY COLUMN `Phone` VARCHAR(16) NULL COMMENT '手机号，用于联系/登录辅助';
```

唯一索引 `uk_cus_phone` / `uk_cus_email` 保留；空值必须为 `NULL`。

实体 `Customer.Phone` 改为 `string?`。

---

## 5. 非目标（本期不做）

- 不改 PC 注册 / 后台建客的必填规则  
- 不改收件人手机、寄件地址电话的面单字段规则（与客户资料联系方式分离）  
- 不强制充值、提现、售后入口（可二期）  
- 不实现短信通道（有手机即可为后续预留）

---

## 6. 风险与注意

1. **老数据**：已有客户均有手机，不受影响。  
2. **密码登录**：无手机邮箱时只能用客户编号或微信扫码；注册成功需展示客户编号。  
3. **RBAC Email**：无邮箱时 CreateUser 需确认 Fake RBAC 是否允许空 Email；不允许则写占位策略需单独评估（优先真实可空）。  
4. **H5 编辑资料**：补全与编辑共用校验，避免「清空手机」绕过。  
5. **并发抢号**：补全时唯一冲突要友好提示。

---

## 7. 验收清单

- [ ] 微信注册可不填手机/邮箱，注册成功并自动登录进入 H5  
- [ ] 新用户 RBAC Account = 客户编号；可用客户编号+密码登录  
- [ ] 缺联系方式时，点「我要下单」立刻弹出补全，取消则不进入下单  
- [ ] 缺联系方式时，进入「创建揽收」同样拦截  
- [ ] 补全成功后自动继续原流程  
- [ ] 绕过前端直接调创建接口，后端返回联系方式必填错误  
- [ ] 手机/邮箱重复时有明确错误提示  
- [ ] 已完善资料的老用户路径无额外弹窗

---

## 8. 实施顺序

1. 本文档定稿  
2. 后端：库表/实体 → 微信注册 → 完整度/补全 API → 下单/揽收门禁  
3. 前端：微信注册页 → 补全弹层组件 → H5/PC 入口接入  
4. 联调与验收清单勾选