Files
zt-closet-backend/.codebuddy/plans/全量代码审查_定位业务与技术逻辑_bug_6b069bbb.md
2026-09-11 01:41:52 +08:00

6.9 KiB
Raw Permalink Blame History

name, overview, todos
name overview todos
全量代码审查:定位业务与技术逻辑 bug 对项目全部 Go 源码(internal/ + pkg/ + global/ + main.go)做系统性代码审查,分模块定位业务逻辑与技术逻辑 bug,最终输出一份分类 bug 报告(含位置、原因、影响、严重程度),不做任何代码修改。
id content status
review-infra 使用 [subagent:code-explorer] 审查 main.go、global/ 与 pkg/ 基础设施及第三方集成 completed
id content status
review-dal 使用 [subagent:code-explorer] 审查 mysqlmodel、mysqldao、redismodel、redisdao 数据访问层 completed
id content status dependencies
review-money 使用 [subagent:code-explorer] 审查订单/支付/权益/配额资损链路,并用 [skill:lsp-code-analysis] 追踪关键函数调用关系 completed
review-dal
id content status dependencies
review-content 使用 [subagent:code-explorer] 审查衣物/穿搭/收藏/点赞/通知/运势/AI 等业务逻辑 completed
review-dal
id content status
review-auth 使用 [subagent:code-explorer] 审查中间件、路由与鉴权(JWT、越权、参数绑定、安全) completed
id content status dependencies
write-report 汇总各模块审查发现,输出分类中文 bug 报告(含位置、根因、影响、严重程度、建议) completed
review-infra
review-dal
review-money
review-content
review-auth

用户需求

对 /root/zt-closet-backend 智能衣橱后端服务进行全量静态代码审查,确认是否存在业务逻辑 bug 或技术逻辑 bug。

澄清结果

  1. 交付方式:仅输出一份分类的 bug 报告,不做任何代码修改。
  2. 审查范围:全部 Go 源码(internal/ + pkg/ + global/ + main.go)。

交付内容

一份中文 Markdown bug 报告,按「业务逻辑 bug」与「技术逻辑 bug」两大类组织,每条 bug 包含:文件路径与行号、问题描述、根因分析、影响、严重程度(高/中/低)、修复建议(仅建议,不实施)。报告需覆盖但不限于:订单支付退款、权益幂等发放、配额原子扣减与回退、并发与事务一致性、缓存一致性、鉴权与越权、金额/时间单位边界、错误处理与资源释放、安全(注入/越权/敏感信息泄露)等。

审查技术方案

审查方法

采用「分层 + 分域」静态审查策略,自底向上覆盖完整调用链:

  1. 基础设施层(main.go、global/、pkg/):配置加载与初始化顺序、OTel/slog 初始化、MySQL/Redis/COS/微信支付客户端初始化、优雅关闭、goroutine 调度器、错误处理与资源释放。
  2. 数据访问层(internal/mysqlmodel/、internal/mysqldao/、internal/redismodel/、internal/redisdao/):GORM 模型字段映射与索引/唯一约束、软删除、原子条件更新(RowsAffected 语义)、Redis key 设计与 TTL、分布式锁正确性(锁粒度、TTL、释放时 value 校验)。
  3. 业务服务层(internal/service/):事务边界、并发一致性、幂等性、金额单位、时间戳单位、AuthZ 归属校验、缓存一致性、错误码映射、分页边界。
  4. 接口与鉴权层(internal/middleware/、internal/routers/、internal/dto/):JWT 校验、会话降级策略、CORS、参数绑定、路由鉴权覆盖完整性。

审查重点清单

  • 资损敏感链路:订单创建(先微信下单后落库的竞态)、支付回调幂等与金额校验、退款回调、权益幂等发放、补偿任务重试、配额原子扣减/回退/发放。
  • 并发一致性:分布式锁粒度与 TTL、锁释放误删风险、MySQL 条件更新的 RowsAffected 判断、多实例定时任务防重、retry_count 更新是否基于内存快照导致覆盖。
  • 幂等性:支付回调、退款回调、权益发放、补偿任务崩溃恢复(benefitAlreadyGranted 流水查重)。
  • 边界与单位:金额单位(分/元)、时间单位(秒/毫秒)、分页上限、切片越界/空指针、字符串截断(genOrderNo/genRefundNo 取 UUID 前 16 位)。
  • 安全:SQL 注入(GORM 参数绑定)、越权访问(getOwnedOrder 等归属校验是否完整覆盖)、日志敏感信息(openid/金额)、JWT 会话 Redis 故障降级放行的安全权衡。
  • 资源与性能:context 超时、goroutine 泄漏、Redis/DB 连接与 body 释放、N+1 查询、缓存穿透/击穿。

报告格式

最终输出一份中文 Markdown bug 报告,结构如下:

  • 「业务逻辑 bug」章节:业务规则、状态流转、权益/资损、幂等、越权相关缺陷。
  • 「技术逻辑 bug」章节:并发、事务、缓存、错误处理、资源管理、边界条件、安全相关缺陷。
  • 每条含:文件:行号、问题描述、根因、影响、严重程度(高/中/低)、修复建议。

严重程度定义:

  • 高:资损、数据丢失、越权、严重并发不一致、安全漏洞。
  • 中:功能错误、边界异常、异常处理缺失、缓存不一致。
  • 低:代码质量、潜在风险、性能隐患、维护性问题。

审查覆盖范围

/root/zt-closet-backend
├── main.go                      # 初始化与调度器启动
├── global/                      # 全局配置与连接(5 文件)
├── internal/
│   ├── service/                 # 业务编排(16 文件)
│   ├── mysqldao/                # MySQL DAO(14 文件)
│   ├── redisdao/                # Redis DAO 含锁(10 文件)
│   ├── mysqlmodel/              # GORM 模型(18 文件)
│   ├── redismodel/              # Redis 模型与 key(11 文件)
│   ├── dto/                     # 请求/响应 DTO(13 文件)
│   ├── middleware/              # JWT/CORS/日志/OTel(5 文件)
│   └── routers/                 # 路由与 handler(13 文件)
└── pkg/                         # 工具与第三方封装(29 文件)

使用的扩展

SubAgent

  • code-explorer
  • 用途:对 internal/、pkg/、global/、main.go 等全部源码进行跨文件、跨目录的系统性读取与搜索,定位每个业务域的实现细节、调用关系与潜在缺陷。
  • 预期产出:各模块的审查发现清单(文件路径 + 行号 + 疑似问题描述),供汇总阶段整理为最终报告。

Skill

  • lsp-code-analysis
  • 用途:对资损敏感链路的几个关键函数(如 consumeQuota、refundQuota、grantQuota、grantBenefitIdempotent、retryBenefitTask、OrderUpdateStatusByOrderNo)做语义级定义/引用/调用层次追踪,验证并发、事务与幂等逻辑是否安全。
  • 预期产出:关键函数完整调用链与引用点,支撑并发/幂等结论的准确判断。