Files
huang 409a68d60b
All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 5m45s
feat: OpenAPI 契约对齐与框架优化
主要变更:
1. OpenAPI 文档契约对齐
   - 统一错误响应字段名为 msg(非 message)
   - 规范 envelope 响应结构(code, msg, data, timestamp)
   - 个人客户路由纳入文档体系(使用 Register 机制)
   - 新增 BuildDocHandlers() 统一管理 handler 构造
   - 确保文档生成的幂等性

2. Service 层错误处理统一
   - 全面替换 fmt.Errorf 为 errors.New/Wrap
   - 统一错误码使用规范
   - Handler 层参数校验不泄露底层细节
   - 新增错误码验证集成测试

3. 代码质量提升
   - 删除未使用的 Task handler 和路由
   - 新增代码规范检查脚本(check-service-errors.sh)
   - 新增注释路径一致性检查(check-comment-paths.sh)
   - 更新 API 文档生成指南

4. OpenSpec 归档
   - 归档 openapi-contract-alignment 变更(63 tasks)
   - 归档 service-error-unify-core 变更
   - 归档 service-error-unify-support 变更
   - 归档 code-cleanup-docs-update 变更
   - 归档 handler-validation-security 变更
   - 同步 delta specs 到主规范文件

影响范围:
- pkg/openapi: 新增 handlers.go,优化 generator.go
- internal/service/*: 48 个 service 文件错误处理统一
- internal/handler/admin: 优化参数校验错误提示
- internal/routes: 个人客户路由改造,删除 task 路由
- scripts: 新增 3 个代码检查脚本
- docs: 更新 OpenAPI 文档(15750+ 行)
- openspec/specs: 同步 3 个主规范文件

破坏性变更:无
向后兼容:是
2026-01-30 11:40:36 +08:00

3.0 KiB
Raw Blame History

Design: 全局业务一致性修复(错误语义/文档/功能完整性)

1. 核心设计原则

  1. 对外契约一致文档OpenAPI必须描述真实线上响应结构与字段名。
  2. 业务语义一致:预期业务错误必须是 4xx + 稳定业务 code不可将“可预期失败”变成 500。
  3. 不泄露内部细节:校验细节、数据库/第三方错误细节仅写日志,不直接返回给客户端。
  4. 分层一致Handler 只做输入解析/鉴权/返回Service 输出结构化错误Store 负责数据访问。

2. 错误处理与报错规范(落地策略)

2.1 Handler 层

  • 参数解析失败:errors.New(CodeInvalidParam, "请求参数解析失败")
  • 参数校验失败:不返回 validatorerr.Error();统一返回 errors.New(CodeInvalidParam)(客户端 msg 为“参数验证失败”)。
  • 下游错误:直接 return err,交给全局 ErrorHandler。

2.2 Service 层(本次全量改造范围)

  • 禁止对外返回 fmt.Errorf(...) 作为业务错误。
  • 业务校验错误(可预期):errors.New(<4xx-code>[, message])
  • 依赖/数据库/队列错误(不可预期):errors.Wrap(<5xx-code>, err, "业务动作失败")

2.3 全局 ErrorHandler既有行为保持

  • 对 5xx统一返回映射表通用 msg避免泄露但日志保留完整 err 与上下文。
  • 对 4xx返回 AppError.Message因此 Handler/Service 必须避免把内部细节塞进 Message。

3. 限流覆盖策略

3.1 范围

  • 覆盖:/api/admin/api/h5/api/c/v1
  • 排除:/api/callback(第三方回调)、/health/ready

3.2 实现要点

  • 限流 middleware 应挂到真实 group 上,而非孤立的 /api/v1
  • 仍保留配置开关与存储后端memory/redis

4. OpenAPI 输出对齐envelope

4.1 字段名对齐

  • 错误响应:{code, data, msg, timestamp}(与运行时一致),不使用 message 字段。

4.2 成功响应结构

  • 每个接口的 200 响应在 OpenAPI 中体现 envelope
    • code: integer
    • msg: string
    • timestamp: date-time
    • data: 具体 DTO保持类型信息

备注:实现时可以在 pkg/openapi/generator.go 内构造标准 envelope schema并把 output DTO schema 嵌入到 data 属性。

5. 文档生成入口一致性

  • cmd/api/docs.gocmd/gendocs/main.go 应复用同一份“文档生成用 handlers 构造器”,避免漏 Handler 与重复维护。

6. 任务模块处理(移除)

  • 移除 /api/admin/tasks/:id 占位路由(当前返回固定 pending 且存在鉴权不一致风险)。
  • 移除未接入路由的 internal/handler/admin/task.go,避免误导。
  • Worker 侧任务处理器保留(已有业务模块会通过队列提交任务)。

7. 个人客户路由纳入文档体系

  • internal/routes/personal.go 改为使用 Register(...) 并接受 doc 参数(与其他域一致)。
  • 文档生成器 handlers 清单补齐 PersonalCustomer