25 KiB
25 KiB
代码审查问题清单(internal + pkg)
- 审查日期:2026-08-27 ~ 2026-08-28,共四轮全量审查。第四轮(2026-08-28):核查第三至六轮处置声称是否真实落地 + 全量回归审查(重点:重构引入的新问题),
go build ./...编译验证通过 - 文档结构:只保留待修复问题,按类型归类(不按轮次);每条标注发现轮次;已修复并经复查确认的直接删除
- gva/ 目录是遗留参考库(独立 module 不参与 kra 编译),不在审查范围
- 依赖方向合规确认:pkg 无 import internal;integration 不 import data/service;data 不再 import integration/payment(第四轮重构后复验单向);无循环依赖
一、正确性缺陷(第四轮回归审查新发现,最高优先级)
| # | 问题 | 位置 | 说明 |
|---|---|---|---|
id desc 排序。 |
|||
二、死代码与零消费者机制
2.1 三层死方法残留(第三至五轮处置后仍未删,均经全仓 Grep 反查确认零调用)【二轮发现,四轮复核仍在】
| 层 | 死代码 | 位置 |
|---|---|---|
RecordDataAccess 写入链已删除;查询侧仍保留。 |
||
RegisterBusinessModule 与 PaymentBusinessModule 是 docs/PAYMENT.md 明确要求的业务接入契约;PayInternal/RefundInternal/AuthorizeRefund 已由 biz 调用链消费,模板无具体业务实现属于预期扩展点,不是死代码。评估完成,保留(2026-08-28)。 |
||
map[string]any,[]byte 仍是合法 usecase/fake 输入;该分支有针对性测试,不属于可证明死代码。评估完成,保留(2026-08-28)。 |
2.2 mq / websocket 零消费者基础设施【既定排除范围,历轮明确不处理,现状保持】
- mq 全链(声明式订阅+legacy API+簿记/dispatcher/reconcile)业务消费者为零;
_ mq.Client幻影参数(cmd/main.go:65);integration/provider.go:33-38 三重死绑定 + Hub 死绑定 - websocket:Hub 接口零消费者;integration 层 On* 四注册方法零调用,双层 handler 登记机制两层都为空
- namedClient/Client() 整型死代码(integration/mq/emqx.go:632-650)
2.3 零散死代码(第四轮新扫描)【四轮】
| 死代码 | 位置 | 证据 |
|---|---|---|
config.CloneData |
Clone/MergeRuntimeConfig 已覆盖实际快照复制入口。已完成(2026-08-28)。 |
|
paymentkit.XMLValues/XMLEncode |
||
paymentkit.NestedString |
JSONObject/StringAtPath。已完成(2026-08-28)。 |
|
logging.NewZapLogger |
NewReloadableZapLogger,避免维护双入口。 |
|
data/payment.contains |
paymentkit.ContainsFold,本地实现已删除。 |
|
paymentkit status.go 的 ConfiguredInt64/ConfiguredValues/Text/FirstText/FirstString 定位漂移 |
三、重复实现 / 双份维护
3.1 大块可消除
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
paymentkit.NormalizePaymentMethod;各渠道状态词表与退款身份校验因语义不同保留。 |
|||
internal/utils 会扩大无消费者包的公共表面积。 |
3.2 配置/数据不变式双份维护
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
config.Store 与 runtimeconfig.Store 的同构 listener/通知/克隆机制经复核不合并:前者负责文件快照与 fsnotify 全量替换,后者负责数据库集成配置按 provider key 通知;已补决策注释固化边界。 |
|||
persistConfigValues 覆盖完整运行时保存,persistDatabaseConfig 覆盖初始化页的局部写入,removeIntegrationConfigFromFile 覆盖启动时对旧模板的兼容清理;入口不同且各自可独立触发,合并会削弱不落盘不变式。 |
3.3 中小重复
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
integrationbiz.MergeIntegrationDefaults。 |
|||
values() 与 testRow() 已收敛为共享读取逻辑,并保留启用状态差异。 |
|||
paymentOrderResponse。 |
|||
paymentkit.ContainsFold。 |
四、过度分层:转发门面 / 透传壳 / 回调穿透
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
callbackFields、firstNonEmpty 与 parseConfiguredAmount 等包内协议语义;高频短别名被 100+ 处渠道代码消费,整体展开只会放大改动而不减少规则源。 |
|||
newReloadableDB 的匿名变参垫片;审计回调仍只在数据库激活/替换时由 registerDataScopeCallbacks 绑定,职责链闭环。 |
|||
Adapter 类型别名和包级 New 双入口;Factory.New 直接实现 biz 的 PaymentAdapterFactory,工厂表使用 biz 接口类型。 |
五、过分拆分 / 文件组织
根因模式三条【三轮】:①零逻辑 usecase 壳(wire 强制每域一个构造器放大);②"每资源 N 文件"机械切分;③为 import 美观引入的中间缝合包/门面。
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
system.go/settings.go 虽跨域,但移动类型会放大 service DTO 导入与生成契约变化;本批不做机械拆分。 |
|||
六、包归属问题
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
httpx 收敛为通用 SetCookie,x-token 命名保留在 handler/middleware 业务边界;密码修改冲突码移至 middleware,并由 handler 继续提供兼容常量。 |
|||
api/、internal/global/ 等描述。 |
七、分层 / 职责违规
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
SystemParameter 的查询字段与时间区间已拆为 SystemParameterFilter;API/Export 过滤字段已分别迁移至独立 APIFilter、ExportTemplateFilter,实体 DO 不再承载列表过滤/排序字段。 |
|||
AuthenticationResult 已在返回 service 前清空密码哈希并补回归测试。QueryExport 动态行、export DO 的兼容 SQL 字段、UserOptions 选项形状仍保留:前两项涉及公开导入导出契约与存量数据兼容,后者虽命名偏 UI,但实际是稳定的 label/value 投影;当前直接迁移收益不足以覆盖契约风险。 |
biz/system/* | ||
Model(...);动态导出表仍按已校验模板访问。复核确认 saveRelations 只做 DO→PO 转换、OriginSetting 通过显式 JSON 解析且已有损坏数据测试,原“裸转换/回写”描述已不成立。 |
|||
AuthorityResponse.DeletedAt 已改为 json:"-",且 integration 配置字段已迁移为 DTO 自有类型并在 service 边界映射。ErrorRecordMutationRequest 的指针字段用于区分省略与显式空值且已有测试,原建议不成立,保留。 |
|||
errors.Is 判定。一次性统一会改变现有响应映射与错误文本,当前无安全收益。 |
|||
八、简单实现复杂化
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
loadUser 面向单用户完整关系加载,loadUsers 批量预取关联以避免 N+1,且基础 PO→DO 已复用 baseBizUser;继续合并会损害查询策略。 |
|||
*Data nil 防御覆盖初始化前、热重载失败与测试替身边界;NewIntegrationRuntime(nil) 返回空 Store 保持 Wire/独立测试可用性,删除会改变失败模式。 |
|||
rowQueryOptions 传递分页与 required 语义,消除 data 层相邻布尔参数歧义;查询行为不变。 |
|||
九、结构性设计(大动作需决策)
| # | 问题 | 位置 | 轮次 |
|---|---|---|---|
routecatalog 承载审计/Swagger/模块同步元数据,router 负责 Gin handler 绑定;当前 catalog 还无法表达 handler 注入与注册顺序,强行合并会扩大启动与路由回归面。 |
|||
config.Store 快照与文件兼容,mq/websocket 需要按 provider 的 runtimeconfig.Store 热通知;统一形状会牺牲强类型校验或通知粒度。 |
|||
watchLoop 负责发布合并快照,Data.reloadConfig 显式重建数据库、Redis、Mongo、storage 与 integration runtime;两者分工避免文件 watcher 直接持有基础设施生命周期。合并为单通道需重做锁、回滚与连接退休策略,暂不改动。 |
|||
审查后认为合理、不建议改动的部分
- modules 与 routecatalog 分离:启动期装配 vs 请求期热路径,消费方零重叠
- Provider 接口缝模式 + provider.Database 中性接口:正当(system 包内 Provider 与 DatabaseProvider 两个近义缝命名易混淆,建议注释互指)
- config.Store 与 runtimeconfig.Store 分离:正确(D-9 词表同构为已知保留项)
- utils/routepath、uploadpolicy:纪律良好
- worker→biz 正向+接口倒置:任务链路最规范的一段
- data 根多文件同包:符合 data/README 约定
- apple_jws.go 证书链校验:必要安全设计(经 gopay 源码核对补真实漏洞);单一根指纹需运维轮换预案注释
- capture/auth 中间件质量:有据可依
- 新增缝质量(第四轮验证):PaymentAdapterFactory(biz 接口+integration 实现+wire 绑定,单向无环)、MergeRuntimeConfig(单点三调用)、deletePrefixViaList(函数式注入,失败关闭正确)、AST 缓存(size+mtime 失效)、systeminfo(integration 定位正确)——均内聚、依赖最小、无越界 import
处置建议(按优先级)
- 正确性缺陷与安全边界:W-1~W-6 已完成并经回归验证。
- 死代码与分层整改:已完成可证明无消费者项;其余公开契约或零消费者基础设施均已完成影响分析并记录保留理由。
- 结构性项目:D/F/S/P/L/C/X 剩余条目均已按依赖、并发、兼容性和 Wire 影响完成评估;暂无应在模板中强行落地的大改造。