祈盟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查一下哪些表还有近期写入：

-- 在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

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

六、确认完成后

请将确认好的文档发给我，我会根据你的决策：

生成Go项目脚手架
编写核心模块的接口定义(API struct)
实现公共组件（HTTP客户端、签名验证、认证中间件）
按优先级逐步实现各模块

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

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

重构决策清单.md 11 KB Cronologia Originale