# 祈盟SDK Go重构 - 决策确认清单

> **使用方法**: 每个条目都有【决策选项】，请在你的选择处标记 `[x]`，未确认的标记 `[?]`
> 确认完成后，基于此文档开始实施

---

## 一、需要确认的业务问题

这些直接影响重构范围，需要你找业务方或自己确认。

### Q1. 渠道回调 - 哪些还在用？

`application/complex/controller/` 下有19个渠道控制器，请确认哪些还有业务流量：

| 渠道 | 文件 | 状态 |
|------|------|------|
| 爱豆 | Aidou.php | `[?]在用` `[?]已废弃` |
| 飞腾 | Fengteng.php | `[?]在用` `[?]已废弃` |
| 沪维 | Huwei.php | `[?]在用` `[?]已废弃` |
| 聚思达 | Juside.php | `[?]在用` `[?]已废弃` |
| 奇信 | Qixin.php | `[?]在用` `[?]已废弃` |
| 顺游安卓 | Shunyouanr.php | `[?]在用` `[?]已废弃` |
| 顺游IOS | Shunyouios.php | `[?]在用` `[?]已废弃` |
| 思默 | Simo.php | `[?]在用` `[?]已废弃` |
| 思默快 | Simoquick.php | `[?]在用` `[?]已废弃` |
| 微游 | Vyou.php | `[?]在用` `[?]已废弃` |
| 小智 | Xiaozhi.php | `[?]在用` `[?]已废弃` |
| 西谷 | Xigu.php | `[?]在用` `[?]已废弃` |
| 鑫客源 | Xkhyn.php | `[?]在用` `[?]已废弃` |
| 翼牛 | Yiniu.php | `[?]在用` `[?]已废弃` |
| 自游 | Ziyou.php | `[?]在用` `[?]已废弃` |
| 邹boom | Zoulboom.php | `[?]在用` `[?]已废弃` |
| 第一 | Diyi.php | `[?]在用` `[?]已废弃` |
| 奥游 | Aoyou.php | `[?]在用` `[?]已废弃` |
| 爱豆(另一版) | Aidou.php | `[?]在用` `[?]已废弃` |

> **决策**: 废弃的渠道不迁移，只迁移在用的

---

### Q2. 旧版接口 - 客户端还能升级吗？

以下接口有新旧版本并存，确认是否可以只保留新版：

| 旧接口 | 新接口 | 可否只保留新版？ |
|--------|--------|-----------------|
| `/v2.game_notify/index_v2`(标记"准备弃用") | `/v2.game_notify/index_v3` | `[?]可以` `[?]不行，要兼容` |
| `/gh/channel_data_summary`(弃用) | `/gh/channel_data_summary_v2` | `[?]可以` `[?]不行，要兼容` |
| `/v2.complex_authentication/query`(弃用) | 无替代 | `[?]可以` `[?]不行，要兼容` |
| `/v1.complex_login/index.html` | 无替代(保持v1) | `[?]保持v1` `[?]升级到v2风格` |

> **决策**: 不能升级的接口需要在Go中保留兼容路由

---

### Q3. 数据表 - 哪些还在用？

项目有151个Model，但很多可能已废弃。请用以下SQL查一下哪些表还有近期写入：

```sql
-- 在MySQL中执行，查看最近30天有写入的表
SELECT TABLE_NAME, UPDATE_TIME, TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = '你的数据库名'
  AND UPDATE_TIME > DATE_SUB(NOW(), INTERVAL 30 DAY)
ORDER BY UPDATE_TIME DESC;
```

> **决策**: 只迁移有业务流量的表对应的Model

---

## 二、接口重构决策

### A. 可以直接废弃的接口

以下接口已明确标记弃用或功能已被替代：

| 接口 | 废弃原因 | 确认废弃？ |
|------|----------|-----------|
| `/v2.game_notify/index_v2` | 已有v3替代 | `[?]是` `[?]否` |
| `/v2.complex_authentication/query` | 已标记弃用 | `[?]是` `[?]否` |
| `/gh/channel_data_summary` | 已有v2替代 | `[?]是` `[?]否` |
| `/index/notidy` | 仅为示例 | `[?]是` `[?]否` |

---

### B. 路径风格统一方案

现有路径风格混乱，需要统一。请选择新系统的路径风格：

| 方案 | 示例 | 优点 | 缺点 |
|------|------|------|------|
| **A. RESTful风格** | `POST /api/v1/users/login` | 业界标准，语义清晰 | 改动大，客户端需适配 |
| **B. 保持现有风格** | `POST /v1.login/index.html` | 客户端零改动 | 继续混乱 |
| **C. 折中：保留方法名，去掉`.html`** | `POST /api/v1/login` | 改动小，相对规范 | 不够RESTful |

