huang
409a68d60b
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 5m45s
主要变更： 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 个主规范文件 破坏性变更：无 向后兼容：是
64 lines
3.0 KiB
Markdown
64 lines
3.0 KiB
Markdown
# Design: 全局业务一致性修复（错误语义/文档/功能完整性）
|
||
|
||
## 1. 核心设计原则
|
||
|
||
1) 对外契约一致：文档（OpenAPI）必须描述真实线上响应结构与字段名。
|
||
2) 业务语义一致：预期业务错误必须是 4xx + 稳定业务 code；不可将“可预期失败”变成 500。
|
||
3) 不泄露内部细节：校验细节、数据库/第三方错误细节仅写日志，不直接返回给客户端。
|
||
4) 分层一致：Handler 只做输入解析/鉴权/返回；Service 输出结构化错误；Store 负责数据访问。
|
||
|
||
## 2. 错误处理与报错规范（落地策略）
|
||
|
||
### 2.1 Handler 层
|
||
- 参数解析失败：`errors.New(CodeInvalidParam, "请求参数解析失败")`。
|
||
- 参数校验失败：**不返回** `validator` 的 `err.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.go` 与 `cmd/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`。
|