> **决策**: `[?]方案A` `[?]方案B` `[?]方案C` `[?]其他:______`

---

### C. 版本策略

现有v1/v2混用，新系统如何处理？

| 方案 | 说明 |
|------|------|
| **A. 全部v1重来** | 新系统统一用 `/api/v1/`，不区分旧v1/v2 |
| **B. 保持v1/v2分离** | 旧v1接口映射到新v1，旧v2映射到新v2 |
| **C. 只迁移v2** | 旧v1接口如果是早期版本，直接废弃 |

> **决策**: `[?]方案A` `[?]方案B` `[?]方案C`

---

## 三、代码层面的优化决策

### D. common.php 函数迁移清单

90+全局函数，逐个确认迁移方式：

#### HTTP请求类（9个 → 1个统一客户端）

| 原函数 | 迁移方案 | 确认 |
|--------|----------|------|
| `getCurlContent` | → `HttpClient.Get/Post` | `[?]保留` `[?]合并` |
| `getCurl` | → `HttpClient.Get` | `[?]保留` `[?]合并` |
| `curl` | → `HttpClient.Post` | `[?]保留` `[?]合并` |
| `apipost` | → `HttpClient.PostForm` | `[?]保留` `[?]合并` |
| `getHttp` | → `HttpClient.Do` | `[?]保留` `[?]合并` |
| `getHttpGet` | → `HttpClient.Get` | `[?]保留` `[?]合并` |
| `getHttpException` | → `HttpClient.PostJSON` | `[?]保留` `[?]合并` |
| `curlHeader` | → `HttpClient.Do` | `[?]保留` `[?]合并` |
| `timingCurl` | → `HttpClient.WithTimeout` | `[?]保留` `[?]合并` |

> **建议**: 全部合并为一个 `HttpClient` 结构体，统一超时、重试、日志
> **决策**: `[?]同意合并` `[?]保留原有风格`

---

#### 数据脱敏类（6个 → 1个通用函数）

| 原函数 | 迁移方案 | 确认 |
|--------|----------|------|
| `stringObfuscation` | → `util.Mask(s, keepStart, keepEnd)` | `[?]合并` |
| `idcardObfuscation` | → `util.MaskIDCard(s)` | `[?]合并` |
| `passwordObfuscation` | → `util.Mask(s, 3, 3)` | `[?]合并` |
| `mobileObfuscation` | → `util.MaskMobile(s)` | `[?]合并` |
| `usernameObfuscation` | → `util.Mask(s, 1, 1)` | `[?]合并` |
| `mailObfuscation` | → `util.MaskEmail(s)` | `[?]合并` |

> **决策**: `[?]同意合并` `[?]保留各自独立函数`

---

#### 渠道查询类（8个 → 1个ChannelService）

| 原函数 | 问题 | 迁移方案 |
|--------|------|----------|
| `get_top_channel` | while循环N次SQL | → `ChannelService.GetTop(channelId)` |
| `get_union_channel` | 同上 | → `ChannelService.GetUnion(channelId)` |
| `get_channel_level` | 查整条记录只为取level | → `ChannelService.GetLevel(channelId)` |
| `get_top_second_channel_name` | 80行复杂逻辑 | → `ChannelService.GetAncestors(channelId)` 派生 |
| `get_top_second_channel_name_v2` | 优化版，2次SQL | → 以此为基础实现 |
| `get_channel_top_by_aggregate` | 重复逻辑 | → `ChannelService.GetTop(channelId)` 复用 |
| `get_channel_name` | 简单查询 | → `ChannelService.GetName(channelId)` |
| `get_complex_channel_name` | 简单查询 | → `ChannelService.GetName(channelId)` 复用 |

> **决策**: `[?]以v2为基础统一实现` `[?]保留各自函数`

---

#### 安全相关 - 必须修改

| 问题 | 原代码 | Go方案 | 确认 |
|------|--------|--------|------|
| 硬编码密钥 | `$key = 'ukN3KYVdI2sPtjpL'` | 配置文件/环境变量 | `[?]同意` |
| dd()调试函数 | `echo Db::getLastSql(); die;` | 删除 | `[?]同意` |
| die()暴露信息 | `die('签名校验失败 '.$thisSign)` | 统一错误码，不暴露细节 | `[?]同意` |
| unserialize反序列化 | `$param = unserialize($param)` | 改用JSON存储 | `[?]同意` `[?]需要兼容旧数据` |

---

#### 可以直接删除的函数

| 函数 | 删除理由 |
|------|----------|
| `dd()` | 调试函数 |
| `arrayColumnByObject()` | PHP7.0已有array_column |
| `is_mobile_request()` | UA检测已不可靠 |
| `priceFormat()` | 就是number_format的包装 |
| `dump()` | 调试函数 |

> **决策**: `[?]同意删除` `[?]保留某些:______`

---

### E. 支付回调重构方案

现有19个渠道控制器，每个都有 `pay()` 方法。重构方案：

| 方案 | 说明 | 优点 | 缺点 |
|------|------|------|------|
| **A. 策略模式** | 定义 `ChannelAdapter` 接口，每个渠道实现 `ParseParams` + `VerifySign` | 代码最干净，新增渠道只需加一个适配器 | 需要梳理每个渠道的差异 |
| **B. 配置驱动** | 将参数映射和签名规则存DB/配置，通用解析器读取配置执行 | 不用为每个渠道写代码 | 签名算法可能无法完全配置化 |
| **C. 保持独立文件** | 继续每个渠道一个文件 | 改动最小 | 代码继续膨胀 |

> **决策**: `[?]方案A(推荐)` `[?]方案B` `[?]方案C`

---

## 四、Go项目结构决策

### F. 框架选择

| 框架 | 说明 | 适合场景 |
|------|------|----------|
| **GoFrame v2** | 全栈框架，内置ORM/配置/日志/路由 | 快速开发，类似ThinkPHP的开发体验 |
| **Gin + GORM** | 轻量路由 + 独立ORM | 灵活度高，社区生态丰富 |
| **Kratos** | B站开源微服务框架 | 如果将来要拆微服务 |

> **决策**: `[?]GoFrame v2` `[?]Gin+GORM` `[?]Kratos` `[?]其他:______`

---

### G. 项目模块划分

基于现有接口，建议的Go模块划分：

```
new_sdk_go/
├── module/
│   ├── user/          # 用户：登录、注册、实名、绑定手机、忘记密码
│   ├── pay/           # 支付：下单、支付、充值、回调
│   ├── order/         # 订单：列表、详情、取消
│   ├── coupon/        # 代金券：领取、兑换、列表
│   ├── gift/          # 礼包：列表、领取
│   ├── channel/       # 渠道：查询、聚合渠道对接
│   ├── game/          # 游戏：角色上传、公告、更新
│   ├── thirdparty/    # 第三方：抖音、支付宝、微信
│   └── system/        # 系统：配置、验证码、客服
├── pkg/
│   ├── httpclient/    # 统一HTTP客户端（替代9个curl函数）
│   ├── sign/          # 签名验证（替代散落各处的签名逻辑）
│   ├── auth/          # 认证：Token、签名中间件
│   └── util/          # 工具：脱敏、格式化等
└── config/
    └── config.yaml    # 配置文件（密钥、数据库、Redis等）
```

> **决策**: `[?]同意此划分` `[?]调整为:______`

---

## 五、实施顺序决策

### H. 分期计划

| 阶段 | 内容 | 预估工作量 | 优先级 |
|------|------|-----------|--------|
| **第1期** | 项目脚手架 + 公共组件(HttpClient/签名/认证) | 2-3天 | P0 |
| **第2期** | 支付核心(下单/支付/回调) | 3-5天 | P0 |
| **第3期** | 用户体系(登录/注册/实名) | 3-4天 | P1 |
| **第4期** | 订单 + 充值 + 代金券 + 礼包 | 2-3天 | P1 |
| **第5期** | 渠道对接(聚合渠道 + 第三方) | 3-5天 | P2 |
| **第6期** | 辅助功能(公告/客服/数据查询) | 2-3天 | P3 |

> **决策**: `[?]同意此顺序` `[?]调整优先级:______`

---

## 六、确认完成后

请将确认好的文档发给我，我会根据你的决策：
1. 生成Go项目脚手架
2. 编写核心模块的接口定义(API struct)
3. 实现公共组件（HTTP客户端、签名验证、认证中间件）
4. 按优先级逐步实现各模块

---

## 快速决策汇总（填写这里）

| 编号 | 决策项 | 你的选择 |
|------|--------|----------|
| Q1 | 哪些渠道还在用？ | |
| Q2 | 弃用接口能否直接删除？ | |
| Q3 | 还在写的表有多少？ | |
| B | 路径风格 | |
| C | 版本策略 | |
| D | common.php函数 | |
| E | 支付回调方案 | |
| F | Go框架选择 | |
| G | 模块划分 | |
| H | 实施顺序 | |