创建仓库
This commit is contained in:
259
Go项目实战/03_基础设施/01_错误处理/01_基础设施详细设计规格说明书.md
Normal file
259
Go项目实战/03_基础设施/01_错误处理/01_基础设施详细设计规格说明书.md
Normal file
@@ -0,0 +1,259 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 🏗️ Infrastructure Design Specifications (v1.2)
|
||||
- 🏗️ Infrastructure Design Specifications (v1.1)
|
||||
- 🏗️ Infrastructure Design Specifications (v1.0)
|
||||
date created: 星期三, 十二月 10日 2025, 9:41:53 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 10:37:49 上午
|
||||
---
|
||||
|
||||
# 🏗️ Infrastructure Design Specifications (v1.2)
|
||||
|
||||
项目名称: Enterprise-CMS-Core
|
||||
|
||||
模块: Infrastructure (Error Handling & Response)
|
||||
|
||||
版本: 1.2.0 (Refined)
|
||||
|
||||
状态: [✅ 已锁定]
|
||||
|
||||
---
|
||||
|
||||
## 1. 设计目标 (Design Objectives)
|
||||
|
||||
本模块旨在构建一套**统一的、类型安全的、框架解耦**的 HTTP 响应与错误处理机制。
|
||||
|
||||
- **统一性:** 无论成功与否，API 必须返回结构一致的 JSON Envelope。
|
||||
- **可观测性:** 错误必须携带业务语义（ErrorCode），而非仅返回 HTTP 500。
|
||||
- **解耦性:** 业务逻辑层 (Service) 不感知 HTTP 框架 (Gin)，仅通过 Go 原生 `error` 接口交互。
|
||||
- **高内聚:** 错误码定义与错误实体封装在同一包内，减少调用摩擦。
|
||||
|
||||
---
|
||||
|
||||
## 2. 技术选型基线 (Tech Stack Baseline)
|
||||
|
||||
|**组件**|**选型**|**约束说明**|
|
||||
|---|---|---|
|
||||
|**HTTP Context**|`github.com/gin-gonic/gin`|仅在 `internal/pkg/app` (Level 1) 和 `handler` 层使用。**严禁**在 `service` 层引入。|
|
||||
|**Error Handling**|Go Standard Library|使用 Go 1.13+ `errors` (`Is`, `As`, `New`) 和 `fmt.Errorf`。**严禁**引入第三方 error 库 (如 `pkg/errors`)。|
|
||||
|**Serialization**|`encoding/json`|使用标准库。MVP 阶段暂不引入 `json-iterator`。|
|
||||
|**Concurrency**|`sync.RWMutex`|用于保护错误码 Map 的并发读取（读多写少场景）。|
|
||||
| **Tracing** | Gin Keys | Trace ID 必须由前置中间件（或网关）注入。Gin Context Key 约定为 `"X-Trace-ID"`。 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心设计模式 (Design Patterns)
|
||||
|
||||
### 3.1 响应封装：Context Object & Factory
|
||||
|
||||
采用 **“上下文对象”** 模式对 `gin.Context` 进行封装，提供链式调用的体验。
|
||||
|
||||
- **模式:** `app.New(c).Success(data)`
|
||||
- **优势:** 屏蔽底层框架差异，统一入口。
|
||||
|
||||
### 3.2 错误处理：安全与动态机制 (Security & Dynamics)
|
||||
|
||||
- **双层信息架构:**
|
||||
- **User Msg (Safe):** JSON Body 中的 `msg` 字段。**仅**允许返回 `ecode` 中定义的静态文案，或经过白名单过滤的动态参数（如参数名）。
|
||||
- **Log Detail (Unsafe):** 服务端日志。必须记录完整的 `err.Error()`（包含堆栈、SQL 错误、`fmt.Errorf` 包装的底层原因）。
|
||||
- **动态文案支持:**
|
||||
- `ecode` 包需提供 `WithMsg(msg string)` 或 `WithDetails(args …any)` 方法，用于**安全地**覆盖默认文案。
|
||||
- **示例:** `return ecode.InvalidParams.WithMsg("Email 格式错误")`。
|
||||
|
||||
### 3.3 状态码管理：Centralized Registry
|
||||
|
||||
采用 **“集中式注册表”** 模式。
|
||||
|
||||
- **约束:** 所有业务错误码 (Business Code) 必须在 `internal/pkg/ecode` 包中定义为 `const`。
|
||||
- **禁止:** 严禁在业务代码中硬编码数字（Magic Number）。
|
||||
|
||||
### 3.4 错误码号段分配：Error Code Allocation
|
||||
|
||||
结构定义:
|
||||
|
||||
错误码采用 5 位数字结构：A BB NN
|
||||
|
||||
- **A (万位):** 模块/领域 (1=Infra, 2=User, 3=Content…)
|
||||
- **BB (千百位):** 组件/子模块分类
|
||||
- **NN (十个位):** 具体错误流水号
|
||||
|
||||
#### 1. 基础设施层 (System / Infra) - `10000 - 19999`
|
||||
|
||||
针对基础设施，**必须**严格遵守以下二级分类，严禁混用：
|
||||
|
||||
|**二级区间 (Sub-Range)**|**组件归属 (Component)**|**典型示例 (Examples)**|
|
||||
|---|---|---|
|
||||
|**10000 - 10099**|**Server General**|`10000` (Success), `10001` (Unknown Error), `10002` (Panic Recovered)|
|
||||
|**10100 - 10199**|**Database (Internal)**|`10100` (DB Connection Lost), `10101` (SQL Syntax Error) - _注意：业务查空属业务码，不在此列_|
|
||||
|**10200 - 10299**|**Cache (Redis)**|`10200` (Redis Timeout), `10201` (Key Evicted Unexpectedly)|
|
||||
|**10300 - 10399**|**Serialization**|`10300` (JSON Marshal Failed), `10301` (Invalid Request Body)|
|
||||
|**10400 - 10499**|**Middleware/Gateway**|`10400` (Too Many Requests/Rate Limit), `10401` (Route Not Found)|
|
||||
|**10500 - 10599**|**3rd Party API**|`10500` (External Service Unavailable), `10501` (SMS Send Failed)|
|
||||
|
||||
#### 2. 业务模块层 (Business Modules) - `20000+`
|
||||
|
||||
业务模块建议参考同等逻辑进行二级划分（由各模块负责人定义，但建议遵循以下范式）：
|
||||
|
||||
|**一级区间**|**模块**|**二级区间示例**|
|
||||
|---|---|---|
|
||||
|**20000 - 29999**|**User / Auth**|`200xx` (基础账户), `201xx` (登录/Token), `202xx` (RBAC 权限), `203xx` (KYC 认证)|
|
||||
|**30000 - 39999**|**Content (CMS)**|`300xx` (文章), `301xx` (分类/标签), `302xx` (评论), `303xx` (审核流)|
|
||||
|
||||
---
|
||||
|
||||
## 4. 交互协议与数据流 (Interaction Protocol)
|
||||
|
||||
### 4.1 JSON 响应契约 (The Contract)
|
||||
|
||||
所有 HTTP 接口返回的 Body 必须符合以下结构：
|
||||
|
||||
```JSON
|
||||
{
|
||||
"code": 20001, // 业务状态码 (0=成功, 非0=错误)
|
||||
"msg": "用户已存在", // 开发者提示/用户提示
|
||||
"data": { … }, // 业务数据 (成功时为 Object/Array, 失败时为 null)
|
||||
"trace_id": "abc-123" // 必填。取值优先级: c.GetHeader("X-Trace-ID") -> c.GetString("X-Trace-ID") -> UUID生成
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 HTTP 状态码策略 (Status Code Policy)
|
||||
|
||||
本项目采用 **"Hybrid 策略 "**：
|
||||
|
||||
- **HTTP 200 OK:**
|
||||
- 所有 **业务逻辑错误** (Code `2xxxx` - `4xxxx`)。
|
||||
- 前端通过 Body 中的 `code != 0` 判断业务异常。
|
||||
- _理由:_ 避免网关（如 Nginx）拦截 4xx 响应并替换为默认错误页，导致前端拿不到 JSON 数据。
|
||||
- **HTTP 500 Internal Server Error:**
|
||||
- 所有 **基础设施错误** (Code `1xxxx`)，包括 Panic、数据库断连、Redis 超时。
|
||||
- _理由:_ 触发云厂商负载均衡器 (LB) 的熔断机制，将流量切出故障节点。
|
||||
- **HTTP 401/403:**
|
||||
- 仅用于网关层面的拦截（如 JWT 格式错误），业务层鉴权失败建议走 HTTP 200 + Code `20101`。
|
||||
|
||||
### 4.3 跨层交互时序 (Cross-Layer Flow)
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant C as Controller (Handler)
|
||||
participant S as Service (Domain)
|
||||
participant I as Infra (pkg/app)
|
||||
participant E as Ecode (pkg/ecode)
|
||||
|
||||
C->>I: app.New(c) 初始化
|
||||
C->>S: Call Business Logic
|
||||
alt 成功
|
||||
S-->>C: return (data, nil)
|
||||
C->>I: app.Success(data)
|
||||
I-->>Client: JSON {code:0, data:…}
|
||||
else 失败 (业务错误)
|
||||
S-->>C: return (nil, ecode.New(20001))
|
||||
C->>I: app.Error(err)
|
||||
I->>I: errors.As(err) -> 提取 Code 20001
|
||||
I-->>Client: JSON {code:20001, msg:"…"}
|
||||
else 失败 (系统错误)
|
||||
S-->>C: return (nil, errors.New("DB error"))
|
||||
C->>I: app.Error(err)
|
||||
I->>I: errors.As(err) -> 失败 (Fallback)
|
||||
I-->>Client: JSON {code:50000, msg:"Internal Error"}
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 目录结构与职责 (Directory & Responsibilities)
|
||||
|
||||
```Plaintext
|
||||
internal/
|
||||
├── middleware/ # [New] 全局中间件
|
||||
│ ├── recovery.go # Panic 捕获 -> 转换为 ecode.ServerError (50000)
|
||||
│ └── not_found.go # 404 捕获 -> 转换为 ecode.NotFound (40400)
|
||||
│
|
||||
└── pkg/
|
||||
├── ecode/ # [Level 0] 错误核心包 (无内部依赖)
|
||||
│ ├── code.go # const 常量定义 (UserNotFound = 20001)
|
||||
│ ├── msg.go # 错误码文案映射 (Map & GetMsg)
|
||||
│ └── error.go # Error 结构体定义 (New, Parse 方法)
|
||||
│
|
||||
└── app/ # [Level 1] HTTP 响应封装 (依赖 gin, ecode)
|
||||
└── response.go # NewResponse, Success, Error 方法
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 开发规范与 Linter 规则 (Linting Rules)
|
||||
|
||||
1. **包引用原则:**
|
||||
|
||||
- `ecode` 包必须保持零依赖（只依赖标准库）。
|
||||
- `app` 包依赖 `ecode`。
|
||||
|
||||
2. **Service 层纯净性:**
|
||||
|
||||
- `internal/domain/service` 代码中**严禁出现** `import "github.com/gin-gonic/gin"`。
|
||||
- `internal/domain/service` 代码中**严禁出现** `import "enterprise-cms-core/internal/pkg/app"`。
|
||||
- 只允许引入 `internal/pkg/ecode`。
|
||||
|
||||
3. **错误包装与响应清洗:**
|
||||
|
||||
- **Log:** `app.Error(err)` 内部必须将 `err` 的完整堆栈打印到 Zap 日志中。
|
||||
- **Response:**
|
||||
- 若 `err` 可被断言为 `*ecode.Error`，则取其 `Msg` 字段返回。
|
||||
- 若 `err` 仅为普通 `error` (如 DB error)，**严禁**直接将其内容返回给前端，必须统一兜底返回 `ecode.ServerError` 的文案（"Internal Server Error"）。
|
||||
|
||||
4. **全局兜底机制 (Global Safety Net):**
|
||||
- 项目必须在 `internal/middleware` 中实现 `Recovery` 中间件。
|
||||
- **严禁**让 Gin 默认的 Panic 堆栈直接输出到 HTTP Body。
|
||||
- **必须**捕获所有 Panic，并调用 `app.Error(ecode.ServerError)` 统一输出为符合 JSON 契约的格式 (`{"code": 50000, "msg": "Internal Server Error", …}`)。
|
||||
|
||||
---
|
||||
|
||||
## 7. 工程化实施标准 (Engineering Standards)
|
||||
|
||||
### 7.1 代码风格契约 (Code Style Contract)
|
||||
|
||||
为确保代码长期可维护，生成的代码必须严格遵守以下 Go 惯用语 (Idioms)：
|
||||
|
||||
1. **命名规范:**
|
||||
- **缩写:** 使用全大写缩写 (如 `ServeHTTP`, `ID`, `URL`)，严禁 `Url`, `Id`。
|
||||
- **局部变量:** 保持短小 (如 `ctx`, `err`, `req`)，避免 Java 式的长命名 (如 `requestContext`, `errorObject`)。
|
||||
- **工厂方法:** `ecode` 包内使用 `New()`, `app` 包内使用 `NewResponse()`。
|
||||
|
||||
2. **代码组织:**
|
||||
- **Import 分组:** 标准库 -> 第三方库 -> 内部库 (enterprise-cms-core/…)。
|
||||
- **Guard Clauses:** 优先使用“卫语句”提前返回，减少 `else` 嵌套层级。
|
||||
|
||||
### 7.2 注释与文档 (Documentation)
|
||||
|
||||
为了提升团队协作效率，所有 Exported (首字母大写) 的类型、函数、常量必须包含符合 GoDoc 规范的**中文注释**。
|
||||
|
||||
- **格式规范:** `// FunctionName 中文描述…`
|
||||
- **关键:** 注释**必须**以函数/变量名开头，且与中文描述之间**保留一个空格**。这是 Go 官方工具链解析文档的标准要求。
|
||||
- **内容重心:**
|
||||
- **摘要:** 第一行简明扼要地说明“它是做什么的”。
|
||||
- **详情 (可选):** 解释 **"Why" (设计意图)** 和 **"Caveats" (副作用/注意事项)**，而非翻译代码逻辑。
|
||||
- **示例:**
|
||||
|
||||
```Go
|
||||
// Success 向客户端写入标准的 JSON 成功响应。
|
||||
//
|
||||
// 注意:
|
||||
// 1. 无论业务逻辑如何，此方法会将 HTTP 状态码强制设置为 200。
|
||||
// 2. data 字段若为 nil，将序列化为 JSON 的 null。
|
||||
func (r *Response) Success(data any) { … }
|
||||
|
||||
// UserNotFound 表示用户不存在的业务错误码 (20001)。
|
||||
const UserNotFound = 20001
|
||||
```
|
||||
|
||||
### 7.3 可扩展性设计 (Extensibility Patterns)
|
||||
|
||||
为了应对未来需求变更，本模块需采用以下模式：
|
||||
|
||||
1. **Functional Options (针对 `app` 包):**
|
||||
- 构造 `Response` 对象时，应支持 Option 模式，以便未来无需破坏函数签名即可添加新字段（如 TraceID, DebugInfo）。
|
||||
- *定义:* `type Option func(*Response)`
|
||||
- *签名:* `func New(c *gin.Context, opts …Option) *Response`
|
||||
|
||||
2. **Interface Segregation (接口隔离):**
|
||||
- 虽然 `ecode` 是基础值对象，但 `app` 层若涉及复杂逻辑，应定义 `Responder` 接口，方便 Mock 测试。
|
||||
247
Go项目实战/03_基础设施/01_错误处理/02_AI 辅助基础设施构建 SOP (v2.1) -错误处理与响应篇.md
Normal file
247
Go项目实战/03_基础设施/01_错误处理/02_AI 辅助基础设施构建 SOP (v2.1) -错误处理与响应篇.md
Normal file
@@ -0,0 +1,247 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 🏗️ AI 辅助基础设施构建 SOP (v2.1) - [错误处理与响应篇]
|
||||
- 🏗️ AI 辅助基础设施构建 SOP (v2.0) - [错误处理与响应篇]
|
||||
- 🏗️ AI 辅助基础设施构建 SOP (v1.1) - [错误处理与响应篇]
|
||||
- 🏗️ AI 辅助基础设施构建 SOP (v1.0) - [错误处理与响应篇]
|
||||
date created: 星期三, 十二月 10日 2025, 12:34:57 凌晨
|
||||
date modified: 星期三, 十二月 10日 2025, 11:55:08 中午
|
||||
---
|
||||
|
||||
# 🏗️ AI 辅助基础设施构建 SOP (v2.1) - [错误处理与响应篇]
|
||||
|
||||
**核心理念:**
|
||||
|
||||
1. **Contract First (契约优先):** 永远先定义对外暴露的 JSON 结构，再写内部 Go 结构体。
|
||||
2. **DX Driven (体验驱动):** 在实现逻辑前，先写“伪代码”验证调用是否顺手。
|
||||
3. **Atomic Delivery (原子交付):** 单次交互只生成一个文件，利用“上下文锚点”串联上下文。
|
||||
|
||||
---
|
||||
|
||||
## 📋 准备工作：变量与架构确认
|
||||
|
||||
在使用以下 Prompt 前，请确认上下文：
|
||||
|
||||
- `{语言/框架}`: Go 1.24+ / Gin
|
||||
- `{模块路径}`:
|
||||
- `internal/pkg/ecode` (Level 0: 错误码 + 错误实体 + 映射逻辑)
|
||||
- `internal/pkg/app` (Level 1: HTTP 响应封装，依赖 `ecode`)
|
||||
- `{架构约束}`: `ecode` 包零依赖；`app` 包依赖 `ecode`。
|
||||
|
||||
---
|
||||
|
||||
## Phase 0: 原子化任务拆解 (The MECE Protocol)
|
||||
|
||||
**目的:** 将大需求拆解为一组符合 MECE 原则的微任务清单。
|
||||
|
||||
### 🤖 拆解者 Prompt (复制使用)
|
||||
|
||||
```Markdown
|
||||
你现在是我的 **Tech Lead (技术负责人)**。
|
||||
我们要实现 `{模块名称}` 模块。为了防止代码生成中断和逻辑混乱，请不要直接开始写代码。
|
||||
|
||||
请先执行 **“MECE 任务拆解”**：
|
||||
|
||||
**1. 架构约束分析:**
|
||||
- 本模块遵循 Modular Clean Architecture。
|
||||
- `internal/pkg/ecode`: 包含错误码常量、错误实体结构体、错误文案映射。**严禁依赖上层包**。
|
||||
- `internal/pkg/app`: 包含 Gin 的 Response 封装。依赖 `ecode`。
|
||||
|
||||
**2. 原子化切分:**
|
||||
请将开发工作拆解为 3-5 个“原子任务步”。
|
||||
- 每个步骤必须针对**单个物理文件**。
|
||||
- 步骤必须遵循依赖顺序（底层先于上层）。
|
||||
|
||||
**3. 输出格式:**
|
||||
请输出一个 **Markdown Checklist (执行清单)**。
|
||||
格式示例：
|
||||
- [ ] **Step 1: {文件名}** - {核心职责} (依赖: 无)
|
||||
- [ ] **Step 2: {文件名}** - {核心职责} (依赖: Step 1)
|
||||
…
|
||||
|
||||
**模块需求:**
|
||||
我们需要一套统一的 HTTP 错误处理机制，支持自定义业务错误码，统一返回 JSON 格式。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 0.5: API 签名锁定 (API Surface Lock)
|
||||
|
||||
**目的:** 在实现具体逻辑前，强制锁定所有 Public 方法的签名，防止实现阶段出现参数不一致。
|
||||
|
||||
### 🤖 Prompt 0.5: 生成接口定义
|
||||
|
||||
**[发送给 AI]:**
|
||||
|
||||
````markdown
|
||||
在开始写代码前，请先为 `internal/pkg/app` 包定义 **Public API 签名 (Exported Functions)**。
|
||||
请直接提供 `Responder` 接口定义或核心函数的函数头（无需函数体）。
|
||||
|
||||
**要求:**
|
||||
1. **一致性:** 确认 `context` 参数的位置（建议统一作为第一个参数）。
|
||||
2. **完整性:** 必须包含 `New`, `Success`, `Error` 以及我们刚才讨论的 `ErrorCtx` (处理 trace_id)。
|
||||
3. **Go Doc:** 为每个方法写出符合 Go 标准的注释。
|
||||
|
||||
**期望输出示例:**
|
||||
|
||||
```go
|
||||
// Response wraps the gin.Context for unified JSON response.
|
||||
type Response struct { … }
|
||||
|
||||
// New creates a new Response wrapper.
|
||||
func New(c *gin.Context) *Response { … }
|
||||
|
||||
// Success sends a successful response with data.
|
||||
func (r *Response) Success(data any) { … }
|
||||
```
|
||||
````
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: 契约定义 (Contract Definition)
|
||||
|
||||
**目的:** 确立“对外口径”。
|
||||
|
||||
### 🤖 Prompt 1: 定义 JSON 结构 (复制使用)
|
||||
|
||||
```Markdown
|
||||
你现在是我的 **API 治理专家**。
|
||||
请设计一套统一的 **HTTP 响应结构 (JSON Envelope)**。
|
||||
|
||||
**设计原则:**
|
||||
1. **统一性:** 无论成功还是失败，Body 结构一致。
|
||||
2. **字段要求:** 必须包含 `code` (int), `msg` (string), `data` (any), `trace_id` (string)。
|
||||
|
||||
**任务:**
|
||||
请给出以下 3 种场景的 JSON 响应示例，并解释设计理由：
|
||||
- 场景 A: 成功返回对象。
|
||||
- 场景 B: 成功返回空列表 (明确 `data` 是 `null` 还是 `[]`)。
|
||||
- 场景 C: 业务错误 (如 Code 20001)。
|
||||
|
||||
**[关键补充约束]**
|
||||
1. **安全性优先:** `app.Error(err)` 处理逻辑中，必须区分**用户可见文案**和**底层调试信息**。若 `err` 包含底层堆栈（如 SQL 错误），JSON 中的 `msg` 必须降级显示为 `ecode` 定义的通用文案（如 "Internal Error"），严禁透传底层 Error String。
|
||||
2. **HTTP 状态码:** 本项目强制执行 **"HTTP 200 OK + Business Code"** 策略。除非 Gin 框架层崩溃，否则 HTTP Status 永远为 200。
|
||||
3. **Trace ID:** 假设 `c.GetString("trace_id")` 可以获取 ID，请在 `app.New(c)` 时将其注入 Response 结构体。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: 体验验证 (DX Verification)
|
||||
|
||||
**目的:** 模拟业务层调用，防止基础设施“反人类”。
|
||||
|
||||
### 🤖 Prompt 2: 伪代码验证 (复制使用)
|
||||
|
||||
```Markdown
|
||||
JSON 结构已确认。
|
||||
假设我们已经有了 `internal/pkg/ecode` 和 `internal/pkg/app`。
|
||||
|
||||
请写一段 Gin Handler 的 **伪代码 (Pseudo-code)**，展示开发者该如何使用它们。
|
||||
|
||||
**验证重点:**
|
||||
1. **业务错误:** 如何返回 `ecode.New(20001, "…")`？
|
||||
2. **响应封装:** 如何调用 `app.New(c).Success(data)`？
|
||||
3. **代码简洁性:** 避免大量的 `if err != nil` 重复代码。
|
||||
|
||||
请展示最优雅的写法。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: 迭代式核心实现 (Iterative Implementation)
|
||||
|
||||
**核心机制:** 这是一个**循环步骤**。请查看 Phase 0 生成的 Checklist，**逐个文件**执行。
|
||||
|
||||
### 🔄 循环动作 A: 生成代码
|
||||
|
||||
**[用户动作]:** 复制 Checklist 中当前未完成的步骤（例如 "Step 1: 生成 ecode/code.go"）。
|
||||
|
||||
**[发送 Prompt]:**
|
||||
|
||||
```Markdown
|
||||
我们现在执行 **Step {N}**。
|
||||
|
||||
**任务目标:**
|
||||
{粘贴 Phase 0 Checklist 中的当前步骤描述}
|
||||
|
||||
**上下文约束 (严禁修改):**
|
||||
1. **JSON 契约:** `{粘贴 Phase 1 确认的 JSON}`
|
||||
2. **DX 规范:** `{粘贴 Phase 2 确认的伪代码}`
|
||||
3. **依赖控制:** 如果是 `ecode` 包，严禁引用 `app` 或 `gin`。
|
||||
|
||||
**输出要求:**
|
||||
请仅生成该步骤对应的 `{文件名}` 源代码。不要生成测试代码。
|
||||
|
||||
**通用代码质量约束 (Linter Rules):**
|
||||
1. **注释规范:** 所有 Exported (首字母大写) 的结构体、函数、常量必须包含符合 Go Doc 规范的注释。
|
||||
2. **复杂度控制:** 确保 `gocyclo` (圈复杂度) 低于 10。如果逻辑复杂，请拆分为私有函数。
|
||||
3. **错误检查:** 严禁忽略 error 返回值（如 `json.Marshal`），必须处理或 Log。
|
||||
4. **Lint 检查:** 生成的代码必须能通过 `errcheck` 和 `staticcheck`。
|
||||
```
|
||||
|
||||
### 🔄 循环动作 B: 上下文锚点 (Context Anchoring)
|
||||
|
||||
**[用户动作]:** 代码生成并确认无误后，发送此 Prompt 以建立记忆锚点。
|
||||
|
||||
**[发送 Prompt]:**
|
||||
|
||||
```Markdown
|
||||
已确认 `{文件名}` 代码无误。
|
||||
请将该代码存入你的**短期记忆**，作为后续步骤的上下文依赖。
|
||||
**不要重复输出它**。我们准备进入下一步。
|
||||
```
|
||||
|
||||
_(重复 A -> B，直到所有源码文件生成完毕)_
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: 极限防御测试 (Extreme Defensive Testing)
|
||||
|
||||
**目的:** 模拟“最糟糕”的业务代码调用，确保基础设施不崩。
|
||||
|
||||
### 🤖 Prompt 4: 生成红队测试用例
|
||||
|
||||
```markdown
|
||||
所有核心代码已生成。现在请为 `internal/pkg/app/response.go` 编写单元测试 `response_test.go`。
|
||||
|
||||
**请覆盖以下 4 个极端场景 (Test Cases):**
|
||||
|
||||
1. **Raw Error 降级:**
|
||||
- **场景:** 传入 `errors.New("db connection broken")` (非 ecode 类型)。
|
||||
- **断言:** HTTP 状态码为 500 (或 200+Code 50000)，Msg 为 "Internal Server Error" (严禁泄漏原始错误信息)。
|
||||
|
||||
2. **Double Response 防护:**
|
||||
- **场景:** 在同一个 Handler 中连续调用 `app.Success()` 两次。
|
||||
- **断言:** 第二次调用应被忽略或记录 Warning 日志，且不应导致 Panic。
|
||||
|
||||
3. **Nil Data 安全:**
|
||||
- **场景:** 调用 `app.Success(nil)`。
|
||||
- **断言:** JSON 中的 `data` 字段应为 `null` (或 `{}`，取决于契约)，不应 Panic。
|
||||
|
||||
4. **并发 Map 读写:**
|
||||
- **场景:** 启动 100 个 Goroutine 并发调用 `ecode.GetMsg(code)`。
|
||||
- **断言:** `test -race` 必须通过，无数据竞争。
|
||||
|
||||
请输出完整的 Test 代码。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: 最终验收 (SRE Review)
|
||||
|
||||
**目的:** 模拟运维视角审查。
|
||||
|
||||
### 🤖 Prompt 5: 找茬模式 (复制使用)
|
||||
|
||||
```Markdown
|
||||
切换角色为 **SRE (站点可靠性工程师)**。
|
||||
请审查上述所有代码（ecode + app）。
|
||||
|
||||
**风险排查:**
|
||||
1. **Panic 风险:** 是否有未捕获的 Panic 点？
|
||||
2. **监控盲区:** 当前的 Error Log 是否包含了足够的上下文（如 StackTrace）供排查？
|
||||
3. **状态码混淆:** 我们采用了“HTTP 200 + 业务码”模式，请确认这是否会影响网关层的 5xx 告警配置？
|
||||
|
||||
请简要列出 2-3 个优化建议。
|
||||
```
|
||||
161
Go项目实战/03_基础设施/01_错误处理/03_README_错误处理.md
Normal file
161
Go项目实战/03_基础设施/01_错误处理/03_README_错误处理.md
Normal file
@@ -0,0 +1,161 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- "🛡️ 基础设施模块：错误处理与响应系统 (Infra: Error Handling & Response)"
|
||||
date created: 星期三, 十二月 10日 2025, 12:10:32 中午
|
||||
date modified: 星期三, 十二月 10日 2025, 12:12:02 中午
|
||||
---
|
||||
|
||||
# 🛡️ 基础设施模块：错误处理与响应系统 (Infra: Error Handling & Response)
|
||||
|
||||
## 1\. 模块概述
|
||||
|
||||
本模块实现了 **Modular Clean Architecture** 中的基础设施层 (`Level 0` & `Level 1`)，提供了一套统一的、安全的、可观测的 HTTP 响应机制。
|
||||
|
||||
**核心能力:**
|
||||
|
||||
- **统一契约:** 所有 API 响应（成功、失败、Panic、404）严格遵循 `{code, msg, data, trace_id}` 结构。
|
||||
- **安全降级:** 自动识别业务错误与系统错误。对系统级错误（如 SQL 失败）进行“掩码”处理，防止敏感信息泄露。
|
||||
- **可观测性:** 集成 Prometheus 埋点，通过 `X-Biz-Code` 实现业务级监控；全链路 TraceID 自动注入。
|
||||
- **开发体验:** 提供 `Responder` 接口与工厂模式，支持 Handler 层的依赖注入与 Mock 测试。
|
||||
|
||||
-----
|
||||
|
||||
## 2\. 文件清单 (File Manifest)
|
||||
|
||||
以下代码位于项目根目录 `gitea-aliyun/Klein/enterprise-cms-core/` 下：
|
||||
|
||||
### Level 0: 基础领域层 (`internal/pkg/ecode`)
|
||||
|
||||
> **依赖:** 零依赖 (仅标准库)
|
||||
|
||||
| 文件名 | 类型 | 核心职责 |
|
||||
| :--- | :--- | :--- |
|
||||
| `code.go` | Const | **错误码注册表**。定义 `1xxxx` (系统) 和 `2xxxx` (业务) 常量。 |
|
||||
| `msg.go` | Data | **文案映射**。维护全局 `map[int]string`，提供并发安全的 `GetMsg`。 |
|
||||
| `error.go` | Struct | **错误实体**。实现 `error` 接口，支持 `WithMsg`/`WithDetails` 扩展。 |
|
||||
| `ecode_test.go` | Test | 验证并发安全性及不可变性。 |
|
||||
|
||||
### Level 1: 应用工具层 (`internal/pkg/app`)
|
||||
|
||||
> **依赖:** `gin`, `ecode`
|
||||
|
||||
| 文件名 | 类型 | 核心职责 |
|
||||
| :--- | :--- | :--- |
|
||||
| `responder.go` | Interface | **接口定义**。定义 `Responder` 接口与 `Factory` 函数类型，用于解耦。 |
|
||||
| `response.go` | Impl | **核心实现**。封装 Gin Context，实现 JSON 序列化、错误清洗、监控埋点。 |
|
||||
| `options.go` | Pattern | **功能选项**。提供 `WithTraceID` 等扩展配置。 |
|
||||
| `response_test.go` | Test | 验证 JSON 契约、空指针防御及错误降级逻辑。 |
|
||||
|
||||
### Global: 全局中间件 (`internal/middleware`)
|
||||
|
||||
> **依赖:** `gin`, `pkg/app`, `pkg/ecode`, `prometheus`
|
||||
|
||||
| 文件名 | 类型 | 核心职责 |
|
||||
| :--- | :--- | :--- |
|
||||
| `recovery.go` | Safety | **Panic 兜底**。捕获 Panic 并转换为标准 JSON 500 响应。 |
|
||||
| `not_found.go` | Route | **404 兜底**。将无路由请求转换为标准 JSON 404 响应。 |
|
||||
| `metrics.go` | Monitor | **业务监控**。采集 `http_requests_total` 指标，包含 `biz_code` 标签。 |
|
||||
|
||||
-----
|
||||
|
||||
## 3\. 快速上手 (Quick Start)
|
||||
|
||||
### 3.1 定义新错误
|
||||
|
||||
在 `internal/pkg/ecode/code.go` 添加常量，并在 `msg.go` 添加文案。
|
||||
|
||||
```go
|
||||
// code.go
|
||||
const UserBalanceInsufficient = 20005
|
||||
|
||||
// msg.go
|
||||
msg = map[int]string{
|
||||
// ...
|
||||
UserBalanceInsufficient: "User Balance Insufficient",
|
||||
}
|
||||
```
|
||||
|
||||
### 3.2 在 Handler 中使用 (推荐写法)
|
||||
|
||||
使用依赖注入的 `app.Factory` 创建响应器，而非直接调用 `app.New`。
|
||||
|
||||
```go
|
||||
import (
|
||||
"github.com/gin-gonic/gin"
|
||||
"gitea-aliyun/Klein/enterprise-cms-core/internal/pkg/app"
|
||||
"gitea-aliyun/Klein/enterprise-cms-core/internal/pkg/ecode"
|
||||
)
|
||||
|
||||
type UserHandler struct {
|
||||
// 注入 Responder 工厂，便于测试 Mock
|
||||
RespFactory app.Factory
|
||||
}
|
||||
|
||||
func (h *UserHandler) Create(c *gin.Context) {
|
||||
// 1. 创建响应器
|
||||
resp := h.RespFactory(c)
|
||||
|
||||
// 2. 模拟业务逻辑
|
||||
if err := h.Service.Create(); err != nil {
|
||||
// 自动处理错误：如果是业务错误直接返回；如果是系统错误则降级并记录日志
|
||||
resp.Error(err)
|
||||
return
|
||||
}
|
||||
|
||||
// 3. 成功响应
|
||||
resp.Success(gin.H{"status": "created"})
|
||||
}
|
||||
```
|
||||
|
||||
### 3.3 系统接入 (Main.go)
|
||||
|
||||
在 HTTP Server 启动时注册全局中间件。
|
||||
|
||||
```go
|
||||
r := gin.New()
|
||||
|
||||
// 1. Recovery (必须最先注册)
|
||||
r.Use(middleware.Recovery())
|
||||
|
||||
// 2. Metrics (监控业务码)
|
||||
r.Use(middleware.BusinessMetrics())
|
||||
|
||||
// ... 注册业务路由 ...
|
||||
|
||||
// 3. 404 处理 (最后注册)
|
||||
r.NoRoute(middleware.NotFound())
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
## 4\. 设计决策说明 (Architecture Decisions)
|
||||
|
||||
### A. HTTP 200 Always 策略
|
||||
|
||||
- **规则:** 除非网络层崩溃，所有接口（包括业务错误和系统错误）均返回 `HTTP 200 OK`。
|
||||
- **原因:** 防止网关（Nginx/ALB）拦截非 200 响应并替换 Body，确保前端始终能解析 JSON 中的 `code`。
|
||||
|
||||
### B. 安全掩码 (Security Masking)
|
||||
|
||||
- **输入:** `db.Query` 失败返回 `sql: connection refused`。
|
||||
- **输出:** 前端收到 `{ "code": 10000, "msg": "Internal Server Error" }`。
|
||||
- **日志:** 服务端 Error Log 记录原始堆栈。
|
||||
- **目的:** 杜绝数据库结构、IP 等敏感信息通过报错接口泄露。
|
||||
|
||||
### C. 监控指标 (Metrics)
|
||||
|
||||
- **指标名:** `http_requests_total`
|
||||
- **关键标签:** `biz_code` (业务状态码)。
|
||||
- **SRE 告警:** 请针对 `biz_code >= 10000` (系统错误) 配置告警，而非 HTTP Status Code。
|
||||
|
||||
-----
|
||||
|
||||
## 5\. 测试指南
|
||||
|
||||
本模块已包含完整的单元测试与竞态检测 (Race Detection)。
|
||||
|
||||
```bash
|
||||
# 运行所有测试
|
||||
go test -v -race ./internal/pkg/...
|
||||
```
|
||||
27
Go项目实战/03_基础设施/01_错误处理/04_错误处理模块文件夹骨架.md
Normal file
27
Go项目实战/03_基础设施/01_错误处理/04_错误处理模块文件夹骨架.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十二月 10日 2025, 11:00:25 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 11:56:10 中午
|
||||
---
|
||||
|
||||
```plaintext
|
||||
enterprise-cms-core/
|
||||
├── internal/
|
||||
│ ├── pkg/
|
||||
│ │ ├── ecode/ # [Level 0] 基础领域层
|
||||
│ │ │ ├── code.go # [Const] 纯常量定义 (ErrorCode Registry)
|
||||
│ │ │ ├── error.go # [Type] 核心结构体定义 (struct Error)
|
||||
│ │ │ ├── msg.go # [Data] 错误码文案映射 (var msg map[int]string)
|
||||
│ │ │ └── ecode_test.go # [Test] 单元测试
|
||||
│ │ │
|
||||
│ │ └── app/ # [Level 1] 应用工具层
|
||||
│ │ ├── responder.go # [Interface] 👈 修正点: 定义 type Responder interface
|
||||
│ │ ├── response.go # [Impl] 定义 type Response struct (实现逻辑)
|
||||
│ │ ├── options.go # [Pattern] 定义 Functional Options (配置扩展)
|
||||
│ │ └── response_test.go # [Test] 单元测试
|
||||
│ │
|
||||
│ └── middleware/ # [Global]
|
||||
│ ├── recovery.go # Panic 捕获
|
||||
│ ├── not_found.go # 404 处理
|
||||
│ └── metrics.go
|
||||
```
|
||||
548
Go项目实战/03_基础设施/01_错误处理/99_错误处理上下文.md
Normal file
548
Go项目实战/03_基础设施/01_错误处理/99_错误处理上下文.md
Normal file
@@ -0,0 +1,548 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- Project Context Aggregation
|
||||
date created: 星期三, 十二月 10日 2025, 11:10:48 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 11:12:52 上午
|
||||
---
|
||||
|
||||
# Project Context Aggregation
|
||||
|
||||
> Source Items: 3
|
||||
|
||||
==== AI 辅助基础设施构建 SOP (v2.1) - 错误处理与响应篇.md ====
|
||||
|
||||
```markdown
|
||||
# 🏗️ AI 辅助基础设施构建 SOP (v2.1) - [错误处理与响应篇]
|
||||
|
||||
**核心理念:**
|
||||
|
||||
1. **Contract First (契约优先):** 永远先定义对外暴露的 JSON 结构，再写内部 Go 结构体。
|
||||
2. **DX Driven (体验驱动):** 在实现逻辑前，先写“伪代码”验证调用是否顺手。
|
||||
3. **Atomic Delivery (原子交付):** 单次交互只生成一个文件，利用“上下文锚点”串联上下文。
|
||||
|
||||
---
|
||||
|
||||
## 📋 准备工作：变量与架构确认
|
||||
|
||||
在使用以下 Prompt 前，请确认上下文：
|
||||
|
||||
- `{语言/框架}`: Go 1.24+ / Gin
|
||||
- `{模块路径}`:
|
||||
- `internal/pkg/ecode` (Level 0: 错误码 + 错误实体 + 映射逻辑)
|
||||
- `internal/pkg/app` (Level 1: HTTP 响应封装，依赖 `ecode`)
|
||||
- `{架构约束}`: `ecode` 包零依赖；`app` 包依赖 `ecode`。
|
||||
|
||||
---
|
||||
|
||||
## Phase 0: 原子化任务拆解 (The MECE Protocol)
|
||||
|
||||
**目的:** 将大需求拆解为一组符合 MECE 原则的微任务清单。
|
||||
|
||||
### 🤖 拆解者 Prompt (复制使用)
|
||||
|
||||
```Markdown
|
||||
你现在是我的 **Tech Lead (技术负责人)**。
|
||||
我们要实现 `{模块名称}` 模块。为了防止代码生成中断和逻辑混乱，请不要直接开始写代码。
|
||||
|
||||
请先执行 **“MECE 任务拆解”**：
|
||||
|
||||
**1. 架构约束分析:**
|
||||
- 本模块遵循 Modular Clean Architecture。
|
||||
- `internal/pkg/ecode`: 包含错误码常量、错误实体结构体、错误文案映射。**严禁依赖上层包**。
|
||||
- `internal/pkg/app`: 包含 Gin 的 Response 封装。依赖 `ecode`。
|
||||
|
||||
**2. 原子化切分:**
|
||||
请将开发工作拆解为 3-5 个“原子任务步”。
|
||||
- 每个步骤必须针对**单个物理文件**。
|
||||
- 步骤必须遵循依赖顺序（底层先于上层）。
|
||||
|
||||
**3. 输出格式:**
|
||||
请输出一个 **Markdown Checklist (执行清单)**。
|
||||
格式示例：
|
||||
- [ ] **Step 1: {文件名}** - {核心职责} (依赖: 无)
|
||||
- [ ] **Step 2: {文件名}** - {核心职责} (依赖: Step 1)
|
||||
…
|
||||
|
||||
**模块需求:**
|
||||
我们需要一套统一的 HTTP 错误处理机制，支持自定义业务错误码，统一返回 JSON 格式。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 0.5: API 签名锁定 (API Surface Lock)
|
||||
|
||||
**目的:** 在实现具体逻辑前，强制锁定所有 Public 方法的签名，防止实现阶段出现参数不一致。
|
||||
|
||||
### 🤖 Prompt 0.5: 生成接口定义
|
||||
|
||||
**[发送给 AI]:**
|
||||
|
||||
````markdown
|
||||
在开始写代码前，请先为 `internal/pkg/app` 包定义 **Public API 签名 (Exported Functions)**。
|
||||
请直接提供 `Responder` 接口定义或核心函数的函数头（无需函数体）。
|
||||
|
||||
**要求:**
|
||||
1. **一致性:** 确认 `context` 参数的位置（建议统一作为第一个参数）。
|
||||
2. **完整性:** 必须包含 `New`, `Success`, `Error` 以及我们刚才讨论的 `ErrorCtx` (处理 trace_id)。
|
||||
3. **Go Doc:** 为每个方法写出符合 Go 标准的注释。
|
||||
|
||||
**期望输出示例:**
|
||||
|
||||
```go
|
||||
// Response wraps the gin.Context for unified JSON response.
|
||||
type Response struct { … }
|
||||
|
||||
// New creates a new Response wrapper.
|
||||
func New(c *gin.Context) *Response { … }
|
||||
|
||||
// Success sends a successful response with data.
|
||||
func (r *Response) Success(data any) { … }
|
||||
```
|
||||
````
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: 契约定义 (Contract Definition)
|
||||
|
||||
**目的:** 确立“对外口径”。
|
||||
|
||||
### 🤖 Prompt 1: 定义 JSON 结构 (复制使用)
|
||||
|
||||
```Markdown
|
||||
你现在是我的 **API 治理专家**。
|
||||
请设计一套统一的 **HTTP 响应结构 (JSON Envelope)**。
|
||||
|
||||
**设计原则:**
|
||||
1. **统一性:** 无论成功还是失败，Body 结构一致。
|
||||
2. **字段要求:** 必须包含 `code` (int), `msg` (string), `data` (any), `trace_id` (string)。
|
||||
|
||||
**任务:**
|
||||
请给出以下 3 种场景的 JSON 响应示例，并解释设计理由：
|
||||
- 场景 A: 成功返回对象。
|
||||
- 场景 B: 成功返回空列表 (明确 `data` 是 `null` 还是 `[]`)。
|
||||
- 场景 C: 业务错误 (如 Code 20001)。
|
||||
|
||||
**[关键补充约束]**
|
||||
1. **安全性优先:** `app.Error(err)` 处理逻辑中，必须区分**用户可见文案**和**底层调试信息**。若 `err` 包含底层堆栈（如 SQL 错误），JSON 中的 `msg` 必须降级显示为 `ecode` 定义的通用文案（如 "Internal Error"），严禁透传底层 Error String。
|
||||
2. **HTTP 状态码:** 本项目强制执行 **"HTTP 200 OK + Business Code"** 策略。除非 Gin 框架层崩溃，否则 HTTP Status 永远为 200。
|
||||
3. **Trace ID:** 假设 `c.GetString("trace_id")` 可以获取 ID，请在 `app.New(c)` 时将其注入 Response 结构体。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: 体验验证 (DX Verification)
|
||||
|
||||
**目的:** 模拟业务层调用，防止基础设施“反人类”。
|
||||
|
||||
### 🤖 Prompt 2: 伪代码验证 (复制使用)
|
||||
|
||||
```Markdown
|
||||
JSON 结构已确认。
|
||||
假设我们已经有了 `internal/pkg/ecode` 和 `internal/pkg/app`。
|
||||
|
||||
请写一段 Gin Handler 的 **伪代码 (Pseudo-code)**，展示开发者该如何使用它们。
|
||||
|
||||
**验证重点:**
|
||||
1. **业务错误:** 如何返回 `ecode.New(20001, "…")`？
|
||||
2. **响应封装:** 如何调用 `app.New(c).Success(data)`？
|
||||
3. **代码简洁性:** 避免大量的 `if err != nil` 重复代码。
|
||||
|
||||
请展示最优雅的写法。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: 迭代式核心实现 (Iterative Implementation)
|
||||
|
||||
**核心机制:** 这是一个**循环步骤**。请查看 Phase 0 生成的 Checklist，**逐个文件**执行。
|
||||
|
||||
### 🔄 循环动作 A: 生成代码
|
||||
|
||||
**[用户动作]:** 复制 Checklist 中当前未完成的步骤（例如 "Step 1: 生成 ecode/code.go"）。
|
||||
|
||||
**[发送 Prompt]:**
|
||||
|
||||
```Markdown
|
||||
我们现在执行 **Step {N}**。
|
||||
|
||||
**任务目标:**
|
||||
{粘贴 Phase 0 Checklist 中的当前步骤描述}
|
||||
|
||||
**上下文约束 (严禁修改):**
|
||||
1. **JSON 契约:** `{粘贴 Phase 1 确认的 JSON}`
|
||||
2. **DX 规范:** `{粘贴 Phase 2 确认的伪代码}`
|
||||
3. **依赖控制:** 如果是 `ecode` 包，严禁引用 `app` 或 `gin`。
|
||||
|
||||
**输出要求:**
|
||||
请仅生成该步骤对应的 `{文件名}` 源代码。不要生成测试代码。
|
||||
|
||||
**通用代码质量约束 (Linter Rules):**
|
||||
1. **注释规范:** 所有 Exported (首字母大写) 的结构体、函数、常量必须包含符合 Go Doc 规范的注释。
|
||||
2. **复杂度控制:** 确保 `gocyclo` (圈复杂度) 低于 10。如果逻辑复杂，请拆分为私有函数。
|
||||
3. **错误检查:** 严禁忽略 error 返回值（如 `json.Marshal`），必须处理或 Log。
|
||||
4. **Lint 检查:** 生成的代码必须能通过 `errcheck` 和 `staticcheck`。
|
||||
```
|
||||
|
||||
### 🔄 循环动作 B: 上下文锚点 (Context Anchoring)
|
||||
|
||||
**[用户动作]:** 代码生成并确认无误后，发送此 Prompt 以建立记忆锚点。
|
||||
|
||||
**[发送 Prompt]:**
|
||||
|
||||
```Markdown
|
||||
已确认 `{文件名}` 代码无误。
|
||||
请将该代码存入你的**短期记忆**，作为后续步骤的上下文依赖。
|
||||
**不要重复输出它**。我们准备进入下一步。
|
||||
```
|
||||
|
||||
_(重复 A -> B，直到所有源码文件生成完毕)_
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: 极限防御测试 (Extreme Defensive Testing)
|
||||
|
||||
**目的:** 模拟“最糟糕”的业务代码调用，确保基础设施不崩。
|
||||
|
||||
### 🤖 Prompt 4: 生成红队测试用例
|
||||
|
||||
```markdown
|
||||
所有核心代码已生成。现在请为 `internal/pkg/app/response.go` 编写单元测试 `response_test.go`。
|
||||
|
||||
**请覆盖以下 4 个极端场景 (Test Cases):**
|
||||
|
||||
1. **Raw Error 降级:**
|
||||
- **场景:** 传入 `errors.New("db connection broken")` (非 ecode 类型)。
|
||||
- **断言:** HTTP 状态码为 500 (或 200+Code 50000)，Msg 为 "Internal Server Error" (严禁泄漏原始错误信息)。
|
||||
|
||||
2. **Double Response 防护:**
|
||||
- **场景:** 在同一个 Handler 中连续调用 `app.Success()` 两次。
|
||||
- **断言:** 第二次调用应被忽略或记录 Warning 日志，且不应导致 Panic。
|
||||
|
||||
3. **Nil Data 安全:**
|
||||
- **场景:** 调用 `app.Success(nil)`。
|
||||
- **断言:** JSON 中的 `data` 字段应为 `null` (或 `{}`，取决于契约)，不应 Panic。
|
||||
|
||||
4. **并发 Map 读写:**
|
||||
- **场景:** 启动 100 个 Goroutine 并发调用 `ecode.GetMsg(code)`。
|
||||
- **断言:** `test -race` 必须通过，无数据竞争。
|
||||
|
||||
请输出完整的 Test 代码。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: 最终验收 (SRE Review)
|
||||
|
||||
**目的:** 模拟运维视角审查。
|
||||
|
||||
### 🤖 Prompt 5: 找茬模式 (复制使用)
|
||||
|
||||
```Markdown
|
||||
切换角色为 **SRE (站点可靠性工程师)**。
|
||||
请审查上述所有代码（ecode + app）。
|
||||
|
||||
**风险排查:**
|
||||
1. **Panic 风险:** 是否有未捕获的 Panic 点？
|
||||
2. **监控盲区:** 当前的 Error Log 是否包含了足够的上下文（如 StackTrace）供排查？
|
||||
3. **状态码混淆:** 我们采用了“HTTP 200 + 业务码”模式，请确认这是否会影响网关层的 5xx 告警配置？
|
||||
|
||||
请简要列出 1-2 个优化建议。
|
||||
```
|
||||
|
||||
```bash
|
||||
|
||||
==== 基础设施详细设计规格说明书.md ====
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 🏗️ Infrastructure Design Specifications (v1.2)
|
||||
- 🏗️ Infrastructure Design Specifications (v1.1)
|
||||
- 🏗️ Infrastructure Design Specifications (v1.0)
|
||||
date created: 星期三, 十二月 10日 2025, 9:41:53 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 10:37:49 上午
|
||||
---
|
||||
|
||||
# 🏗️ Infrastructure Design Specifications (v1.2)
|
||||
|
||||
项目名称: Enterprise-CMS-Core
|
||||
|
||||
模块: Infrastructure (Error Handling & Response)
|
||||
|
||||
版本: 1.2.0 (Refined)
|
||||
|
||||
状态: [✅ 已锁定]
|
||||
|
||||
---
|
||||
|
||||
## 1. 设计目标 (Design Objectives)
|
||||
|
||||
本模块旨在构建一套**统一的、类型安全的、框架解耦**的 HTTP 响应与错误处理机制。
|
||||
|
||||
- **统一性:** 无论成功与否，API 必须返回结构一致的 JSON Envelope。
|
||||
- **可观测性:** 错误必须携带业务语义（ErrorCode），而非仅返回 HTTP 500。
|
||||
- **解耦性:** 业务逻辑层 (Service) 不感知 HTTP 框架 (Gin)，仅通过 Go 原生 `error` 接口交互。
|
||||
- **高内聚:** 错误码定义与错误实体封装在同一包内，减少调用摩擦。
|
||||
|
||||
---
|
||||
|
||||
## 2. 技术选型基线 (Tech Stack Baseline)
|
||||
|
||||
|**组件**|**选型**|**约束说明**|
|
||||
|---|---|---|
|
||||
|**HTTP Context**|`github.com/gin-gonic/gin`|仅在 `internal/pkg/app` (Level 1) 和 `handler` 层使用。**严禁**在 `service` 层引入。|
|
||||
|**Error Handling**|Go Standard Library|使用 Go 1.13+ `errors` (`Is`, `As`, `New`) 和 `fmt.Errorf`。**严禁**引入第三方 error 库 (如 `pkg/errors`)。|
|
||||
|**Serialization**|`encoding/json`|使用标准库。MVP 阶段暂不引入 `json-iterator`。|
|
||||
|**Concurrency**|`sync.RWMutex`|用于保护错误码 Map 的并发读取（读多写少场景）。|
|
||||
| **Tracing** | Gin Keys | Trace ID 必须由前置中间件（或网关）注入。Gin Context Key 约定为 `"X-Trace-ID"`。 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心设计模式 (Design Patterns)
|
||||
|
||||
### 3.1 响应封装：Context Object & Factory
|
||||
|
||||
采用 **“上下文对象”** 模式对 `gin.Context` 进行封装，提供链式调用的体验。
|
||||
|
||||
- **模式:** `app.New(c).Success(data)`
|
||||
- **优势:** 屏蔽底层框架差异，统一入口。
|
||||
|
||||
### 3.2 错误处理：安全与动态机制 (Security & Dynamics)
|
||||
|
||||
- **双层信息架构:**
|
||||
- **User Msg (Safe):** JSON Body 中的 `msg` 字段。**仅**允许返回 `ecode` 中定义的静态文案，或经过白名单过滤的动态参数（如参数名）。
|
||||
- **Log Detail (Unsafe):** 服务端日志。必须记录完整的 `err.Error()`（包含堆栈、SQL 错误、`fmt.Errorf` 包装的底层原因）。
|
||||
- **动态文案支持:**
|
||||
- `ecode` 包需提供 `WithMsg(msg string)` 或 `WithDetails(args …any)` 方法，用于**安全地**覆盖默认文案。
|
||||
- **示例:** `return ecode.InvalidParams.WithMsg("Email 格式错误")`。
|
||||
|
||||
### 3.3 状态码管理：Centralized Registry
|
||||
|
||||
采用 **“集中式注册表”** 模式。
|
||||
|
||||
- **约束:** 所有业务错误码 (Business Code) 必须在 `internal/pkg/ecode` 包中定义为 `const`。
|
||||
- **禁止:** 严禁在业务代码中硬编码数字（Magic Number）。
|
||||
|
||||
### 3.4 错误码号段分配：Error Code Allocation
|
||||
|
||||
结构定义:
|
||||
|
||||
错误码采用 5 位数字结构：A BB NN
|
||||
|
||||
- **A (万位):** 模块/领域 (1=Infra, 2=User, 3=Content…)
|
||||
- **BB (千百位):** 组件/子模块分类
|
||||
- **NN (十个位):** 具体错误流水号
|
||||
|
||||
#### 1. 基础设施层 (System / Infra) - `10000 - 19999`
|
||||
|
||||
针对基础设施，**必须**严格遵守以下二级分类，严禁混用：
|
||||
|
||||
|**二级区间 (Sub-Range)**|**组件归属 (Component)**|**典型示例 (Examples)**|
|
||||
|---|---|---|
|
||||
|**10000 - 10099**|**Server General**|`10000` (Success), `10001` (Unknown Error), `10002` (Panic Recovered)|
|
||||
|**10100 - 10199**|**Database (Internal)**|`10100` (DB Connection Lost), `10101` (SQL Syntax Error) - _注意：业务查空属业务码，不在此列_|
|
||||
|**10200 - 10299**|**Cache (Redis)**|`10200` (Redis Timeout), `10201` (Key Evicted Unexpectedly)|
|
||||
|**10300 - 10399**|**Serialization**|`10300` (JSON Marshal Failed), `10301` (Invalid Request Body)|
|
||||
|**10400 - 10499**|**Middleware/Gateway**|`10400` (Too Many Requests/Rate Limit), `10401` (Route Not Found)|
|
||||
|**10500 - 10599**|**3rd Party API**|`10500` (External Service Unavailable), `10501` (SMS Send Failed)|
|
||||
|
||||
#### 2. 业务模块层 (Business Modules) - `20000+`
|
||||
|
||||
业务模块建议参考同等逻辑进行二级划分（由各模块负责人定义，但建议遵循以下范式）：
|
||||
|
||||
|**一级区间**|**模块**|**二级区间示例**|
|
||||
|---|---|---|
|
||||
|**20000 - 29999**|**User / Auth**|`200xx` (基础账户), `201xx` (登录/Token), `202xx` (RBAC 权限), `203xx` (KYC 认证)|
|
||||
|**30000 - 39999**|**Content (CMS)**|`300xx` (文章), `301xx` (分类/标签), `302xx` (评论), `303xx` (审核流)|
|
||||
|
||||
---
|
||||
|
||||
## 4. 交互协议与数据流 (Interaction Protocol)
|
||||
|
||||
### 4.1 JSON 响应契约 (The Contract)
|
||||
|
||||
所有 HTTP 接口返回的 Body 必须符合以下结构：
|
||||
|
||||
```JSON
|
||||
{
|
||||
"code": 20001, // 业务状态码 (0=成功, 非0=错误)
|
||||
"msg": "用户已存在", // 开发者提示/用户提示
|
||||
"data": { … }, // 业务数据 (成功时为 Object/Array, 失败时为 null)
|
||||
"trace_id": "abc-123" // 必填。取值优先级: c.GetHeader("X-Trace-ID") -> c.GetString("X-Trace-ID") -> UUID生成
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 HTTP 状态码策略 (Status Code Policy)
|
||||
|
||||
本项目采用 **"Hybrid 策略 "**：
|
||||
|
||||
- **HTTP 200 OK:**
|
||||
- 所有 **业务逻辑错误** (Code `2xxxx` - `4xxxx`)。
|
||||
- 前端通过 Body 中的 `code != 0` 判断业务异常。
|
||||
- _理由:_ 避免网关（如 Nginx）拦截 4xx 响应并替换为默认错误页，导致前端拿不到 JSON 数据。
|
||||
- **HTTP 500 Internal Server Error:**
|
||||
- 所有 **基础设施错误** (Code `1xxxx`)，包括 Panic、数据库断连、Redis 超时。
|
||||
- _理由:_ 触发云厂商负载均衡器 (LB) 的熔断机制，将流量切出故障节点。
|
||||
- **HTTP 401/403:**
|
||||
- 仅用于网关层面的拦截（如 JWT 格式错误），业务层鉴权失败建议走 HTTP 200 + Code `20101`。
|
||||
|
||||
### 4.3 跨层交互时序 (Cross-Layer Flow)
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant C as Controller (Handler)
|
||||
participant S as Service (Domain)
|
||||
participant I as Infra (pkg/app)
|
||||
participant E as Ecode (pkg/ecode)
|
||||
|
||||
C->>I: app.New(c) 初始化
|
||||
C->>S: Call Business Logic
|
||||
alt 成功
|
||||
S-->>C: return (data, nil)
|
||||
C->>I: app.Success(data)
|
||||
I-->>Client: JSON {code:0, data:…}
|
||||
else 失败 (业务错误)
|
||||
S-->>C: return (nil, ecode.New(20001))
|
||||
C->>I: app.Error(err)
|
||||
I->>I: errors.As(err) -> 提取 Code 20001
|
||||
I-->>Client: JSON {code:20001, msg:"…"}
|
||||
else 失败 (系统错误)
|
||||
S-->>C: return (nil, errors.New("DB error"))
|
||||
C->>I: app.Error(err)
|
||||
I->>I: errors.As(err) -> 失败 (Fallback)
|
||||
I-->>Client: JSON {code:50000, msg:"Internal Error"}
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 目录结构与职责 (Directory & Responsibilities)
|
||||
|
||||
```Plaintext
|
||||
internal/
|
||||
├── middleware/ # [New] 全局中间件
|
||||
│ ├── recovery.go # Panic 捕获 -> 转换为 ecode.ServerError (50000)
|
||||
│ └── not_found.go # 404 捕获 -> 转换为 ecode.NotFound (40400)
|
||||
│
|
||||
└── pkg/
|
||||
├── ecode/ # [Level 0] 错误核心包 (无内部依赖)
|
||||
│ ├── code.go # const 常量定义 (UserNotFound = 20001)
|
||||
│ ├── msg.go # 错误码文案映射 (Map & GetMsg)
|
||||
│ └── error.go # Error 结构体定义 (New, Parse 方法)
|
||||
│
|
||||
└── app/ # [Level 1] HTTP 响应封装 (依赖 gin, ecode)
|
||||
└── response.go # NewResponse, Success, Error 方法
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 开发规范与 Linter 规则 (Linting Rules)
|
||||
|
||||
1. **包引用原则:**
|
||||
|
||||
- `ecode` 包必须保持零依赖（只依赖标准库）。
|
||||
- `app` 包依赖 `ecode`。
|
||||
|
||||
2. **Service 层纯净性:**
|
||||
|
||||
- `internal/domain/service` 代码中**严禁出现** `import "github.com/gin-gonic/gin"`。
|
||||
- `internal/domain/service` 代码中**严禁出现** `import "enterprise-cms-core/internal/pkg/app"`。
|
||||
- 只允许引入 `internal/pkg/ecode`。
|
||||
|
||||
3. **错误包装与响应清洗:**
|
||||
|
||||
- **Log:** `app.Error(err)` 内部必须将 `err` 的完整堆栈打印到 Zap 日志中。
|
||||
- **Response:**
|
||||
- 若 `err` 可被断言为 `*ecode.Error`，则取其 `Msg` 字段返回。
|
||||
- 若 `err` 仅为普通 `error` (如 DB error)，**严禁**直接将其内容返回给前端，必须统一兜底返回 `ecode.ServerError` 的文案（"Internal Server Error"）。
|
||||
|
||||
4. **全局兜底机制 (Global Safety Net):**
|
||||
- 项目必须在 `internal/middleware` 中实现 `Recovery` 中间件。
|
||||
- **严禁**让 Gin 默认的 Panic 堆栈直接输出到 HTTP Body。
|
||||
- **必须**捕获所有 Panic，并调用 `app.Error(ecode.ServerError)` 统一输出为符合 JSON 契约的格式 (`{"code": 50000, "msg": "Internal Server Error", …}`)。
|
||||
|
||||
---
|
||||
|
||||
## 7. 工程化实施标准 (Engineering Standards)
|
||||
|
||||
### 7.1 代码风格契约 (Code Style Contract)
|
||||
|
||||
为确保代码长期可维护，生成的代码必须严格遵守以下 Go 惯用语 (Idioms)：
|
||||
|
||||
1. **命名规范:**
|
||||
- **缩写:** 使用全大写缩写 (如 `ServeHTTP`, `ID`, `URL`)，严禁 `Url`, `Id`。
|
||||
- **局部变量:** 保持短小 (如 `ctx`, `err`, `req`)，避免 Java 式的长命名 (如 `requestContext`, `errorObject`)。
|
||||
- **工厂方法:** `ecode` 包内使用 `New()`, `app` 包内使用 `NewResponse()`。
|
||||
|
||||
2. **代码组织:**
|
||||
- **Import 分组:** 标准库 -> 第三方库 -> 内部库 (enterprise-cms-core/…)。
|
||||
- **Guard Clauses:** 优先使用“卫语句”提前返回，减少 `else` 嵌套层级。
|
||||
|
||||
### 7.2 注释与文档 (Documentation)
|
||||
|
||||
为了提升团队协作效率，所有 Exported (首字母大写) 的类型、函数、常量必须包含符合 GoDoc 规范的**中文注释**。
|
||||
|
||||
- **格式规范:** `// FunctionName 中文描述…`
|
||||
- **关键:** 注释**必须**以函数/变量名开头，且与中文描述之间**保留一个空格**。这是 Go 官方工具链解析文档的标准要求。
|
||||
- **内容重心:**
|
||||
- **摘要:** 第一行简明扼要地说明“它是做什么的”。
|
||||
- **详情 (可选):** 解释 **"Why" (设计意图)** 和 **"Caveats" (副作用/注意事项)**，而非翻译代码逻辑。
|
||||
- **示例:**
|
||||
|
||||
```Go
|
||||
// Success 向客户端写入标准的 JSON 成功响应。
|
||||
//
|
||||
// 注意:
|
||||
// 1. 无论业务逻辑如何，此方法会将 HTTP 状态码强制设置为 200。
|
||||
// 2. data 字段若为 nil，将序列化为 JSON 的 null。
|
||||
func (r *Response) Success(data any) { … }
|
||||
|
||||
// UserNotFound 表示用户不存在的业务错误码 (20001)。
|
||||
const UserNotFound = 20001
|
||||
```
|
||||
|
||||
### 7.3 可扩展性设计 (Extensibility Patterns)
|
||||
|
||||
为了应对未来需求变更，本模块需采用以下模式：
|
||||
|
||||
1. **Functional Options (针对 `app` 包):**
|
||||
- 构造 `Response` 对象时，应支持 Option 模式，以便未来无需破坏函数签名即可添加新字段（如 TraceID, DebugInfo）。
|
||||
- *定义:* `type Option func(*Response)`
|
||||
- *签名:* `func New(c *gin.Context, opts …Option) *Response`
|
||||
|
||||
2. **Interface Segregation (接口隔离):**
|
||||
- 虽然 `ecode` 是基础值对象，但 `app` 层若涉及复杂逻辑，应定义 `Responder` 接口，方便 Mock 测试。
|
||||
|
||||
```bash
|
||||
|
||||
==== 错误处理模块文件夹骨架.md ====
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十二月 10日 2025, 11:00:25 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 11:04:26 上午
|
||||
---
|
||||
|
||||
```plaintext
|
||||
enterprise-cms-core/
|
||||
├── internal/
|
||||
│ ├── pkg/
|
||||
│ │ ├── ecode/ # [Level 0] 基础领域层
|
||||
│ │ │ ├── code.go # [Const] 纯常量定义 (ErrorCode Registry)
|
||||
│ │ │ ├── error.go # [Type] 核心结构体定义 (struct Error)
|
||||
│ │ │ ├── msg.go # [Data] 错误码文案映射 (var msg map[int]string)
|
||||
│ │ │ └── ecode_test.go # [Test] 单元测试
|
||||
│ │ │
|
||||
│ │ └── app/ # [Level 1] 应用工具层
|
||||
│ │ ├── responder.go # [Interface] 👈 修正点: 定义 type Responder interface
|
||||
│ │ ├── response.go # [Impl] 定义 type Response struct (实现逻辑)
|
||||
│ │ ├── options.go # [Pattern] 定义 Functional Options (配置扩展)
|
||||
│ │ └── response_test.go # [Test] 单元测试
|
||||
│ │
|
||||
│ └── middleware/ # [Global]
|
||||
│ ├── recovery.go # Panic 捕获
|
||||
│ └── not_found.go # 404 处理
|
||||
```
|
||||
|
||||
```bash
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- "📋 Phase 0: 基础设施构建执行清单 (Execution Checklist)"
|
||||
date created: 星期三, 十二月 10日 2025, 11:15:25 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 11:41:27 中午
|
||||
---
|
||||
|
||||
# 📋 Phase 0: 基础设施构建执行清单 (Execution Checklist)
|
||||
|
||||
- [ ] **Step 1: `internal/pkg/ecode/code.go`** - **定义错误码注册表**
|
||||
- **核心职责:** 仅定义 `int` 类型的 `const` 常量。包括基础设施类（10000+）和业务类（20000+）错误码。
|
||||
- **依赖:** 无 (Root Node)。
|
||||
- **注意:** 需严格遵循文档中的“五位数字”分段规则。
|
||||
|
||||
- [ ] **Step 2: `internal/pkg/ecode/msg.go`** - **定义错误文案映射**
|
||||
- **核心职责:** 初始化全局 `map[int]string`，提供 `GetMsg(code)` 方法。
|
||||
- **依赖:** Step 1 (`code.go` 中的常量)。
|
||||
- **注意:** 使用 `sync.RWMutex` 保护并发读写（虽然主要是读），文案必须是“用户安全”的。
|
||||
|
||||
- [ ] **Step 3: `internal/pkg/ecode/error.go`** - **实现核心错误实体**
|
||||
- **核心职责:** 定义 `struct Error`，实现 `error` 接口，提供 `New()`, `Error()`, `Code()` 等方法。支持 `WithDetails` 等动态扩展。
|
||||
- **依赖:** Step 1 & Step 2。
|
||||
- **注意:** 这是 Service 层唯一允许引用的错误对象。
|
||||
|
||||
- [ ] **Step 4: `internal/pkg/app/options.go`** - **定义响应配置模式**
|
||||
- **核心职责:** 定义 `type Option func(*Response)` 及常用的 Option 实现（如 `WithTraceID`）。
|
||||
- **依赖:** 无（或仅依赖标准库）。
|
||||
- **注意:** 先于 `response.go` 实现，以便主逻辑直接使用配置项，符合“开闭原则”。
|
||||
|
||||
- [ ] **Step 5: `internal/pkg/app/response.go`** - **实现 HTTP 响应封装**
|
||||
- **核心职责:** 定义 `Response` 结构体，封装 `New`, `Success`, `Error` 方法。处理 JSON 序列化、TraceID 注入、以及将 `error` 接口清洗为 `ecode` 的逻辑。
|
||||
- **依赖:** Step 3 (`ecode`), Step 4 (`options`), `Gin Context`。
|
||||
- **注意:** 需实现“双层信息架构”：日志记录原始错误，HTTP Body 返回安全文案。
|
||||
|
||||
- [ ] **Step 6: internal/pkg/app/responder.go** - **定义 Responder 接口**
|
||||
- **核心职责:** 定义 `Responder` 接口，解耦具体实现，方便未来 Mock 测试。
|
||||
- **依赖:** `app/response.go` (实现关系)。
|
||||
145
Go项目实战/03_基础设施/01_错误处理/Phase 1 统一响应结构定义 (The Contract).md
Normal file
145
Go项目实战/03_基础设施/01_错误处理/Phase 1 统一响应结构定义 (The Contract).md
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 📦 统一响应结构定义 (The Contract)
|
||||
date created: 星期三, 十二月 10日 2025, 11:23:15 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 12:12:46 中午
|
||||
---
|
||||
|
||||
# Phase 1 统一响应结构定义 (The Contract)
|
||||
|
||||
## 📦 统一响应结构定义 (The Contract)
|
||||
|
||||
所有 HTTP 接口（无论成功与否）必须严格返回以下 JSON 结构：
|
||||
|
||||
```JSON
|
||||
{
|
||||
"code": 20001, // 业务状态码 (0=成功, 非0=错误)
|
||||
"msg": "用户已存在", // 用户可见的提示文案 (Safe Message)
|
||||
"data": { ... }, // 业务数据 payload (成功时返回，失败时通常为 null)
|
||||
"trace_id": "a1b2-c3d4" // 全链路追踪 ID (必填，用于 SRE 排查)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎨 场景示例与设计理由
|
||||
|
||||
### 🟢 场景 A: 成功返回对象 (Single Object)
|
||||
|
||||
请求: GET /api/v1/users/1001
|
||||
|
||||
HTTP Status: 200 OK
|
||||
|
||||
```JSON
|
||||
{
|
||||
"code": 0,
|
||||
"msg": "OK",
|
||||
"data": {
|
||||
"user_id": 1001,
|
||||
"nickname": "TechLead_01",
|
||||
"avatar": "https://cdn.example.com/u/1001.jpg"
|
||||
},
|
||||
"trace_id": "0a1b2c3d-4e5f-6789-1234-567890abcdef"
|
||||
}
|
||||
```
|
||||
|
||||
**📌 设计理由:**
|
||||
|
||||
- **Code 0:** 符合业界惯例（如 Google/Tencent API），`0` 明确表示逻辑执行成功。
|
||||
- **Data 类型:** 返回具体的 Object。
|
||||
|
||||
---
|
||||
|
||||
### 🟡 场景 B: 成功返回空列表 (Empty List)
|
||||
|
||||
请求: GET /api/v1/articles?category=golang (假设该分类下无文章)
|
||||
|
||||
HTTP Status: 200 OK
|
||||
|
||||
```JSON
|
||||
{
|
||||
"code": 0,
|
||||
"msg": "OK",
|
||||
"data": {
|
||||
"list": [],
|
||||
"total": 0
|
||||
},
|
||||
"trace_id": "0a1b2c3d-4e5f-6789-1234-567890abcdef"
|
||||
}
|
||||
```
|
||||
|
||||
**📌 设计理由:**
|
||||
|
||||
- **Data 不为 `null`:** 对于列表型接口，`data` 内部的 `list` 字段必须返回空数组 `[]`，而不是 `null`。
|
||||
- _原因:_ 前端可以直接调用 `.map()` 或 `.forEach()` 而无需判空，极大降低前端出现 `Cannot read property 'map' of null` 的崩溃风险。
|
||||
- **结构一致性:** 即使是列表，建议包裹在 Object 中（如 `{list: [], total: 0}`），方便未来扩展分页字段。
|
||||
|
||||
---
|
||||
|
||||
### 🔴 场景 C: 业务/系统错误 (Error Handling)
|
||||
|
||||
这里我们需要区分 **“预期内的业务错误”** 和 **“预期外的系统错误”**，但在 JSON 表现上它们必须是一致的。
|
||||
|
||||
Case C-1: 预期内的业务错误
|
||||
|
||||
场景: 用户尝试注册已存在的邮箱。
|
||||
|
||||
Service 层返回: ecode.UserAlreadyExist (Code: 20001)
|
||||
|
||||
```JSON
|
||||
{
|
||||
"code": 20001,
|
||||
"msg": "用户已存在",
|
||||
"data": null,
|
||||
"trace_id": "0a1b2c3d-4e5f-6789-1234-567890abcdef"
|
||||
}
|
||||
```
|
||||
|
||||
Case C-2: 预期外的系统错误 (触发安全防御)
|
||||
|
||||
场景: 数据库突然断连，GORM 返回 dial tcp 127.0.0.1:5432: connect: connection refused。
|
||||
|
||||
Service 层返回: 原生 error 对象。
|
||||
|
||||
```JSON
|
||||
{
|
||||
"code": 50000,
|
||||
"msg": "Internal Server Error", // <--- 严禁显示 "dial tcp ..."
|
||||
"data": null,
|
||||
"trace_id": "0a1b2c3d-4e5f-6789-1234-567890abcdef"
|
||||
}
|
||||
```
|
||||
|
||||
**📌 设计理由:**
|
||||
|
||||
- **Security (安全降级):**
|
||||
- `app.Error(err)` 的内部逻辑必须执行 **Type Assertion (类型断言)**。
|
||||
- 若 `err` 是 `*ecode.Error`，则透传其 `msg`（Case C-1）。
|
||||
- 若 `err` 是普通 `error`（Case C-2），视为系统级异常。**必须**将 JSON 中的 `msg` 强制重写为 `"Internal Server Error"` 或通用文案，防止数据库表结构、IP 地址等敏感信息泄露给攻击者。
|
||||
- **HTTP 200:** 即使是 Code 50000，HTTP Status 依然保持 200。这确保了网关层（Nginx/Gateway）不会拦截 Body，前端始终能解析 JSON 拿到 `code` 和 `trace_id` 用于展示和报错。
|
||||
|
||||
---
|
||||
|
||||
## 🛡️ 关键实现逻辑预告
|
||||
|
||||
为了实现上述契约，在接下来的 **Step 5: `internal/pkg/app/response.go`** 中，我们将实现如下核心逻辑：
|
||||
|
||||
1. **Trace ID 注入:** 在 `New(c)` 时执行 `r.traceID = c.GetString("trace_id")`。
|
||||
2. **错误清洗:**
|
||||
|
||||
```Go
|
||||
// 伪代码逻辑预览
|
||||
func (r *Response) Error(err error) {
|
||||
if e, ok := err.(*ecode.Error); ok {
|
||||
// 业务错误：直接使用
|
||||
r.json(e.Code(), e.Msg())
|
||||
} else {
|
||||
// 系统错误：记录原始日志，但在 JSON 中降级
|
||||
log.Error("System Error", zap.Error(err), zap.String("trace_id", r.traceID))
|
||||
r.json(ecode.ServerErr, "Internal Server Error") // 🔒 安全替换
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
这套设计已经满足了 **Phase 1** 的所有契约要求。
|
||||
111
Go项目实战/03_基础设施/01_错误处理/SOP 增强补丁：长代码&多文件分步生成策略.md
Normal file
111
Go项目实战/03_基础设施/01_错误处理/SOP 增强补丁：长代码&多文件分步生成策略.md
Normal file
@@ -0,0 +1,111 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 🛠️ SOP 增强补丁：长代码/多文件分步生成策略
|
||||
date created: 星期三, 十二月 10日 2025, 9:21:58 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 9:34:54 上午
|
||||
---
|
||||
|
||||
# 🛠️ SOP 增强补丁：长代码/多文件分步生成策略
|
||||
|
||||
核心原则: 原子化交付 (Atomic Delivery)。
|
||||
|
||||
不要命令 AI “写完这个模块”。要命令 AI “写完这个文件” 或者 “写完这个结构体的具体方法”。
|
||||
|
||||
## 策略一：按物理文件拆分 (File-Level Sharding)
|
||||
|
||||
对于基础设施模块，通常可以自然拆分为多个文件。
|
||||
|
||||
操作动作:
|
||||
|
||||
修改 SOP 的 阶段三，不再一次性要求生成所有文件，而是分轮次请求。
|
||||
|
||||
### 🤖 优化后的 Prompt 序列
|
||||
|
||||
**第一轮：仅生成错误码定义**
|
||||
|
||||
```Markdown
|
||||
我们先处理 `internal/pkg/code` 包。
|
||||
请仅生成 `code.go` 文件。
|
||||
内容包含：
|
||||
1. package 声明。
|
||||
2. const 常量定义（错误码）。
|
||||
3. 暂时不要包含 `GetMsg` 的具体 map 映射逻辑，只定义常量。
|
||||
```
|
||||
|
||||
**第二轮：生成错误码映射**
|
||||
|
||||
```Markdown
|
||||
很好。现在请生成同目录下的 `msg.go` 文件。
|
||||
内容包含：
|
||||
1. `var msgFlags = map[int]string{…}` 映射表。
|
||||
2. `func Text(code int) string` 方法的实现。
|
||||
注意：请确保引用了 `code.go` 中定义的常量。
|
||||
```
|
||||
|
||||
**第三轮：生成响应结构体**
|
||||
|
||||
```Markdown
|
||||
现在进入 `internal/pkg/app` 包。
|
||||
请生成 `response.go`。
|
||||
实现 `Response` 结构体定义、`NewResponse` 工厂函数，以及 `Success` 方法。
|
||||
暂时**不要**实现 `Error` 相关方法，我们下一步单独写。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 策略二：骨架先行，血肉填充 (Skeleton First, Flesh Later)
|
||||
|
||||
如果单文件（如 `service.go`）依然很长（超过 500 行），使用此策略。先生成接口和空方法，再逐个填充逻辑。
|
||||
|
||||
### 🤖 优化后的 Prompt 序列
|
||||
|
||||
**第一轮：生成骨架 (The Skeleton)**
|
||||
|
||||
```Markdown
|
||||
我们要实现 `UserService`。由于逻辑复杂，请先生成**骨架代码**。
|
||||
要求：
|
||||
1. 定义 Struct 和所有 Method 的签名 (Signature)。
|
||||
2. Method 内部留空，或仅写 `panic("implement me")`。
|
||||
3. 包含完整的各种 import 和结构体字段注入。
|
||||
```
|
||||
|
||||
**第二轮：填充核心方法 (The Flesh)**
|
||||
|
||||
```Markdown
|
||||
现在，请给出 `Register` 和 `Login` 这两个方法的完整实现代码。
|
||||
请直接输出这两个函数的完整内容，无需重复输出 Struct 定义。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 策略三：上下文锚点 (Context Anchoring)
|
||||
|
||||
当你完成了第一部分代码（比如 `code.go`），在开始下一部分之前，需要让 AI **“记住但不输出”**，以节省 Token 并防止幻觉。
|
||||
|
||||
### 🤖 关键 Prompt (用于连接两个步骤)
|
||||
|
||||
```Markdown
|
||||
[用户动作]:
|
||||
(将 AI 生成的 code.go 代码复制到本地 IDE，确认无误)
|
||||
|
||||
[发送给 AI 的指令]:
|
||||
已确认 `code.go` 代码无误。
|
||||
现在，请将以下代码作为**“已知上下文”**存入你的短期记忆，**不要重复输出它**，但在后续生成 `msg.go` 时必须严格遵守其中的常量定义。
|
||||
|
||||
[粘贴 code.go 的完整代码]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ 你的工作流修正建议
|
||||
|
||||
回到你当前的 **错误处理模块**，我建议你采用 **“策略一：按物理文件拆分”**。
|
||||
|
||||
因为你的 `code` 包和 `app` 包本身就应该物理隔离，避免循环依赖。
|
||||
|
||||
**推荐的执行顺序：**
|
||||
|
||||
1. **Prompt:** 生成 `internal/pkg/code/err_code.go` (仅包含 const)。
|
||||
2. **Prompt:** 生成 `internal/pkg/code/err_msg.go` (包含 map 和 Text 方法)。
|
||||
3. **Prompt:** 生成 `internal/pkg/app/response.go` (包含 Response 结构体和 Success/Error 方法)。
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 🧩 SOP 补丁：MECE 任务拆解协议 (The MECE Protocol)
|
||||
date created: 星期三, 十二月 10日 2025, 9:26:43 上午
|
||||
date modified: 星期三, 十二月 10日 2025, 9:30:27 上午
|
||||
---
|
||||
|
||||
# 🧩 SOP 补丁：MECE 任务拆解协议 (The MECE Protocol)
|
||||
|
||||
**适用场景:** 任何代码行数预估 > 200 行，或涉及多个文件交互的大型模块（如：错误处理、RBAC 权限系统、订单状态机）。
|
||||
|
||||
**插入位置:** 在原有 SOP 的 **[阶段一：契约定义]** 之前执行。
|
||||
|
||||
---
|
||||
|
||||
## 阶段 0: 原子化任务拆解 (Atomic Decomposition)
|
||||
|
||||
**目的:** 将大需求拆解为一组符合 **MECE 原则 (相互独立，完全穷尽)** 的微任务。确保每个微任务的上下文长度都在 AI 的“舒适区”内，且具备清晰的依赖顺序。
|
||||
|
||||
### 🤖 拆解者 Prompt (复制使用)
|
||||
|
||||
```Markdown
|
||||
你现在是我的 **Tech Lead (技术负责人)**。
|
||||
我们要实现 `{模块名称}` 模块。为了防止代码生成中断和逻辑混乱，请不要直接开始写代码。
|
||||
|
||||
请先执行 **“MECE 任务拆解”**：
|
||||
|
||||
**1. 依赖分析:**
|
||||
分析该模块涉及哪些物理文件？它们之间的依赖关系是什么？(例如：B 依赖 A，则 A 必须先完成)。
|
||||
|
||||
**2. 原子化切分:**
|
||||
将开发工作拆解为 3-5 个“原子任务步”。
|
||||
- 每个步骤必须针对**单个物理文件**或**一组紧密相关的函数**。
|
||||
- 每个步骤必须是独立的，可执行的。
|
||||
|
||||
**3. 输出格式:**
|
||||
请输出一个 **Markdown Checklist (执行清单)**。
|
||||
格式示例：
|
||||
- [ ] **Step 1: {文件名}** - {核心职责} (依赖: 无)
|
||||
- [ ] **Step 2: {文件名}** - {核心职责} (依赖: Step 1)
|
||||
…
|
||||
|
||||
**模块上下文:**
|
||||
{此处粘贴你的需求或 PRD 片段}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ 你的工作流变更 (Workflow Update)
|
||||
|
||||
引入此补丁后，你的新工作流变成了：
|
||||
|
||||
1. **Phase 0 (New):** 发送拆解 Prompt -> **获得清单**。
|
||||
2. **Phase 1 (User Action):** 选中清单中的 **Step 1** -> 发送 Prompt：“请执行 Step 1，生成 `code.go`…”。
|
||||
3. **Phase 2 (User Action):** 拿到代码 -> 存入本地 -> **锚点确认** ("Step 1 已完成，代码如下…")。
|
||||
4. **Phase 3 (User Action):** 选中清单中的 **Step 2** -> 发送 Prompt：“基于 Step 1，请执行 Step 2…”。
|
||||
|
||||
### 为什么这样做有效？
|
||||
|
||||
1. **Token 节省:** AI 在生成 Step 2 时，不需要你在 Prompt 里重新描述 Step 1 的需求，只需要把 Step 1 已经生成的代码贴给它作为 Context 即可。
|
||||
2. **避免幻觉:** 因为每个 Step 只有一个目标，AI 不会“顾头不顾尾”。
|
||||
3. **断点续传:** 如果 Step 2 生成错了，你只需要重新生成 Step 2，而不需要推倒重来。
|
||||
113
Go项目实战/03_基础设施/02_日志/01_设计目标.md
Normal file
113
Go项目实战/03_基础设施/02_日志/01_设计目标.md
Normal file
@@ -0,0 +1,113 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 核心设计目标 (Core Design Goals)
|
||||
date created: 星期三, 十二月 10日 2025, 10:27:39 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 10:28:15 晚上
|
||||
---
|
||||
|
||||
# 1. 核心设计目标 (Core Design Goals)
|
||||
|
||||
## 目标一：全链路上下文关联 (Contextual Traceability)
|
||||
|
||||
这是最核心的差异点。传统的 `log.Println("Database error")` 在并发环境下毫无价值，因为你不知道这条错误属于哪个请求。
|
||||
|
||||
- **设计要求**:
|
||||
- **自动注入 TraceID**: 必须能够从 `context.Context` 中提取 `TraceID`（目前 `internal/pkg/app` 已经生成了 TraceID），并自动将其附加到每一条日志中。
|
||||
- **请求元数据绑定**: 除了 TraceID，还应支持自动绑定 `UserID`、`IP`、`Method`、`Path` 等元数据，形成请求的完整快照。
|
||||
- **跨组件穿透**: 日志对象必须能够在 Layer 之间传递（例如 Controller -> Service -> Repository），且保持上下文不丢失。
|
||||
|
||||
## 目标二：严格的结构化契约 (Strict Structured Schema)
|
||||
|
||||
日志是写给机器看的，不是写给通过 SSH 连上服务器的人看的。
|
||||
|
||||
- **设计要求**:
|
||||
- **JSON First**: 生产环境强制使用 JSON 格式。
|
||||
- **Schema 统一**: 字段命名必须统一。例如，不要混用 `uid`, `user_id`, `userId`，必须在设计阶段锁定为 snake_case (如 `user_id`)。
|
||||
- **类型安全**: 时间戳必须统一格式（推荐 ISO8601 或 Unix Nano），数字字段不能变成字符串（便于聚合计算）。
|
||||
|
||||
## 目标三：高性能与零侵入 (High Performance & Zero Allocation)
|
||||
|
||||
日志通常是系统中 IO 最密集的组件之一。
|
||||
|
||||
- **设计要求**:
|
||||
- **低 GC 压力**: 利用 Zap 的核心优势，避免大量的 `interface{}` 反射和字符串拼接，使用强类型的 Field（如 `zap.Int`, `zap.String`）。
|
||||
- **异步 IO (可选)**: 考虑是否引入 Buffer 机制（牺牲极端崩溃下的日志完整性换取吞吐量）。
|
||||
- **Level 级联过滤**: 在 Debug 级别关闭时，Debug 级别的日志构造逻辑（如复杂的对象序列化）不应被执行。
|
||||
|
||||
## 目标四：安全与合规 (Security & Compliance)
|
||||
|
||||
这往往是被忽视的一点，也是导致安全事故的频发区。
|
||||
|
||||
- **设计要求**:
|
||||
- **敏感数据脱敏**: 必须具备“黑名单”机制。任何包含 `password`, `token`, `mobile`, `credit_card` 的字段在输出前必须被自动掩盖（Masking）。
|
||||
- **安全截断**: 防止打印过大的 Body（如 Base64 图片上传）导致磁盘爆满或日志系统瘫痪，限制单条日志最大长度。
|
||||
|
||||
---
|
||||
|
||||
# 2. 场景化行为对比 (Dev Vs Prod)
|
||||
|
||||
为了兼顾开发体验和生产运维标准，我们需要在设计中明确区分两种环境的行为。
|
||||
|
||||
|**维度**|**开发环境 (Development)**|**生产环境 (Production)**|**设计意图**|
|
||||
|---|---|---|---|
|
||||
|**编码格式**|Console (彩色，人类易读)|JSON (机器易读)|开发追求直观；生产追求 ELK 解析效率。|
|
||||
|**输出目标**|Stdout (控制台)|File + Stdout (双写)|开发侧容器即焚；生产侧需持久化 + 容器采集。|
|
||||
|**日志级别**|Debug|Info / Warn|生产环境过滤掉大量 Debug 噪音，节省存储成本。|
|
||||
|**堆栈追踪**|Error 级别即打印|Panic 或 Fatal 才打印|减少生产环境日志体积，除非发生严重故障。|
|
||||
|**调用行号**|显示 (Caller)|显示 (Caller)|快速定位代码位置。|
|
||||
|
||||
---
|
||||
|
||||
# 3. 架构定位与边界 (Architecture Boundary)
|
||||
|
||||
我们需要明确日志模块在架构中的位置：
|
||||
|
||||
- **位置**: 属于 `Infrastructure Layer` (Level 0/1)。
|
||||
- **依赖关系**:
|
||||
- **被谁依赖**: 所有层（Handler, Service, Repository）都依赖 Log。
|
||||
- **依赖谁**: 仅依赖标准库和第三方 Log Driver (Zap)，**不应依赖业务逻辑**。
|
||||
- **与其他模块的关系**:
|
||||
- **vs `ecode`**: `ecode` 定义错误的**类型**（Code），Log 记录错误的**现场**（Stack/Trace）。
|
||||
- **vs `app.Response`**: Response 负责**对用户说话**（经过清洗的、友好的信息），Log 负责**对开发者说话**（原始的、包含脏数据的真相）。
|
||||
|
||||
---
|
||||
|
||||
# 4. 深度反思与自我反驳 (Critical Thinking & Risk Analysis)
|
||||
|
||||
在敲定设计目标前，必须审视潜在的矛盾和风险：
|
||||
|
||||
**反驳点 1：全链路上下文（TraceID）的传递成本**
|
||||
|
||||
- **挑战**: 要想让 Repository 层的日志也打出 TraceID，必须修改所有方法的签名为 `func (ctx context.Context, …)`。这对现有代码（如果是非 Context 风格）是巨大的重构。
|
||||
- **回应**: 我们的 `Repository` 接口目前设计中已经包含了 `context.Context`。这是一个必须遵守的“硬约束”。如果缺少 Context，日志将断层。
|
||||
- **结论**: 必须在规范中强调：**所有层级的方法首个参数必须是 Context**。
|
||||
|
||||
**反驳点 2：脱敏机制的性能损耗**
|
||||
|
||||
- **挑战**: 如果每一条日志都要遍历字段去匹配“黑名单”进行正则替换，CPU 开销极大。
|
||||
- **回应**: 不能使用正则扫描全文。
|
||||
- **修正方案**: 利用 Zap 的 `Hook` 或 `Core` 包装，仅针对特定 Key（如 `password`）进行值替换，或者要求开发者在打印敏感结构体时显式调用 `.Reduct()` 方法，而非隐式全局扫描。隐式扫描在 Golang 中通常是性能杀手。
|
||||
|
||||
**反驳点 3：异步写入的丢数据风险**
|
||||
|
||||
- **挑战**: 为了性能使用 `Buffered Write`，如果进程被 `kill -9` 或 Panic 崩溃，缓冲区日志会丢失，而崩溃前的日志往往最重要。
|
||||
- **回应**: 对于交易类系统，**可靠性 > 吞吐量**。
|
||||
- **结论**: 默认采用 **同步写入 (Sync Write)**。Zap 本身性能已经足够强（纳秒级），除非达到数万 QPS，否则不需要引入 Buffer。对于 Panic，必须使用 `defer logger.Sync()` 确保刷盘。
|
||||
|
||||
---
|
||||
|
||||
# 5. 待确认问题 (Open Questions)
|
||||
|
||||
在进入下一步（编写详细规格说明书）之前，我需要确认你对以下几点的偏好：
|
||||
|
||||
1. **全局单例 vs 纯依赖注入**:
|
||||
|
||||
- _选项 A_: 提供 `log.Info()` 全局静态方法（方便，但有副作用）。
|
||||
- _选项 B_: 强制必须通过 `l.Info()` 实例方法调用（架构更洁癖，但调用繁琐）。
|
||||
- _推荐_: **选项 A + B**。提供全局方法作为快捷方式（底层代理到单例），同时支持 DI 注入。你倾向于哪种？
|
||||
|
||||
2. **日志轮转 (Rotation) 策略**:
|
||||
|
||||
- 你是倾向于按 **大小** 切割（如 100MB 一个文件），还是按 **时间** 切割（每天一个文件）？
|
||||
- _通常建议_: 按大小切割（防止单文件过大无法打开），配合最大文件保留数。
|
||||
99
Go项目实战/03_基础设施/02_日志/02_技术栈基线.md
Normal file
99
Go项目实战/03_基础设施/02_日志/02_技术栈基线.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 核心引擎 (The Engine)：Uber Zap
|
||||
date created: 星期三, 十二月 10日 2025, 10:28:15 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 10:29:20 晚上
|
||||
---
|
||||
|
||||
# 1. 核心引擎 (The Engine)：Uber Zap
|
||||
|
||||
行业共识 (Consensus):
|
||||
|
||||
在 Go 语言的高性能后端领域，go.uber.org/zap 是目前无可争议的事实标准（De Facto Standard）。
|
||||
|
||||
我的推荐:
|
||||
|
||||
坚定地使用 Zap，不要犹豫。
|
||||
|
||||
**老兵的经验谈 (Why & How):**
|
||||
|
||||
- **为何不是 Logrus?** Logrus 胜在 API 极其友好（兼容标准库），但它底层大量使用反射（Reflection）和锁，在高并发场景下是严重的性能瓶颈（GC 压力大）。
|
||||
- **为何不是 Slog (Go 1.21+)?** Slog 是 Go 官方推出的结构化日志接口。虽然它是未来，但目前的生态和性能优化（尤其是在 JSON 序列化的极致性能上）尚未完全超越 Zap。且 Zap 可以很方便地作为 Slog 的 Backend。但在本项目中，为了追求极致性能和成熟度，直接使用 Zap 原生 API 是最高效的。
|
||||
- **关键决策点**:
|
||||
- **Field 强类型**: 我们必须强制团队使用 `zap.String("key", "val")` 而非 `zap.Any("key", val)`。`Any` 会导致反射，破坏 Zap 的零内存分配（Zero Allocation）优势。这是代码审查（Code Review）的红线。
|
||||
- **Logger vs SugaredLogger**:
|
||||
- **核心业务链路 (Hot Path)**: 使用 `zap.Logger`（极致性能，但语法繁琐）。
|
||||
- **初始化/非热点代码**: 使用 `zap.SugaredLogger`（语法类似 `printf`，性能稍弱但开发快）。
|
||||
- **基线**: 我们的封装层默认暴露 `Logger` 能力，保留高性能入口。
|
||||
|
||||
# 2. 轮转插件 (Rotation): Lumberjack V2
|
||||
|
||||
行业共识 (Consensus):
|
||||
|
||||
日志切割看似简单，实则坑多（并发写冲突、文件重命名原子性、不同操作系统的文件锁差异）。
|
||||
|
||||
我的推荐:
|
||||
|
||||
使用 gopkg.in/natefinch/lumberjack.v2。
|
||||
|
||||
**老兵的经验谈:**
|
||||
|
||||
- **不要造轮子**: 我见过无数团队尝试自己写 `file.Write` 然后计数切割，最后都在“多进程并发写同一个日志文件”或者“日志压缩时导致 IO 飙升”这些问题上翻车。
|
||||
- **配置陷阱**:
|
||||
- `MaxSize`: 建议 **100MB**。太小导致文件碎片化，太大导致像 grep/vim 这种工具打开困难。
|
||||
- `MaxBackups`: 建议保留 **30-50 个**。
|
||||
- `MaxAge`: 建议 **7-14 天**。
|
||||
- **Compress**: 建议 **开启 (True)**。历史日志压缩存储（gzip）能节省 90% 以上的磁盘空间，这对于云盘成本控制非常重要。
|
||||
|
||||
# 3. 上下文管理 (Context Awareness): 自研封装层
|
||||
|
||||
这是我们作为“架构师”必须介入的地方。原生 Zap 不懂业务上下文，我们需要一个胶水层。
|
||||
|
||||
技术难点:
|
||||
|
||||
如何优雅地把 TraceID 塞进每一行日志？
|
||||
|
||||
设计路线:
|
||||
|
||||
我们需要定义一个轻量级的 Wrapper 或者 Helper 函数。
|
||||
|
||||
- **不要**：重写 `zap.Logger` 结构体的所有方法（那样维护成本太高）。
|
||||
- **要**：提供一个入口函数，例如 `log.WithContext(ctx)`。
|
||||
- **原理**：这个函数会从 `ctx` 取出 `TraceID`，然后调用 `zap.With(zap.String("trace_id", id))`，返回一个携带了该字段的子 Logger 实例。这是一次极低成本的指针操作。
|
||||
|
||||
# 4. 抽象策略与混合模式 (Hybrid Pattern)
|
||||
|
||||
结合你选择的 **Option A+B**，我们的技术实现路径如下：
|
||||
|
||||
1. **全局变量 (The Global)**:
|
||||
|
||||
- 在 `internal/pkg/log` 包内部维护一个私有的 `var globalLogger *zap.Logger`。
|
||||
- 利用 `sync.Once` 确保其并发安全的初始化。
|
||||
- **兜底策略**: 在 `init()` 函数中先给它一个默认的 `Console Logger`。这样即使开发者忘记调用 `InitLogger`，程序启动时的日志也不会 panic，只会打印到控制台。
|
||||
|
||||
2. **依赖注入 (The DI)**:
|
||||
|
||||
- 在 `internal/pkg/log` 暴露一个 `Provider` 函数，供 Wire 使用。
|
||||
- 这个 Provider 返回的必须是**同一个**底层 Zap 实例的引用（或者其派生），确保配置（如 Level、Output Path）是一致的。
|
||||
|
||||
---
|
||||
|
||||
# 总结：最终的技术栈清单
|
||||
|
||||
|**组件**|**选型**|**理由**|
|
||||
|---|---|---|
|
||||
|**Logger Core**|`go.uber.org/zap` (v1.27+)|高性能、类型安全、零内存分配。|
|
||||
|**Rotation**|`gopkg.in/natefinch/lumberjack.v2`|成熟稳定，处理并发写文件不仅是事实标准，更是避坑指南。|
|
||||
|**Config**|`spf13/viper` (已引入)|利用现有的 Viper 读取 yaml 配置，实现动态等级调整。|
|
||||
|**Trace Inject**|`Custom Wrapper` (Standard Lib)|基于 `context` 的轻量封装，连接 `gin.Context` 与 `zap.Fields`。|
|
||||
|
||||
老师的最后叮嘱 (The Moral of the story):
|
||||
|
||||
我们现在的设计，本质上是在 Zap 的高性能 和 业务开发的便利性 之间走钢丝。
|
||||
|
||||
最大的风险在于：封装层写得太重。
|
||||
|
||||
如果我们在 log.Info 里面加了太多的锁、反射或者字符串拼接，那么引入 Zap 的意义就没了。所以，接下来的详细设计文档中，我们要时刻警惕“过度封装”。
|
||||
|
||||
如果这个技术栈基线你没有异议，我们就以此为基础，开始生成《全局日志模块详细设计规格说明书》。
|
||||
80
Go项目实战/03_基础设施/02_日志/03_核心设计模式.md
Normal file
80
Go项目实战/03_基础设施/02_日志/03_核心设计模式.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 核心模式：装饰器模式的变体 (Context-Decorator Pattern)
|
||||
date created: 星期三, 十二月 10日 2025, 10:37:54 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 10:38:26 晚上
|
||||
---
|
||||
|
||||
# 1. 核心模式：装饰器模式的变体 (Context-Decorator Pattern)
|
||||
|
||||
这是我们处理 `TraceID` 和上下文的核心手段。
|
||||
|
||||
- 传统误区 (Over-Abstraction)：
|
||||
|
||||
定义一个庞大的 MyLogger 结构体，把 zap.Logger 藏在里面，然后重写 Info, Error 等所有方法。
|
||||
|
||||
- _后果_：维护成本极高，每次 Zap 更新或增加新特性（如 `Panic` 或 `DPanic`），你都得跟着改代码。且容易在转发参数时产生逃逸分析（Escape Analysis）导致的内存分配。
|
||||
- 我们的决策 (The Thin Wrapper)：
|
||||
|
||||
只封装“获取 Logger”的动作，不封装“Logger 本身”。
|
||||
|
||||
我们将定义一个函数 log.WithContext(ctx context.Context) *zap.Logger。
|
||||
|
||||
- _行为_：这个函数极其轻量。它从 `ctx` 中取出 `TraceID`，调用 `zap.With()` 生成一个新的 Zap 实例并返回。
|
||||
- _优势_：业务代码拿到的依然是原生的 `*zap.Logger`。这意味着开发者可以直接使用 Zap 强大的 `zap.String`, `zap.Int` 等强类型字段构建方法，享受极致性能，没有任何中间层损耗。
|
||||
|
||||
# 2. 接口策略：拒绝通用接口 (Concrete Type Dependency)
|
||||
|
||||
这是 Go 语言工程实践中关于日志的一个特殊共识，也是反直觉的地方。
|
||||
|
||||
- 传统误区 (The Java/Interface Way)：
|
||||
|
||||
定义一个 type ILogger interface { Info(msg string, args …interface{}) }。
|
||||
|
||||
- _后果_：`args …interface{}` 会导致大量的反射（Reflection）和装箱（Boxing），这直接抹杀了 Zap 存在的意义。Zap 的核心设计哲学就是通过 `zap.Field` 避免使用 `interface{}`。
|
||||
- 我们的决策 (Concrete Type)：
|
||||
|
||||
直接依赖 *zap.Logger 具体类型。
|
||||
|
||||
- _原则_：在 Handler、Service、Repository 层，注入的类型就是 `*zap.Logger`。
|
||||
- _测试怎么办_：不要 Mock 日志接口。在单元测试中，直接传入 `zap.NewNop()`（什么都不做）或者 `zap.NewExample()`（输出到测试控制台）。这比 Mock 一个接口要简单且真实得多。
|
||||
|
||||
# 3. 访问模式：混合单例与依赖注入 (The Hybrid Accessor)
|
||||
|
||||
结合之前讨论的 Option A+B，我们通过设计模式来解决“初始化顺序”和“热加载”的问题。
|
||||
|
||||
- 设计挑战：
|
||||
|
||||
如果 main.go 还没来得及读配置初始化 Logger，其他 init() 函数里就调用了日志，程序会 Panic。
|
||||
|
||||
- **我们的决策 (Thread-Safe Proxy)**：
|
||||
- **原子替换 (Atomic Swap)**：全局变量 `globalLogger` 不会直接暴露给外部修改。我们将使用 `unsafe.Pointer` 或 `atomic.Value` (配合 Zap 的 `ReplaceGlobals`) 来保证在运行时重新加载配置（如动态修改 Log Level）时，不会发生并发读写冲突。
|
||||
- **懒汉式兜底 (Lazy Fallback)**：在 `internal/pkg/log` 的 `init()` 中，我们会默认初始化一个 `Console Logger`。这样即使 `main` 函数一行代码都没跑，只要引用了包，日志功能就是可用的（虽然配置是默认的）。这极大提升了开发体验（DX）。
|
||||
|
||||
# 4. 字段构建模式：结构化优先 (Field-First API)
|
||||
|
||||
这关乎团队的编码规范，属于 API 设计模式。
|
||||
|
||||
- 传统误区 (Printf Style)：
|
||||
|
||||
使用 SugaredLogger 的 Infof("User %s login failed, error: %v", user, err)。
|
||||
|
||||
- _后果_：日志分析系统（ELK）只能拿到一串文本，无法对 `user` 进行聚合统计。
|
||||
- 我们的决策 (Structured Style)：
|
||||
|
||||
默认只暴露 Logger（强类型），在必要时才暴露 SugaredLogger。
|
||||
|
||||
- _强制规范_：代码中必须写成 `log.Info("user login failed", zap.String("user", user), zap.Error(err))`。
|
||||
- _设计意图_：通过 API 的设计，“强迫”开发者思考每一个字段的语义。这虽然写起来繁琐一点，但对于后期的运维和排查是无价的。
|
||||
|
||||
---
|
||||
|
||||
# 总结：设计规格书的基调
|
||||
|
||||
基于以上讨论，在接下来的规格说明书中，我们将确立以下基调：
|
||||
|
||||
1. **不造轮子**：核心逻辑全权委托给 `zap` 和 `lumberjack`。
|
||||
2. **薄封装**：`pkg/log` 代码行数应控制在 200 行以内，只做配置解析和 Context 桥接。
|
||||
3. **强类型**：严禁在核心路径使用 `interface{}`。
|
||||
4. **显式传递**：通过 `WithContext` 显式传递上下文，而不是依赖某些黑魔法（如 Goroutine Local Storage）。
|
||||
123
Go项目实战/03_基础设施/02_日志/04_架构逻辑.md
Normal file
123
Go项目实战/03_基础设施/02_日志/04_架构逻辑.md
Normal file
@@ -0,0 +1,123 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 代码组织方式 (Code Organization)
|
||||
date created: 星期三, 十二月 10日 2025, 10:42:21 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:38:44 晚上
|
||||
---
|
||||
|
||||
# 1. 代码组织方式 (Code Organization)
|
||||
|
||||
我们将遵循 **“高内聚、低耦合”** 的原则，将日志模块放置在 `internal/pkg/log` 下。这里是所有日志逻辑的物理家园。
|
||||
|
||||
建议的文件结构如下（逻辑分层）：
|
||||
|
||||
- **`log.go` (Facade/Entry Point)**:
|
||||
- 这是对外暴露的统一入口。包含全局单例的定义、初始化函数 (`Init`)、以及最常用的静态方法代理（如 `Info`, `Error`, `WithContext`）。
|
||||
- **设计意图**: 让其他模块只 import 这一个包就能完成 90% 的工作。
|
||||
- **`options.go` (Configuration)**:
|
||||
- 定义配置结构体（Level, Filename, MaxSize, MaxAge 等）。
|
||||
- **设计意图**: 将配置解析逻辑与日志初始化逻辑分离，方便单元测试。
|
||||
- **`zap.go` (Core Implementation)**:
|
||||
- 负责 `zap.Logger` 的具体构建。包含 Encoder 配置（JSON vs Console）、Writer 配置（Lumberjack 集成）和 Level 动态调整逻辑。
|
||||
- 这是“脏活累活”集中的地方，屏蔽 Zap 的复杂构建细节。
|
||||
- **`context.go` (The Bridge)**:
|
||||
- **核心组件**。实现 `TraceID` 的提取逻辑。
|
||||
- 定义如何从 `context.Context` 中挖掘元数据，并将其转化为 `zap.Field`。
|
||||
|
||||
---
|
||||
|
||||
# 2. 调用方式与依赖注入 (Invocation & DI)
|
||||
|
||||
这里有一个经典的架构冲突：**Singleton（单例） vs Dependency Injection（依赖注入）**。我们的策略是 **“依赖注入为主，单例为辅”**，但在具体使用上有一个极其重要的**反直觉设计**。
|
||||
|
||||
## A. 为什么 Service 层不应保存 Request Logger？
|
||||
|
||||
你可能会想在 Service 初始化时注入一个带 Context 的 Logger。
|
||||
|
||||
- **错误做法**: `type UserService struct { logger *zap.Logger }`，然后在请求进来时试图把 request-scoped 的 logger 塞进去。
|
||||
- **架构事实**: 在 Wire 依赖注入中，`Service`、`Repository` 通常是 **单例 (Singleton)** 的（即整个应用生命周期只有一个实例）。
|
||||
- **结论**: 你**不能**把属于某一次 HTTP 请求的 `TraceID` 注入到单例的 Struct 成员变量中。
|
||||
|
||||
## B. 正确的调用范式 (The Best Practice)
|
||||
|
||||
Logger 作为**工具能力**被注入，Context 作为**请求参数**被传递。
|
||||
|
||||
1. **依赖注入 (Setup Phase)**:
|
||||
|
||||
- 在 `NewUserUsecase` 时，注入基础的 `*zap.Logger`（不带 TraceID）。
|
||||
- 这个 Logger 配置好了输出路径、Level 等全局属性。
|
||||
|
||||
2. **方法调用 (Runtime Phase)**:
|
||||
|
||||
- 在具体的方法（如 `Register`）中，使用 `log.WithContext(ctx)` 来“临时”生成一个带有 TraceID 的 Logger 实例。
|
||||
|
||||
**示例逻辑流**:
|
||||
|
||||
- **Struct 定义**: `struct { baseLogger *zap.Logger }`
|
||||
- **方法内部**: `l := log.WithContext(ctx, u.baseLogger)` -> `l.Info("user registered")`
|
||||
- **说明**: 这里的 `WithContext` 是一个纯内存操作（浅拷贝），开销极小，可以放心高频调用。
|
||||
|
||||
## C. 高性能场景：作用域复用 (Scoped Logger)
|
||||
|
||||
虽然 `log.WithContext` 是浅拷贝，但在循环或长链路中频繁调用仍会产生大量临时对象，增加 GC 压力。
|
||||
|
||||
- **反模式 (Anti-Pattern)**: 在 `for` 循环内部调用 `log.WithContext(ctx)`。
|
||||
- **最佳实践 (Best Practice)**: **作用域提升**。在函数或循环入口处调用一次 `WithContext`，生成局部变量 `l` (Logger)，随后全程复用该变量。
|
||||
|
||||
---
|
||||
|
||||
# 3. 数据流与 TraceID 传递 (Data Flow)
|
||||
|
||||
这是实现“全链路可观测性”的生命线。数据流必须打通以下四个关卡：
|
||||
|
||||
## 关卡 1：入口 (Entry - Middleware)
|
||||
|
||||
- **位置**: `internal/middleware/trace.go` (需新建) 或集成在 `response` 包中。
|
||||
- **行为**: 当 HTTP 请求到达，生成一个 UUID。
|
||||
- **动作**: 使用 `c.Set("X-Trace-ID", uuid)` 将其放入 Gin 的上下文存储中。同时，将其放入 HTTP Response **动作**:
|
||||
1. 调用 `pkg/log.WithTraceID(ctx, uuid)` 将 `UUID` 注入标准 `Context`。
|
||||
2. 执行 `c.Request = c.Request.WithContext(newCtx)` 将其回写。
|
||||
3. (可选) 同时放入 Gin 上下文存储和 Response Header 供前端使用。
|
||||
|
||||
## 关卡 2：桥接 (Bridge - Context Adapter)
|
||||
|
||||
- **位置**: `internal/pkg/log/context.go`
|
||||
- **设计原则**: `pkg/log` **不依赖** `gin`，只识别标准库 `context.Context`。
|
||||
- **行为**: `log.WithContext(ctx) 调用内部帮助函数 GetTraceID(ctx) 获取 TraceID。`
|
||||
- **前置条件**: 必须依赖上游（Middleware）将 TraceID 提前注入到标准 Context 中。
|
||||
- **输出**: 返回一个预置了 `zap.String("trace_id", id)` 字段的 Logger。
|
||||
|
||||
## 关卡 3：穿透 (Propagation - Service/Repo)
|
||||
|
||||
- **行为**: 所有的业务方法签名必须包含 `ctx context.Context` 作为第一个参数。
|
||||
- **动作**: 严禁在层级调用中丢弃 Context（例如使用 `context.Background()` 替代传入的 ctx），这会导致链路断裂。
|
||||
|
||||
## 关卡 4：异步与后台边界 (Async & Background Boundary)
|
||||
|
||||
- **高危场景**: 在 Handler 中启动 Goroutine 处理耗时任务。
|
||||
- **陷阱**: `gin.Context` 是非线程安全的。如果 Goroutine 执行时 HTTP 请求已结束，Gin 会重置该 Context，导致数据竞争或脏读。
|
||||
- **解决方案**: 必须在主协程中执行 `ctx.Copy()`，将副本传递给 Goroutine。日志模块必须支持处理这种副本 Context。
|
||||
- **新增场景：后台任务 (Background Tasks)**
|
||||
- **场景**: 定时任务 (Cron)、消息队列消费者 (MQ Consumer)、系统初始化。
|
||||
- **问题**: 初始 `context.Background()` 不包含 TraceID。
|
||||
- **动作**: 必须调用 `log.StartBackgroundTrace(ctx)` 进行“播种”。该函数会检测 Context，若无 TraceID 则生成新 ID 并注入，确保链路可追踪。
|
||||
|
||||
---
|
||||
|
||||
# 4. 关键架构思考：防腐层 (Anti-Corruption Layer)
|
||||
|
||||
我们在设计时还需考虑一层“防腐”。
|
||||
|
||||
- **问题**: 如果未来我们想给所有的日志加一个字段，比如 `env=prod`，或者想把所有的 `trace_id` 改名为 `traceId`。
|
||||
- **对策**: 所有的业务代码**严禁**直接手动构建 `zap.String("trace_id", …)`。
|
||||
- **约束**: 这个字段的 Key 必须定义在 `pkg/log` 的常量中，且只能由 `WithContext` 内部逻辑自动附加。业务开发者只负责传 Context，不负责管 ID 怎么拼写。
|
||||
|
||||
---
|
||||
|
||||
# 总结
|
||||
|
||||
- **代码位置**: `internal/pkg/log`，包含 `log.go` (入口), `zap.go` (实现), `context.go` (桥接)。
|
||||
- **调用方式**: 注入 Base Logger -> 方法内 `WithContext(ctx)` -> 打印。
|
||||
- **数据流**: Middleware 生成 -> Gin Context 携带 -> Log Adapter 提取 -> Zap Field 输出。
|
||||
- **并发安全**: 警惕 Gin Context 在 Goroutine 中的误用，强调 `Copy()` 机制。
|
||||
76
Go项目实战/03_基础设施/02_日志/05_目录结构与职责.md
Normal file
76
Go项目实战/03_基础设施/02_日志/05_目录结构与职责.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 目录结构与职责
|
||||
date created: 星期三, 十二月 10日 2025, 10:45:40 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:40:48 晚上
|
||||
---
|
||||
|
||||
# 目录结构与职责
|
||||
|
||||
## 1. 目录结构设计 (Directory Structure)
|
||||
|
||||
该结构旨在实现 **“配置分离”**、**“核心隐藏”** 与 **“上下文桥接”**。
|
||||
|
||||
```Plaintext
|
||||
internal/
|
||||
├── middleware/ # [Global] 全局中间件层
|
||||
│ ├── access_log.go # [New] HTTP 请求访问日志 (请求入/出记录, 耗时统计)
|
||||
│ └── trace.go # [New] 链路追踪 (生成/透传 TraceID -> 注入 Context)
|
||||
│
|
||||
└── pkg/
|
||||
└── log/ # [Level 0] 全局日志核心包 (基于 Zap)
|
||||
├── log.go # [Facade] 对外入口 (Init, Global L(), Static Proxies)
|
||||
├── options.go # [Config] 配置定义 (Level, FilePath, MaxSize)
|
||||
├── zap.go # [Core] Zap 实例构建 (Encoder, Core, AtomicLevel)
|
||||
├── writer.go # [IO] 输出源管理 (Lumberjack 轮转, Console/File 双写)
|
||||
├── context.go # [Bridge] 上下文桥接 (WithContext, TraceID 提取)
|
||||
└── standard.go # [Schema] 标准字段定义 (Standardized Field Constructors)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 文件职责详解 (Responsibilities)
|
||||
|
||||
### A. `internal/pkg/log` (核心日志包)
|
||||
|
||||
这是一个基础设施包，不应依赖任何业务逻辑（User, Order 等）。
|
||||
|
||||
| **文件名** | **职责描述** | **关键设计点 (Design Decisions)** |
|
||||
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **`log.go`** | **门面 (Facade) 与单例管理**。<br>1. 维护私有全局变量 `globalLogger`。<br>2. 提供 `Init(opts)` 初始化入口。<br>3. 提供 `L()` 获取底层 `*zap.Logger`。<br>4. 提供 `Info/Error` 等静态代理方法。 | **单例兜底**：在 `init()` 中初始化一个默认的 `Nop` 或 `Console` Logger，防止未初始化调用导致 Panic。<br>**Caller 修正**：<br>1. 底层 `globalLogger` 配置 `AddCallerSkip(0)`。<br>2. 静态代理方法 (`Info`, `Error`) 内部使用 `WithOptions(AddCallerSkip(1))`。<br>3. `L()` 和 `WithContext()` 返回原生 Logger (Skip 0)，确保业务层直接调用时行号正确。 |
|
||||
| **`options.go`** | **配置对象 (DTO)**。<br>定义 `Options` 结构体，用于接收 Viper 的配置映射。 | **配置解耦**：只定义 struct，不包含逻辑。支持从 `config.yaml` 的 `log` 节点自动 Unmarshal。 |
|
||||
| **`zap.go`** | **核心构建工厂 (Factory)**。<br>负责组装 Encoder (JSON/Console)、Writer 和 Level。<br>实现 `New(opts)` 函数。 | **环境隔离**：<br>- Dev: ConsoleEncoder + StackTrace (Warn 级)<br>- Prod: JsonEncoder + StackTrace (Panic 级) |
|
||||
| **`writer.go`** | **IO 输出管理**。<br>封装 `lumberjack.Logger`。<br>实现 `zapcore.WriteSyncer` 接口。 | **可靠性**：配置 `Lumberjack` 的 `Compress: true` 和 `MaxSize: 100MB`。实现 Console + File 的 **Tee (双写)** 模式。 |
|
||||
| **`context.go`** | **上下文装饰器与播种器 (Decorator & Seeder)**。<br>1. `WithContext(ctx)`: 提取 TraceID。<br>2. **[New] `StartBackgroundTrace(ctx)`**: 为后台任务生成并注入根 TraceID。 | **零侵入**：仅通过 `zap.With()` 附加字段，返回 **派生 Logger**，不修改全局 Logger，线程安全。 |
|
||||
| **`standard.go`** | **标准化字段与存取器 (Schema & Accessor)**。<br>1. 定义**私有** Context Key 类型，防止碰撞。<br>2. 提供 `WithTraceID(ctx, id)` 和 `GetTraceID(ctx)` 公开方法。<br>3. 定义标准字段构造器 (如 `zap.String("trace_id", …)`)。 | **规范约束**：<br>- 统一使用 snake_case。<br>- 防止拼写错误 (如 `uid` vs `user_id`)。 |
|
||||
|
||||
### B. `internal/middleware` (中间件集成)
|
||||
|
||||
这是日志模块与 HTTP 框架 (Gin) 结合的触点。
|
||||
|
||||
| **文件名** | **职责描述** | **交互逻辑** |
|
||||
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
|
||||
| **`trace.go`** | **链路起点**。<br>链路追踪 (生成 TraceID -> **注入标准 Context** -> 挂载回 Gin Request) | **上下游打通**：保证 TraceID 在微服务或网关间的透传能力。 |
|
||||
| **`access_log.go`** | **流量审计**。<br>1. 记录 `Start Time`。<br>2. 执行 `c.Next()`。<br>3. 计算 `Latency`。<br>4. 打印结构化日志。 | **字段映射**：<br>`path`, `method`, `status`, `client_ip`, `latency`, `user_agent`。**必须使用 `log.WithContext(c)`**。 |
|
||||
| `recovery.go` | 结构化灾难恢复。<br>1. `defer recover()` 捕获 Panic。<br>2. 获取 Stack Trace。<br>3. **调用 `pkg/log` 记录 JSON 格式的 Error 日志** (包含 `stack` 字段)。<br>4. 返回 500 响应。 | **替代 Gin 默认组件**：必须使用 `gin.New()` 启动，手动注册此中间件，杜绝默认的控制台文本打印。 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 数据流转图示 (Data Flow)
|
||||
|
||||
为了确保你理解“上下文”是如何流动的，以下是逻辑路径：
|
||||
|
||||
1. **Request In** -> `middleware/trace.go` -> 生成 `trace_id` -> **Wrap 进 `std.Context`**。 …
|
||||
2. **`pkg/log/context.go`** -> 从 **`std.Context`** 取出 `trace_id` -> …
|
||||
3. **`pkg/log/context.go`** -> 从 `gin.Context` 取出 `trace_id` -> 创建带字段的 `zap.Logger`。
|
||||
4. **`pkg/log/zap.go`** -> 序列化为 JSON `{…"trace_id":"xyz"…}`。
|
||||
5. **`pkg/log/writer.go`** -> 写入 `app.log` 文件 (由 Lumberjack 轮转)。
|
||||
|
||||
## 4. 依赖关系检查 (Dependency Check)
|
||||
|
||||
- `pkg/log` **不依赖** `middleware` (防止循环依赖)。
|
||||
- `middleware` **依赖** `pkg/log` (调用日志打印)。
|
||||
- `pkg/log` **仅依赖** `uber-go/zap`, `natefinch/lumberjack`。**严禁依赖** `gin` 或其他 Web 框架。所有 Context 操作均基于 Go 标准库接口。
|
||||
|
||||
这个结构完全穷尽了我们在前几轮讨论中确定的技术决策。如果确认无误，我们将在下一步生成具体的代码实现。
|
||||
181
Go项目实战/03_基础设施/02_日志/06_日志模块开发规范与质量保证手册.md
Normal file
181
Go项目实战/03_基础设施/02_日志/06_日志模块开发规范与质量保证手册.md
Normal file
@@ -0,0 +1,181 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 《日志模块开发规范与质量保证手册》
|
||||
- 一、 核心开发规范 (The Golden Rules)
|
||||
date created: 星期三, 十二月 10日 2025, 10:53:19 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:31:04 晚上
|
||||
---
|
||||
|
||||
# 《日志模块开发规范与质量保证手册》
|
||||
|
||||
---
|
||||
|
||||
## 一、 核心开发规范 (The Golden Rules)
|
||||
|
||||
这部分是“软约束”，属于团队共识，通过 Code Review 和 AI 辅助检查来执行。
|
||||
|
||||
### 1. 键名命名公约 (Key Naming Convention)
|
||||
|
||||
日志是给机器（ELK/Loki）读的，键名必须统一，方便建立索引。
|
||||
|
||||
- **规则**: 严禁使用 CamelCase (小驼峰) 或 PascalCase (大驼峰)，**必须且只能使用 snake_case (下划线命名)**。
|
||||
- **反例**: `userId`, `IPAddress`, `httpStatus`
|
||||
- **正例**: `user_id`, `client_ip`, `http_status`
|
||||
- **理由**: 多数数据库和搜索引擎（如 Elasticsearch）的分词器对下划线更友好，且 SQL 查询习惯也是下划线。
|
||||
|
||||
### 2. 类型安全铁律 (Type Safety Strictness)
|
||||
|
||||
利用 Zap 的强类型优势，拒绝隐式转换。
|
||||
|
||||
- **规则**: 在业务热点路径（Hot Path）中，**严禁使用 `zap.Any`、`zap.Reflect` 或 `Sugar` 模式**。
|
||||
- **例外**: 仅在应用启动（Init）、Panic 恢复或非高频的配置加载阶段允许使用 `SugaredLogger`。
|
||||
- **理由**: `zap.Any` 会触发反射（Reflection），导致内存逃逸和 GC 压力。这是高性能系统的“隐形杀手”。
|
||||
|
||||
### 3. 上下文优先原则 (Context First)
|
||||
|
||||
日志不是孤岛，必须依附于请求上下文。
|
||||
|
||||
- **规则**: 所有 Controller、Service、Repository 层的方法，如果需要打印日志，**必须**使用 `log.WithContext(ctx).Info(…)` 及其变体。
|
||||
- **禁止**: 严禁在业务流程中直接调用全局的 `log.Info(…)`（除非是系统级事件，如定时任务启动）。
|
||||
- **理由**: 只有通过 `WithContext`，才能将 TraceID 串联起来。
|
||||
|
||||
### 4. 哨兵值与魔法字符串 (Sentinels & Magic Strings)
|
||||
|
||||
- **规则**: 核心日志字段的 Key 必须定义为常量（Constant）。
|
||||
- **实现**: 在 `pkg/log/standard.go` 中定义 `const TraceIDKey = "trace_id"`。
|
||||
- **禁止**: 代码中出现手写的 `zap.String("trace_id", …)`，防止拼写错误（如写成 `traceid`）。
|
||||
|
||||
### 5. 热点路径复用原则 (Hot Path Reuse)
|
||||
|
||||
针对循环（Loop）或复杂长流程函数，严禁重复构建 Context Logger。
|
||||
|
||||
- **规则**: 必须在作用域入口处初始化 Logger 实例，并在该作用域内复用。
|
||||
- **反例 (Bad)**:
|
||||
|
||||
```Go
|
||||
for _, item := range items {
|
||||
// ❌ 每次循环都分配内存
|
||||
log.WithContext(ctx).Info("processing", zap.String("id", item.ID))
|
||||
}
|
||||
```
|
||||
|
||||
- **正例 (Good)**:
|
||||
|
||||
```Go
|
||||
// ✅ 只分配一次，复用 l
|
||||
l := log.WithContext(ctx)
|
||||
for _, item := range items {
|
||||
l.Info("processing", zap.String("id", item.ID))
|
||||
}
|
||||
```
|
||||
|
||||
- **理由**: 减少大量临时的 `zap.Logger` 结构体分配，降低 GC 的 Scavenge 阶段耗时。
|
||||
|
||||
### 6. 后台任务播种原则 (Background Trace Seeding)
|
||||
|
||||
所有非 HTTP 触发的后台任务入口（Goroutine, Cron, MQ Handler），必须是“有状态”的。
|
||||
|
||||
- **规则**: 任务的第一行代码必须调用 `StartBackgroundTrace`。
|
||||
- **反例 (Bad)**:
|
||||
|
||||
```Go
|
||||
func ProcessOrder(msg []byte) {
|
||||
ctx := context.Background()
|
||||
// ❌ 此时 ctx 空空如也，日志将丢失 TraceID
|
||||
log.WithContext(ctx).Info("processing order")
|
||||
}
|
||||
```
|
||||
|
||||
- **正例 (Good)**:
|
||||
|
||||
```Go
|
||||
func ProcessOrder(msg []byte) {
|
||||
// ✅ 自动生成一个新的 TraceID 注入 ctx
|
||||
ctx := log.StartBackgroundTrace(context.Background())
|
||||
log.WithContext(ctx).Info("processing order")
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 二、 Linter 规则配置 (Automated Enforcement)
|
||||
|
||||
这部分是“硬约束”，我们将在 `.golangci.yml` 中配置这些规则，强行阻断不合规代码的提交。
|
||||
|
||||
### 1. 禁用标准库日志 (`depguard`)
|
||||
|
||||
防止开发人员手滑使用了 Go 原生的 `log` 或 `fmt` 打印日志。
|
||||
|
||||
Linter: depguard
|
||||
|
||||
配置策略:
|
||||
|
||||
- **Deny**:
|
||||
- `log`: 标准库日志（无结构化，无法分级）。
|
||||
- `fmt.Print*`: 控制台打印（生产环境绝对禁止）。
|
||||
- `github.com/sirupsen/logrus`: 防止引入其他日志库。
|
||||
|
||||
### 2. 强制错误处理 (`errcheck`)
|
||||
|
||||
Zap 的 `Sync()` 方法可能会返回错误（特别是在 Linux 的 `/dev/stdout` 上），通常需要忽略，但写入文件的错误不能忽略。
|
||||
|
||||
Linter: errcheck / gosec
|
||||
|
||||
配置策略:
|
||||
|
||||
- 对 `logger.Sync()` 的错误处理进行豁免（Exclude），因为在某些 OS 下 stdout sync 必然报错，这是已知 issue。
|
||||
- 但对 `logger.Info` 等方法的 IO 错误，原则上 Zap 内部处理了，不需要业务层捕获。
|
||||
|
||||
### 3. 自定义规则 (`ruleguard` - 高级)
|
||||
|
||||
标准的 Linter 无法检测“键名必须是 snake_case”。如果需要极致的管控，我们可以引入 `ruleguard`。
|
||||
|
||||
AI 辅助检查逻辑:
|
||||
|
||||
由于配置 ruleguard 较复杂，我们约定在 AI 生成代码阶段 执行此逻辑：
|
||||
|
||||
- **Check 1**: 正则匹配所有 `zap.String("([a-z]+[A-Z][a-z]+)", …)` 模式，如果发现驼峰命名，立刻自我修正。
|
||||
- **Check 2**: 扫描代码中是否存在 `fmt.Print`，如有则报错。
|
||||
|
||||
---
|
||||
|
||||
## 三、 安全与脱敏规范 (Security & Masking)
|
||||
|
||||
这是日志系统的“红线”。
|
||||
|
||||
### 1. PII (个人敏感信息) 零容忍
|
||||
|
||||
- **黑名单字段**: `password`, `token`, `access_token`, `refresh_token`, `credit_card`, `id_card`.
|
||||
- **处理方式**:
|
||||
- **方案 A (拦截器)**: 在 `zapcore` 层加 Hook，但这会损耗性能。
|
||||
- **方案 B (显式脱敏)**: 要求 AI 在生成代码时，对于敏感字段，自动包裹脱敏函数。例如 `zap.String("mobile", mask.Mobile(u.Mobile))`。
|
||||
- **决策**: 采用 **方案 B**。依赖编码时的自觉和 AI 的辅助，性能最优。
|
||||
|
||||
### 2. 大字段截断
|
||||
|
||||
- **规则**: 禁止将 Base64 图片数据、巨大的 HTML 内容直接打入日志。
|
||||
- **限制**: 单个 Field 的 Value 长度建议限制在 2KB 以内。
|
||||
|
||||
---
|
||||
|
||||
## 四、 AI 辅助编码的“质量契约” (AI Quality Contract)
|
||||
|
||||
为了确保我（AI）生成的代码符合上述规范，请你（用户）在审查我的代码时，使用以下 **Checklist** 进行验证。这也是我对你的承诺：
|
||||
|
||||
1. **Imports 检查**: 确认没有引入 `log` 或 `fmt`。
|
||||
2. **Context 检查**: 确认 `log.WithContext(ctx)` 是日志调用的唯一起手式。
|
||||
3. **Keys 检查**: 确认所有 JSON Key 都是 `snake_case`。
|
||||
4. **Args 检查**: 确认使用的是 `zap.String/Int` 等强类型构造器，而非 `zap.Any`。
|
||||
5. **Config 检查**: 确认没有硬编码的路径（如 `/var/log`），必须来自 `options.go`。
|
||||
|
||||
---
|
||||
|
||||
## 五、 总结与下一步
|
||||
|
||||
我们确立了：
|
||||
|
||||
1. **命名**: 强制 snake_case。
|
||||
2. **类型**: 拒绝 `zap.Any`，拒绝 `fmt`。
|
||||
3. **上下文**: 强制 `WithContext`。
|
||||
4. **安全**: 显式脱敏。
|
||||
146
Go项目实战/03_基础设施/02_日志/07_日志模块工程化实施标准.md
Normal file
146
Go项目实战/03_基础设施/02_日志/07_日志模块工程化实施标准.md
Normal file
@@ -0,0 +1,146 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 日志模块工程化实施标准
|
||||
date created: 星期三, 十二月 10日 2025, 10:58:53 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:42:26 晚上
|
||||
---
|
||||
|
||||
# 日志模块工程化实施标准
|
||||
|
||||
---
|
||||
|
||||
## 一、 注释与文档规范 (Documentation Standards)
|
||||
|
||||
目标：“中文友好 (Chinese Friendly)” 且 “符合 GoDoc 标准”。
|
||||
|
||||
我们采用 混合语言策略：结构定义用英文（为了 IDE 兼容性），业务解释用中文（为了团队协作）。
|
||||
|
||||
### 1. 导出的包与函数 (Exported Symbols)
|
||||
|
||||
所有对外暴露的函数（首字母大写），必须编写文档注释。
|
||||
|
||||
- **格式要求**：
|
||||
- 第一行：`// FunctionName 简短的英文或中文摘要` (符合 Go Lint 检查)。
|
||||
- 空一行。
|
||||
- 详细说明：**必须使用中文**，解释函数的行为、副作用（Side Effects）和潜在风险。
|
||||
- 参数说明：如果有复杂参数，使用 `// - param: explanation` 格式。
|
||||
- **范例 (Style Guide)**:
|
||||
|
||||
> // WithContext returns a logger with the trace ID injected.
|
||||
>
|
||||
> //
|
||||
>
|
||||
> // [功能]: 从 context.Context 中提取 TraceID 并附加到 Logger 字段中。
|
||||
>
|
||||
> // [注意]: 这是一个轻量级操作，但如果 ctx 为 nil，将返回原始 Logger 的 fallback。
|
||||
>
|
||||
> // [场景]: 务必在 Controller 或 Service 的入口处优先调用。
|
||||
|
||||
### 2. 内部实现细节 (Internal Logic)
|
||||
|
||||
对于 `internal/pkg/log` 内部复杂的逻辑（如 `lumberjack` 的配置转换），必须在代码块上方添加中文注释。
|
||||
|
||||
- **原则**：解释 **“为什么这么做 (Why)”**，而不是“做了什么 (What)”。代码本身已经展示了做了什么。
|
||||
- **范例**:
|
||||
|
||||
> // [Why]: 这里不使用 zap.NewProduction 自带的 OutputPaths，
|
||||
>
|
||||
> // 因为我们需要同时输出到控制台 (为了 Docker 采集) 和文件 (为了本地容灾)，
|
||||
>
|
||||
> // 且文件输出需要通过 Lumberjack 进行轮转控制。
|
||||
|
||||
### 3. README 维护
|
||||
|
||||
在 `internal/pkg/log/README.md` 中维护一份**“速查手册”**。
|
||||
|
||||
- **必填内容**：
|
||||
- 如何在 `config.yaml` 中配置（给出默认值）。
|
||||
- 如何动态调整日志级别（如通过信号或 API）。
|
||||
- 常见错误码（Code）与日志关键字的对应关系。
|
||||
|
||||
---
|
||||
|
||||
## 二、 可拓展性设计 (Extensibility Design)
|
||||
|
||||
虽然我们拒绝“过度封装”，但必须为未来的变化预留接口（Hook Points）。
|
||||
|
||||
### 1. 配置扩展：Functional Options 模式
|
||||
|
||||
我们在 `Init` 函数中，不应列出所有参数，而应使用 `Option` 模式。
|
||||
|
||||
- **设计**: `func Init(opts …Option) error`
|
||||
- **预留能力**: 未来如果需要添加“发送日志到 Kafka”或“开启 Sentry 报警”，只需新增一个 `WithKafka(addr)` 的 Option，而无需修改 `Init` 的函数签名，保证了对旧代码的兼容性。
|
||||
|
||||
### 2. 核心扩展：Zap Hooks
|
||||
|
||||
Zap 原生支持 `Hooks`。我们的封装必须暴露这一能力。
|
||||
|
||||
- **场景**: 当日志级别为 `Error` 或 `Fatal` 时，可能需要同步触发飞书/钉钉报警。
|
||||
- **实现标准**: 在 `zap.go` 的构建逻辑中，检查配置是否定义了 Hooks。这允许我们在不侵入日志核心代码的情况下，挂载报警逻辑。
|
||||
|
||||
### 3. 字段扩展：Context Key Registry
|
||||
|
||||
随着业务发展，需要记录的元数据会增加（如 `TenantID`, `RequestID`, `SpanID`）。
|
||||
|
||||
- **标准**: 不要在 `context.go` 里写死 key 的提取逻辑。
|
||||
- **设计**: 定义一个 `type ContextExtractor func(ctx) []Field` 类型。默认提供 `TraceIDExtractor`。允许在初始化时注册新的 Extractor。这使得业务线可以自定义需要提取的 Context 字段。
|
||||
|
||||
---
|
||||
|
||||
## 三、 查漏补缺 (Gap Analysis)
|
||||
|
||||
在之前的讨论中，有几个隐蔽但致命的工程细节尚未覆盖，这里作为最后防线进行补充。
|
||||
|
||||
### 1. 关于 `Logger.Fatal` 的使用禁令
|
||||
|
||||
- **风险**: `zap.Logger.Fatal` 会在打印日志后调用 `os.Exit(1)`。
|
||||
- **工程标准**: **在 Web 服务（HTTP Server）中，严禁在业务逻辑层调用 `Fatal`。**
|
||||
- _原因_: 这会直接杀死整个进程，导致所有正在处理的请求中断（没有 Graceful Shutdown）。
|
||||
- _替代_: 遇到不可恢复错误，使用 `Error` 级别日志，并返回 `500` 错误给客户端，由上层中间件处理。
|
||||
- _例外_: 仅在 `main.go` 启动阶段（如连不上数据库、读不到配置）可以使用 `Fatal`。
|
||||
|
||||
### 2. 时间格式的一致性
|
||||
|
||||
- **问题**: Zap 默认的时间格式可能是浮点数（Unix Epoch）或非标准字符串。
|
||||
- **标准**: 生产环境统一配置为 **`ISO8601` (2025-12-10T22:00:00.000Z)**。
|
||||
- _理由_: 这种格式跨时区友好，且能被几乎所有日志分析工具（ELK, Splunk, CloudWatch）自动识别并建立时间索引。
|
||||
|
||||
### 3. 动态日志级别 (Hot Reload)
|
||||
|
||||
- **需求**: 线上出 Bug 时，需要临时把 Level 调成 Debug，查完再调回 Info，且不能重启服务。
|
||||
- **实现标准**: 利用 `zap.AtomicLevel`。
|
||||
- 我们需要暴露一个 HTTP 接口（如 `PUT /admin/log/level`）或监听配置文件的 `fsnotify` 事件。
|
||||
- 收到变更信号后，直接调用 `atomicLevel.SetLevel(zap.DebugLevel)`。这是线程安全的，无需重启实例。
|
||||
|
||||
### 4. 测试支持 (Testing Support)
|
||||
|
||||
- **问题**: 单元测试时，不仅不想看到日志刷屏，有时还需要断言“是否打印了某条错误日志”。
|
||||
- **标准**:
|
||||
- 提供 `pkg/log/test_helper.go`。
|
||||
- 封装 `zaptest/observer`。
|
||||
- 允许测试代码通过 `log.NewTestLogger()` 获取一个观察者对象，从而断言 `logs.FilterMessage("error").Len() == 1`。
|
||||
|
||||
### 5. 链路完整性保障
|
||||
|
||||
- **风险**: 开发者容易遗忘在 `go func()` 中传递 Context。
|
||||
- **标准**: 在 Code Review 时，重点检查所有 `go` 关键字后是否跟随了 Context 的传递或播种操作。
|
||||
|
||||
### 6. 框架初始化与 Panic 处理
|
||||
|
||||
- **风险**: `gin.Default()` 会自动注册只打印文本日志的 Recovery 中间件，破坏 JSON 格式。
|
||||
- **标准**:
|
||||
1. 必须使用 `gin.New()` 初始化 Engine。
|
||||
2. 必须手动注册我们自定义的 `middleware.Recovery` 和 `middleware.AccessLog`。
|
||||
3. 确保 Panic 日志中包含 TraceID（从 `c.Request.Context` 中尝试恢复）。
|
||||
|
||||
---
|
||||
|
||||
## 四、 总结与就绪确认
|
||||
|
||||
至此，我们已经完成了日志模块的**全生命周期设计**：
|
||||
|
||||
1. **架构**: 基础设施层，无业务依赖。
|
||||
2. **技术栈**: Zap + Lumberjack + Context Adapter。
|
||||
3. **模式**: 单例兜底 + 依赖注入，强类型约束。
|
||||
4. **规范**: Snake_case 键名，中文友好文档，严禁 Fatal。
|
||||
233
Go项目实战/03_基础设施/02_日志/AI 辅助基础设施构建 SOP (v1.0)-全局日志篇.md
Normal file
233
Go项目实战/03_基础设施/02_日志/AI 辅助基础设施构建 SOP (v1.0)-全局日志篇.md
Normal file
@@ -0,0 +1,233 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 🏗️ AI 辅助基础设施构建 SOP (v1.0) - [全局日志篇]
|
||||
date created: 星期三, 十二月 10日 2025, 11:50:40 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:52:08 晚上
|
||||
---
|
||||
|
||||
# 🏗️ AI 辅助基础设施构建 SOP (v1.0) - [全局日志篇]
|
||||
|
||||
**核心理念:**
|
||||
|
||||
1. **Configuration Driven (配置驱动):** 先定义配置结构与 Viper 映射，再实现逻辑。
|
||||
2. **Zero Allocation Constraint (零分配约束):** 在 Prompt 层面封杀 `zap.Any`，强制使用强类型字段。
|
||||
3. **Layered Delivery (分层交付):** 先交付 `pkg/log` (Level 0)，再交付 `middleware` (Level 1)。
|
||||
|
||||
---
|
||||
|
||||
## 📋 准备工作：上下文注入
|
||||
|
||||
在使用以下 Prompt 前，请确保 AI 已理解《全局日志模块详细设计说明书》的全部内容。
|
||||
|
||||
- `{语言/框架}`: Go 1.24+ / Uber Zap / Lumberjack v2
|
||||
- `{模块路径}`: `internal/pkg/log` (核心) & `internal/middleware` (集成)
|
||||
- `{关键约束}`: `pkg/log` **严禁依赖** `gin` 或 `viper` (仅接收 Config struct)。
|
||||
|
||||
---
|
||||
|
||||
## Phase 0: 依赖隔离与任务拆解 (The Dependency-Aware MECE)
|
||||
|
||||
**目的:** 防止 AI 在编写日志核心时引入业务层代码（如 Gin），导致循环依赖。
|
||||
|
||||
### 🤖 拆解者 Prompt (复制使用)
|
||||
|
||||
```Markdown
|
||||
你现在是我的 **System Architect (系统架构师)**。
|
||||
我们要实现 `Global Logging Infrastructure`。基于《详细设计说明书》，请执行 **“依赖隔离任务拆解”**。
|
||||
|
||||
**1. 架构红线 (Architecture Rules):**
|
||||
- **Level 0 (Core):** `internal/pkg/log`。只依赖 `zap`, `lumberjack`, standard `context`。**严禁依赖 `gin`**。
|
||||
- **Level 1 (Integration):** `internal/middleware`。依赖 `internal/pkg/log` 和 `gin`。
|
||||
|
||||
**2. 原子化切分:**
|
||||
请将工作拆解为两个独立的 Batch，每个 Batch 包含若干 Step。
|
||||
- **Batch A (Core)**: 必须按 `options.go` (配置) -> `zap.go` (构造) -> `context.go` (桥接) -> `log.go` (门面) 的顺序。
|
||||
- **Batch B (Middleware)**: 包含 `trace.go`, `access_log.go`, `recovery.go`。
|
||||
|
||||
**3. 输出格式:**
|
||||
请输出一个 **Markdown Checklist**。
|
||||
格式示例：
|
||||
- [ ] **Batch A - Step 1: {文件名}** - {核心职责} (关键设计点: …)
|
||||
…
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 0.5: API 签名锁定 (API Surface Lock)
|
||||
|
||||
**目的:** 在实现 `zap` 复杂构建逻辑前，先锁死对外暴露的“门面”方法，确保调用体验。
|
||||
|
||||
### 🤖 Prompt 0.5: 定义门面接口
|
||||
|
||||
```Markdown
|
||||
在实现具体逻辑前，让我们先锁定 `internal/pkg/log` 的 **Public API**。
|
||||
请只输出 `log.go` 和 `context.go` 中 **Exported Functions** 的签名（无需函数体）。
|
||||
|
||||
**关键要求:**
|
||||
1. **初始化:** `Init(opts …Option)` 设计为 Functional Options 模式还是直接传 Struct？(依据设计文档应为 Struct 传入，但保留 Option 扩展性)。
|
||||
2. **上下文注入:** `WithContext(ctx context.Context) *zap.Logger` 的签名确认。
|
||||
3. **静态代理:** `Info`, `Error` 等静态方法如何处理 `CallerSkip`？请在注释中说明。
|
||||
4. **后台任务:** 必须包含 `StartBackgroundTrace(ctx)` 的定义。
|
||||
|
||||
请输出带有完整 Go Doc 的接口定义代码块。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: 配置契约定义 (Configuration Contract)
|
||||
|
||||
**目的:** 只有确定了“怎么配”，才能决定“怎么写”。
|
||||
|
||||
### 🤖 Prompt 1: 定义配置结构与 Schema
|
||||
|
||||
```Markdown
|
||||
你现在是 **DevOps 专家**。
|
||||
请定义日志模块的配置结构 (`options.go`) 以及对应的 YAML 写法。
|
||||
|
||||
**任务:**
|
||||
1. **Go Struct:** 定义 `Options` 结构体。
|
||||
- 包含 `Level`, `Format` (json/console), `Filename`, `MaxSize`, `MaxBackups`, `MaxAge`, `Compress`。
|
||||
- Tag 必须适配 `mapstructure` (Viper 使用)。
|
||||
2. **Default Value:** 提供一个 `NewOptions()` 函数返回生产环境推荐的默认值 (100MB, 30个文件, JSON 格式)。
|
||||
3. **YAML Example:** 给出一个 `config.yaml` 的片段示例。
|
||||
|
||||
**约束:**
|
||||
- 字段类型必须明确（如 `MaxSize` 是 int 还是 string? 建议 int 单位 MB）。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: 体验验证 (DX Verification)
|
||||
|
||||
**目的:** 验证开发者在业务代码中打印日志是否顺手，防止过度封装导致 API 臃肿。
|
||||
|
||||
### 🤖 Prompt 2: 伪代码验证 (复制使用)
|
||||
|
||||
```Markdown
|
||||
配置和接口已锁定。请写一段 **Service 层** 的伪代码，展示如何使用该日志库。
|
||||
|
||||
**场景验证:**
|
||||
1. **标准调用:** 在 `UserRegister` 方法中，如何打日志并自动带上 TraceID？
|
||||
2. **强类型约束:** 展示使用 `zap.String`, `zap.Int` 的写法。**严禁出现 `zap.Any`**。
|
||||
3. **子 Context:** 在 `go func()` 中如何使用 `StartBackgroundTrace` 保证链路不断？
|
||||
4. **Error 处理:** 遇到 DB 错误时，如何记录 log 并返回 error？
|
||||
|
||||
请展示代码，并自我评价是否符合“低心智负担”原则。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: 核心防御式实现 (Core Defensive Implementation)
|
||||
|
||||
**核心机制:** 这是一个**循环步骤**。针对 `internal/pkg/log` 的每个文件执行。
|
||||
|
||||
### 🔄 循环动作 A: 生成代码
|
||||
|
||||
**[发送 Prompt]:**
|
||||
|
||||
```Markdown
|
||||
我们现在执行 **Batch A - Step {N}**。
|
||||
|
||||
**任务目标:**
|
||||
生成 `{文件名}` (例如 `zap.go`)。
|
||||
|
||||
**设计文档引用:**
|
||||
- 引用《设计说明书》中关于 `{章节名}` 的要求。
|
||||
|
||||
**代码质量硬性约束 (Hard Constraints):**
|
||||
1. **Snake Case:** 所有的 JSON Key (包括 TraceID) 必须手动指定为 snake_case (如 `zap.String("trace_id", v)`)。
|
||||
2. **No Zap Any:** 严禁在核心逻辑中使用 `zap.Any`。如果是 map/struct，必须手动拆解或实现 `zapcore.ObjectMarshaler`。
|
||||
3. **Safety:**
|
||||
- `writer.go`: Lumberjack 的 `Compress` 必须默认为 true。
|
||||
- `log.go`: `globalLogger` 必须有 `sync.Once` 保护，且默认初始化为 Console (避免 nil pointer)。
|
||||
4. **Caller Skip:** 确保静态方法 (log.Info) 和实例方法 (logger.Info) 的 Caller 层级正确，都能定位到业务代码行号。
|
||||
|
||||
请生成完整代码。
|
||||
```
|
||||
|
||||
### 🔄 循环动作 B: 质量检查锚点
|
||||
|
||||
**[发送 Prompt]:**
|
||||
|
||||
```Markdown
|
||||
代码已生成。请进行 **Self-Correction (自我修正)**：
|
||||
1. 检查是否有 `fmt.Print` 残留？
|
||||
2. 检查 `log.go` 中的静态方法是否使用了 `WithOptions(zap.AddCallerSkip(1))`？如果没用，业务层行号会报错。
|
||||
3. 检查是否引入了 `gin` 或其他业务包？(Level 0 严禁依赖)。
|
||||
|
||||
确认无误后，存入记忆，继续下一步。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: 中间件集成 (Middleware Integration)
|
||||
|
||||
**目的:** 只有当核心 Log 库稳定后，才实现 Gin 中间件。
|
||||
|
||||
### 🤖 Prompt 4: 实现链路追踪与访问日志
|
||||
|
||||
```Markdown
|
||||
现在进入 **Batch B**。我们需要实现 `internal/middleware/trace.go` 和 `access_log.go`。
|
||||
|
||||
**任务要求:**
|
||||
1. **Trace Middleware:**
|
||||
- 从 Request Header (`X-Trace-ID`) 读取，若无则生成 UUID。
|
||||
- **关键点:** 必须调用 `log.WithTraceID(ctx, id)` 将 ID 注入 Standard Context，再回写到 `c.Request`。
|
||||
2. **Access Log Middleware:**
|
||||
- 记录 Start Time, End Time, Latency。
|
||||
- 使用 `log.WithContext(c.Request.Context()).Info(…)` 打印。
|
||||
- **字段映射:** `method`, `path`, `ip`, `status`, `latency` (ms)。
|
||||
3. **Recovery Middleware:**
|
||||
- 捕获 Panic。
|
||||
- 打印包含 Stack Trace 的 JSON Error 日志 (非 Console 文本)。
|
||||
- 返回 500 响应。
|
||||
|
||||
请一次性生成这三个文件的核心逻辑。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: 极限防御测试 (Extreme Defensive Testing)
|
||||
|
||||
**目的:** 验证并发安全、文件轮转和敏感数据脱敏。
|
||||
|
||||
### 🤖 Prompt 5: 生成红队测试用例
|
||||
|
||||
```Markdown
|
||||
核心代码已就绪。请为 `pkg/log` 编写单元测试 `log_test.go`。
|
||||
|
||||
**请覆盖以下 3 个高危场景 (Test Cases):**
|
||||
|
||||
1. **并发竞争 (Race Detection):**
|
||||
- 启动 100 个 Goroutine，同时调用 `log.WithContext(ctx).Info(…)`。
|
||||
- 断言：`go test -race` 不报错，且 TraceID 不串号。
|
||||
|
||||
2. **Caller 准确性验证:**
|
||||
- 编写一个测试辅助函数，解析输出的 JSON，断言 `caller` 字段指向的是测试代码行号，而不是 `log.go` 内部。
|
||||
|
||||
3. **敏感数据脱敏 (Mock):**
|
||||
- 模拟打印 `zap.String("password", "123456")`。
|
||||
- (注意：如果我们在 Zap Core 层没做拦截，这里需要验证是否通过 AI 辅助代码生成时的规范来避免。此处请测试：如果定义了 Masking Hook，密码是否被替换为 `******`)。
|
||||
- *注：根据设计文档，我们采用“编码规范+AI辅助”策略，故此处测试应侧重于“TraceID 是否在 Log 中正确出现”。*
|
||||
|
||||
请输出 Test 代码。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: SRE 验收 (SRE Review)
|
||||
|
||||
### 🤖 Prompt 6: 运维视角审查
|
||||
|
||||
```Markdown
|
||||
切换角色为 **SRE**。请审查生成的日志模块。
|
||||
|
||||
**检查清单:**
|
||||
1. **磁盘爆炸风险:** `Lumberjack` 配置是否真的生效了？(检查 WriteSyncer 的封装)。
|
||||
2. **性能损耗:** `WithContext` 是否每次都创建了过多的 Zap 对象？(确认是否只是 Shallow Copy)。
|
||||
3. **索引友好度:** 时间戳是否为 ISO8601 (`2025-12-10T…`)？如果是 Epoch float，ELK 处理会麻烦。
|
||||
4. **容灾:** 如果 `logs/` 目录不可写（权限问题），程序会 Panic 还是降级输出到 Stdout？
|
||||
|
||||
请给出 1-2 个具体的 `TODO` 优化项。
|
||||
```
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 📋 Global Logging Infrastructure - Task Checklist
|
||||
date created: 星期三, 十二月 10日 2025, 11:55:42 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:56:24 晚上
|
||||
---
|
||||
收到。作为系统架构师，我已根据《全局日志模块详细设计说明书》及 SOP 要求，完成了**依赖隔离任务拆解 (Dependency-Aware MECE Breakdown)**。
|
||||
|
||||
此拆解方案严格遵循 **Level 0 (Core)** 与 **Level 1 (Integration)** 的物理隔离，确保核心日志包零依赖于业务框架。
|
||||
|
||||
---
|
||||
|
||||
# 📋 Global Logging Infrastructure - Task Checklist
|
||||
|
||||
## Phase 1: Batch A - Core Implementation (Level 0)
|
||||
|
||||
> 目录: internal/pkg/log
|
||||
>
|
||||
> 约束: 仅依赖 zap, lumberjack, context。严禁 import gin, viper。
|
||||
|
||||
- [ ] **Batch A - Step 1: 配置与标准定义 (`options.go`, `standard.go`)**
|
||||
|
||||
- **核心职责:** 定义日志配置结构体 (Config Struct) 及全局统一的键名常量 (Standard Keys)。
|
||||
- **关键设计:**
|
||||
- `Options` 结构体需包含 `mapstructure` tag 以适配外部 Viper 解析。
|
||||
- 预定义 `trace_id`, `user_id` 等常量为 `snake_case`，杜绝魔法字符串。
|
||||
- 包含 `DefaultOptions()` 返回生产环境推荐配置 (100MB, Compress=true)。
|
||||
|
||||
- [ ] **Batch A - Step 2: 核心构建与 IO (`writer.go`, `zap.go`)**
|
||||
|
||||
- **核心职责:** 封装 Lumberjack 文件轮转逻辑，构建 `zap.Core` 与 `zap.Logger` 实例。
|
||||
- **关键设计:**
|
||||
- **IO 分离:** `writer.go` 实现 `zapcore.WriteSyncer`，强制开启 `Compress: true`。
|
||||
- **环境隔离:** `zap.go` 根据配置决定使用 `JSON Encoder` (Prod) 或 `Console Encoder` (Dev)。
|
||||
- **双写机制:** 实现 Tee 模式，同时输出到文件和控制台 (Stdout)。
|
||||
|
||||
- [ ] **Batch A - Step 3: 上下文桥接 (`context.go`)**
|
||||
|
||||
- **核心职责:** 实现标准 `context.Context` 到 `zap.Field` 的转换逻辑。
|
||||
- **关键设计:**
|
||||
- **TraceID 注入:** 实现 `WithContext(ctx)`，从 Context 提取 TraceID 并返回带有 `trace_id` 字段的 `*zap.Logger`。
|
||||
- **后台播种:** 实现 `StartBackgroundTrace(ctx)`，为 Cron/Goroutine 任务生成根 TraceID。
|
||||
- **零侵入:** 仅依赖标准库 Context，不依赖 Gin Context。
|
||||
|
||||
- [ ] **Batch A - Step 4: 全局门面 (`log.go`)**
|
||||
|
||||
- **核心职责:** 管理全局单例 (Singleton)，提供静态代理方法 (Static Proxy)。
|
||||
- **关键设计:**
|
||||
- **懒汉兜底:** `globalLogger` 默认初始化为 Console Logger (Nop)，防止未调用 `Init` 时 Panic。
|
||||
- **Caller 修正:** 静态方法 (`log.Info`) 必须使用 `AddCallerSkip(1)`，确保日志行号指向业务代码而非 `log.go`。
|
||||
- **并发安全:** `Init()` 必须使用 `sync.Once` 或互斥锁保护。
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Batch B - Middleware Integration (Level 1)
|
||||
|
||||
> 目录: internal/middleware
|
||||
>
|
||||
> 约束: 依赖 internal/pkg/log, gin, pkg/app。
|
||||
|
||||
- [ ] **Batch B - Step 1: 链路追踪中间件 (`trace.go`)**
|
||||
|
||||
- **核心职责:** 请求入口处的 TraceID 生成与注入。
|
||||
- **关键设计:**
|
||||
- 优先读取 Header `X-Trace-ID`，无则生成 UUID。
|
||||
- **关键动作:** 调用 `log.WithTraceID(ctx, id)` 将 ID 注入 **Standard Context**，再回写到 `c.Request`，打通后续所有层的日志链路。
|
||||
|
||||
- [ ] **Batch B - Step 2: 访问日志中间件 (`access_log.go`)**
|
||||
|
||||
- **核心职责:** 记录 HTTP 请求的黄金指标 (Golden Signals)。
|
||||
- **关键设计:**
|
||||
- 必须使用 `log.WithContext(c.Request.Context())` 打印，确保包含 TraceID。
|
||||
- 记录字段：`method`, `path`, `status`, `latency` (ms), `client_ip`。
|
||||
|
||||
- [ ] **Batch B - Step 3: 灾难恢复中间件 (`recovery.go`)**
|
||||
|
||||
- **核心职责:** 替换 Gin 默认 Recovery，提供结构化 Panic 日志。
|
||||
- **关键设计:**
|
||||
- 捕获 `panic` -> 获取 Stack Trace -> 构造 JSON Error 日志 (包含 `stack` 字段)。
|
||||
- 联动 `pkg/app` 返回标准 JSON 500 响应，通过 `pkg/log` 记录系统级错误。
|
||||
|
||||
---
|
||||
|
||||
# 🏁 Next Action
|
||||
|
||||
建议按照 Checklist 顺序，从 **Batch A - Step 1** 开始执行。是否现在开始 Phase 0.5 (API 签名锁定) 或直接生成 Step 1 代码？
|
||||
864
Go项目实战/03_基础设施/全局日志模块 (Global Logging Infrastructure) 详细设计说明书.md
Normal file
864
Go项目实战/03_基础设施/全局日志模块 (Global Logging Infrastructure) 详细设计说明书.md
Normal file
@@ -0,0 +1,864 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- Project Context Aggregation
|
||||
date created: 星期三, 十二月 10日 2025, 11:02:10 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:50:40 晚上
|
||||
---
|
||||
|
||||
# Project Context Aggregation
|
||||
|
||||
> Source Items: 1
|
||||
|
||||
==== 02_ 日志\01_ 设计目标.md ====
|
||||
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 核心设计目标 (Core Design Goals)
|
||||
date created: 星期三, 十二月 10日 2025, 10:27:39 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 10:28:15 晚上
|
||||
---
|
||||
|
||||
# 1. 核心设计目标 (Core Design Goals)
|
||||
|
||||
## 目标一：全链路上下文关联 (Contextual Traceability)
|
||||
|
||||
这是最核心的差异点。传统的 `log.Println("Database error")` 在并发环境下毫无价值，因为你不知道这条错误属于哪个请求。
|
||||
|
||||
- **设计要求**:
|
||||
- **自动注入 TraceID**: 必须能够从 `context.Context` 中提取 `TraceID`（目前 `internal/pkg/app` 已经生成了 TraceID），并自动将其附加到每一条日志中。
|
||||
- **请求元数据绑定**: 除了 TraceID，还应支持自动绑定 `UserID`、`IP`、`Method`、`Path` 等元数据，形成请求的完整快照。
|
||||
- **跨组件穿透**: 日志对象必须能够在 Layer 之间传递（例如 Controller -> Service -> Repository），且保持上下文不丢失。
|
||||
|
||||
## 目标二：严格的结构化契约 (Strict Structured Schema)
|
||||
|
||||
日志是写给机器看的，不是写给通过 SSH 连上服务器的人看的。
|
||||
|
||||
- **设计要求**:
|
||||
- **JSON First**: 生产环境强制使用 JSON 格式。
|
||||
- **Schema 统一**: 字段命名必须统一。例如，不要混用 `uid`, `user_id`, `userId`，必须在设计阶段锁定为 snake_case (如 `user_id`)。
|
||||
- **类型安全**: 时间戳必须统一格式（推荐 ISO8601 或 Unix Nano），数字字段不能变成字符串（便于聚合计算）。
|
||||
|
||||
## 目标三：高性能与零侵入 (High Performance & Zero Allocation)
|
||||
|
||||
日志通常是系统中 IO 最密集的组件之一。
|
||||
|
||||
- **设计要求**:
|
||||
- **低 GC 压力**: 利用 Zap 的核心优势，避免大量的 `interface{}` 反射和字符串拼接，使用强类型的 Field（如 `zap.Int`, `zap.String`）。
|
||||
- **异步 IO (可选)**: 考虑是否引入 Buffer 机制（牺牲极端崩溃下的日志完整性换取吞吐量）。
|
||||
- **Level 级联过滤**: 在 Debug 级别关闭时，Debug 级别的日志构造逻辑（如复杂的对象序列化）不应被执行。
|
||||
|
||||
## 目标四：安全与合规 (Security & Compliance)
|
||||
|
||||
这往往是被忽视的一点，也是导致安全事故的频发区。
|
||||
|
||||
- **设计要求**:
|
||||
- **敏感数据脱敏**: 必须具备“黑名单”机制。任何包含 `password`, `token`, `mobile`, `credit_card` 的字段在输出前必须被自动掩盖（Masking）。
|
||||
- **安全截断**: 防止打印过大的 Body（如 Base64 图片上传）导致磁盘爆满或日志系统瘫痪，限制单条日志最大长度。
|
||||
|
||||
---
|
||||
|
||||
# 2. 场景化行为对比 (Dev Vs Prod)
|
||||
|
||||
为了兼顾开发体验和生产运维标准，我们需要在设计中明确区分两种环境的行为。
|
||||
|
||||
|**维度**|**开发环境 (Development)**|**生产环境 (Production)**|**设计意图**|
|
||||
|---|---|---|---|
|
||||
|**编码格式**|Console (彩色，人类易读)|JSON (机器易读)|开发追求直观；生产追求 ELK 解析效率。|
|
||||
|**输出目标**|Stdout (控制台)|File + Stdout (双写)|开发侧容器即焚；生产侧需持久化 + 容器采集。|
|
||||
|**日志级别**|Debug|Info / Warn|生产环境过滤掉大量 Debug 噪音，节省存储成本。|
|
||||
|**堆栈追踪**|Error 级别即打印|Panic 或 Fatal 才打印|减少生产环境日志体积，除非发生严重故障。|
|
||||
|**调用行号**|显示 (Caller)|显示 (Caller)|快速定位代码位置。|
|
||||
|
||||
---
|
||||
|
||||
# 3. 架构定位与边界 (Architecture Boundary)
|
||||
|
||||
我们需要明确日志模块在架构中的位置：
|
||||
|
||||
- **位置**: 属于 `Infrastructure Layer` (Level 0/1)。
|
||||
- **依赖关系**:
|
||||
- **被谁依赖**: 所有层（Handler, Service, Repository）都依赖 Log。
|
||||
- **依赖谁**: 仅依赖标准库和第三方 Log Driver (Zap)，**不应依赖业务逻辑**。
|
||||
- **与其他模块的关系**:
|
||||
- **vs `ecode`**: `ecode` 定义错误的**类型**（Code），Log 记录错误的**现场**（Stack/Trace）。
|
||||
- **vs `app.Response`**: Response 负责**对用户说话**（经过清洗的、友好的信息），Log 负责**对开发者说话**（原始的、包含脏数据的真相）。
|
||||
|
||||
---
|
||||
|
||||
# 4. 深度反思与自我反驳 (Critical Thinking & Risk Analysis)
|
||||
|
||||
在敲定设计目标前，必须审视潜在的矛盾和风险：
|
||||
|
||||
**反驳点 1：全链路上下文（TraceID）的传递成本**
|
||||
|
||||
- **挑战**: 要想让 Repository 层的日志也打出 TraceID，必须修改所有方法的签名为 `func (ctx context.Context, …)`。这对现有代码（如果是非 Context 风格）是巨大的重构。
|
||||
- **回应**: 我们的 `Repository` 接口目前设计中已经包含了 `context.Context`。这是一个必须遵守的“硬约束”。如果缺少 Context，日志将断层。
|
||||
- **结论**: 必须在规范中强调：**所有层级的方法首个参数必须是 Context**。
|
||||
|
||||
**反驳点 2：脱敏机制的性能损耗**
|
||||
|
||||
- **挑战**: 如果每一条日志都要遍历字段去匹配“黑名单”进行正则替换，CPU 开销极大。
|
||||
- **回应**: 不能使用正则扫描全文。
|
||||
- **修正方案**: 利用 Zap 的 `Hook` 或 `Core` 包装，仅针对特定 Key（如 `password`）进行值替换，或者要求开发者在打印敏感结构体时显式调用 `.Reduct()` 方法，而非隐式全局扫描。隐式扫描在 Golang 中通常是性能杀手。
|
||||
|
||||
**反驳点 3：异步写入的丢数据风险**
|
||||
|
||||
- **挑战**: 为了性能使用 `Buffered Write`，如果进程被 `kill -9` 或 Panic 崩溃，缓冲区日志会丢失，而崩溃前的日志往往最重要。
|
||||
- **回应**: 对于交易类系统，**可靠性 > 吞吐量**。
|
||||
- **结论**: 默认采用 **同步写入 (Sync Write)**。Zap 本身性能已经足够强（纳秒级），除非达到数万 QPS，否则不需要引入 Buffer。对于 Panic，必须使用 `defer logger.Sync()` 确保刷盘。
|
||||
|
||||
---
|
||||
|
||||
# 5. 待确认问题 (Open Questions)
|
||||
|
||||
在进入下一步（编写详细规格说明书）之前，我需要确认你对以下几点的偏好：
|
||||
|
||||
1. **全局单例 vs 纯依赖注入**:
|
||||
|
||||
- _选项 A_: 提供 `log.Info()` 全局静态方法（方便，但有副作用）。
|
||||
- _选项 B_: 强制必须通过 `l.Info()` 实例方法调用（架构更洁癖，但调用繁琐）。
|
||||
- _推荐_: **选项 A + B**。提供全局方法作为快捷方式（底层代理到单例），同时支持 DI 注入。你倾向于哪种？
|
||||
|
||||
2. **日志轮转 (Rotation) 策略**:
|
||||
|
||||
- 你是倾向于按 **大小** 切割（如 100MB 一个文件），还是按 **时间** 切割（每天一个文件）？
|
||||
- _通常建议_: 按大小切割（防止单文件过大无法打开），配合最大文件保留数。
|
||||
```
|
||||
|
||||
==== 02_ 日志\02_ 技术栈基线.md ====
|
||||
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 核心引擎 (The Engine)：Uber Zap
|
||||
date created: 星期三, 十二月 10日 2025, 10:28:15 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 10:29:20 晚上
|
||||
---
|
||||
|
||||
# 1. 核心引擎 (The Engine)：Uber Zap
|
||||
|
||||
行业共识 (Consensus):
|
||||
|
||||
在 Go 语言的高性能后端领域，go.uber.org/zap 是目前无可争议的事实标准（De Facto Standard）。
|
||||
|
||||
我的推荐:
|
||||
|
||||
坚定地使用 Zap，不要犹豫。
|
||||
|
||||
**老兵的经验谈 (Why & How):**
|
||||
|
||||
- **为何不是 Logrus?** Logrus 胜在 API 极其友好（兼容标准库），但它底层大量使用反射（Reflection）和锁，在高并发场景下是严重的性能瓶颈（GC 压力大）。
|
||||
- **为何不是 Slog (Go 1.21+)?** Slog 是 Go 官方推出的结构化日志接口。虽然它是未来，但目前的生态和性能优化（尤其是在 JSON 序列化的极致性能上）尚未完全超越 Zap。且 Zap 可以很方便地作为 Slog 的 Backend。但在本项目中，为了追求极致性能和成熟度，直接使用 Zap 原生 API 是最高效的。
|
||||
- **关键决策点**:
|
||||
- **Field 强类型**: 我们必须强制团队使用 `zap.String("key", "val")` 而非 `zap.Any("key", val)`。`Any` 会导致反射，破坏 Zap 的零内存分配（Zero Allocation）优势。这是代码审查（Code Review）的红线。
|
||||
- **Logger vs SugaredLogger**:
|
||||
- **核心业务链路 (Hot Path)**: 使用 `zap.Logger`（极致性能，但语法繁琐）。
|
||||
- **初始化/非热点代码**: 使用 `zap.SugaredLogger`（语法类似 `printf`，性能稍弱但开发快）。
|
||||
- **基线**: 我们的封装层默认暴露 `Logger` 能力，保留高性能入口。
|
||||
|
||||
# 2. 轮转插件 (Rotation): Lumberjack V2
|
||||
|
||||
行业共识 (Consensus):
|
||||
|
||||
日志切割看似简单，实则坑多（并发写冲突、文件重命名原子性、不同操作系统的文件锁差异）。
|
||||
|
||||
我的推荐:
|
||||
|
||||
使用 gopkg.in/natefinch/lumberjack.v2。
|
||||
|
||||
**老兵的经验谈:**
|
||||
|
||||
- **不要造轮子**: 我见过无数团队尝试自己写 `file.Write` 然后计数切割，最后都在“多进程并发写同一个日志文件”或者“日志压缩时导致 IO 飙升”这些问题上翻车。
|
||||
- **配置陷阱**:
|
||||
- `MaxSize`: 建议 **100MB**。太小导致文件碎片化，太大导致像 grep/vim 这种工具打开困难。
|
||||
- `MaxBackups`: 建议保留 **30-50 个**。
|
||||
- `MaxAge`: 建议 **7-14 天**。
|
||||
- **Compress**: 建议 **开启 (True)**。历史日志压缩存储（gzip）能节省 90% 以上的磁盘空间，这对于云盘成本控制非常重要。
|
||||
|
||||
# 3. 上下文管理 (Context Awareness): 自研封装层
|
||||
|
||||
这是我们作为“架构师”必须介入的地方。原生 Zap 不懂业务上下文，我们需要一个胶水层。
|
||||
|
||||
技术难点:
|
||||
|
||||
如何优雅地把 TraceID 塞进每一行日志？
|
||||
|
||||
设计路线:
|
||||
|
||||
我们需要定义一个轻量级的 Wrapper 或者 Helper 函数。
|
||||
|
||||
- **不要**：重写 `zap.Logger` 结构体的所有方法（那样维护成本太高）。
|
||||
- **要**：提供一个入口函数，例如 `log.WithContext(ctx)`。
|
||||
- **原理**：这个函数会从 `ctx` 取出 `TraceID`，然后调用 `zap.With(zap.String("trace_id", id))`，返回一个携带了该字段的子 Logger 实例。这是一次极低成本的指针操作。
|
||||
|
||||
# 4. 抽象策略与混合模式 (Hybrid Pattern)
|
||||
|
||||
结合你选择的 **Option A+B**，我们的技术实现路径如下：
|
||||
|
||||
1. **全局变量 (The Global)**:
|
||||
|
||||
- 在 `internal/pkg/log` 包内部维护一个私有的 `var globalLogger *zap.Logger`。
|
||||
- 利用 `sync.Once` 确保其并发安全的初始化。
|
||||
- **兜底策略**: 在 `init()` 函数中先给它一个默认的 `Console Logger`。这样即使开发者忘记调用 `InitLogger`，程序启动时的日志也不会 panic，只会打印到控制台。
|
||||
|
||||
2. **依赖注入 (The DI)**:
|
||||
|
||||
- 在 `internal/pkg/log` 暴露一个 `Provider` 函数，供 Wire 使用。
|
||||
- 这个 Provider 返回的必须是**同一个**底层 Zap 实例的引用（或者其派生），确保配置（如 Level、Output Path）是一致的。
|
||||
|
||||
---
|
||||
|
||||
# 总结：最终的技术栈清单
|
||||
|
||||
|**组件**|**选型**|**理由**|
|
||||
|---|---|---|
|
||||
|**Logger Core**|`go.uber.org/zap` (v1.27+)|高性能、类型安全、零内存分配。|
|
||||
|**Rotation**|`gopkg.in/natefinch/lumberjack.v2`|成熟稳定，处理并发写文件不仅是事实标准，更是避坑指南。|
|
||||
|**Config**|`spf13/viper` (已引入)|利用现有的 Viper 读取 yaml 配置，实现动态等级调整。|
|
||||
|**Trace Inject**|`Custom Wrapper` (Standard Lib)|基于 `context` 的轻量封装，连接 `gin.Context` 与 `zap.Fields`。|
|
||||
|
||||
老师的最后叮嘱 (The Moral of the story):
|
||||
|
||||
我们现在的设计，本质上是在 Zap 的高性能 和 业务开发的便利性 之间走钢丝。
|
||||
|
||||
最大的风险在于：封装层写得太重。
|
||||
|
||||
如果我们在 log.Info 里面加了太多的锁、反射或者字符串拼接，那么引入 Zap 的意义就没了。所以，接下来的详细设计文档中，我们要时刻警惕“过度封装”。
|
||||
|
||||
如果这个技术栈基线你没有异议，我们就以此为基础，开始生成《全局日志模块详细设计规格说明书》。
|
||||
```
|
||||
|
||||
==== 02_ 日志\03_ 核心设计模式.md ====
|
||||
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 核心模式：装饰器模式的变体 (Context-Decorator Pattern)
|
||||
date created: 星期三, 十二月 10日 2025, 10:37:54 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 10:38:26 晚上
|
||||
---
|
||||
|
||||
# 1. 核心模式：装饰器模式的变体 (Context-Decorator Pattern)
|
||||
|
||||
这是我们处理 `TraceID` 和上下文的核心手段。
|
||||
|
||||
- 传统误区 (Over-Abstraction)：
|
||||
|
||||
定义一个庞大的 MyLogger 结构体，把 zap.Logger 藏在里面，然后重写 Info, Error 等所有方法。
|
||||
|
||||
- _后果_：维护成本极高，每次 Zap 更新或增加新特性（如 `Panic` 或 `DPanic`），你都得跟着改代码。且容易在转发参数时产生逃逸分析（Escape Analysis）导致的内存分配。
|
||||
- 我们的决策 (The Thin Wrapper)：
|
||||
|
||||
只封装“获取 Logger”的动作，不封装“Logger 本身”。
|
||||
|
||||
我们将定义一个函数 log.WithContext(ctx context.Context) *zap.Logger。
|
||||
|
||||
- _行为_：这个函数极其轻量。它从 `ctx` 中取出 `TraceID`，调用 `zap.With()` 生成一个新的 Zap 实例并返回。
|
||||
- _优势_：业务代码拿到的依然是原生的 `*zap.Logger`。这意味着开发者可以直接使用 Zap 强大的 `zap.String`, `zap.Int` 等强类型字段构建方法，享受极致性能，没有任何中间层损耗。
|
||||
|
||||
# 2. 接口策略：拒绝通用接口 (Concrete Type Dependency)
|
||||
|
||||
这是 Go 语言工程实践中关于日志的一个特殊共识，也是反直觉的地方。
|
||||
|
||||
- 传统误区 (The Java/Interface Way)：
|
||||
|
||||
定义一个 type ILogger interface { Info(msg string, args …interface{}) }。
|
||||
|
||||
- _后果_：`args …interface{}` 会导致大量的反射（Reflection）和装箱（Boxing），这直接抹杀了 Zap 存在的意义。Zap 的核心设计哲学就是通过 `zap.Field` 避免使用 `interface{}`。
|
||||
- 我们的决策 (Concrete Type)：
|
||||
|
||||
直接依赖 *zap.Logger 具体类型。
|
||||
|
||||
- _原则_：在 Handler、Service、Repository 层，注入的类型就是 `*zap.Logger`。
|
||||
- _测试怎么办_：不要 Mock 日志接口。在单元测试中，直接传入 `zap.NewNop()`（什么都不做）或者 `zap.NewExample()`（输出到测试控制台）。这比 Mock 一个接口要简单且真实得多。
|
||||
|
||||
# 3. 访问模式：混合单例与依赖注入 (The Hybrid Accessor)
|
||||
|
||||
结合之前讨论的 Option A+B，我们通过设计模式来解决“初始化顺序”和“热加载”的问题。
|
||||
|
||||
- 设计挑战：
|
||||
|
||||
如果 main.go 还没来得及读配置初始化 Logger，其他 init() 函数里就调用了日志，程序会 Panic。
|
||||
|
||||
- **我们的决策 (Thread-Safe Proxy)**：
|
||||
- **原子替换 (Atomic Swap)**：全局变量 `globalLogger` 不会直接暴露给外部修改。我们将使用 `unsafe.Pointer` 或 `atomic.Value` (配合 Zap 的 `ReplaceGlobals`) 来保证在运行时重新加载配置（如动态修改 Log Level）时，不会发生并发读写冲突。
|
||||
- **懒汉式兜底 (Lazy Fallback)**：在 `internal/pkg/log` 的 `init()` 中，我们会默认初始化一个 `Console Logger`。这样即使 `main` 函数一行代码都没跑，只要引用了包，日志功能就是可用的（虽然配置是默认的）。这极大提升了开发体验（DX）。
|
||||
|
||||
# 4. 字段构建模式：结构化优先 (Field-First API)
|
||||
|
||||
这关乎团队的编码规范，属于 API 设计模式。
|
||||
|
||||
- 传统误区 (Printf Style)：
|
||||
|
||||
使用 SugaredLogger 的 Infof("User %s login failed, error: %v", user, err)。
|
||||
|
||||
- _后果_：日志分析系统（ELK）只能拿到一串文本，无法对 `user` 进行聚合统计。
|
||||
- 我们的决策 (Structured Style)：
|
||||
|
||||
默认只暴露 Logger（强类型），在必要时才暴露 SugaredLogger。
|
||||
|
||||
- _强制规范_：代码中必须写成 `log.Info("user login failed", zap.String("user", user), zap.Error(err))`。
|
||||
- _设计意图_：通过 API 的设计，“强迫”开发者思考每一个字段的语义。这虽然写起来繁琐一点，但对于后期的运维和排查是无价的。
|
||||
|
||||
---
|
||||
|
||||
# 总结：设计规格书的基调
|
||||
|
||||
基于以上讨论，在接下来的规格说明书中，我们将确立以下基调：
|
||||
|
||||
1. **不造轮子**：核心逻辑全权委托给 `zap` 和 `lumberjack`。
|
||||
2. **薄封装**：`pkg/log` 代码行数应控制在 200 行以内，只做配置解析和 Context 桥接。
|
||||
3. **强类型**：严禁在核心路径使用 `interface{}`。
|
||||
4. **显式传递**：通过 `WithContext` 显式传递上下文，而不是依赖某些黑魔法（如 Goroutine Local Storage）。
|
||||
```
|
||||
|
||||
==== 02_ 日志\04_ 架构逻辑.md ====
|
||||
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1. 代码组织方式 (Code Organization)
|
||||
date created: 星期三, 十二月 10日 2025, 10:42:21 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:38:44 晚上
|
||||
---
|
||||
|
||||
# 1. 代码组织方式 (Code Organization)
|
||||
|
||||
我们将遵循 **“高内聚、低耦合”** 的原则，将日志模块放置在 `internal/pkg/log` 下。这里是所有日志逻辑的物理家园。
|
||||
|
||||
建议的文件结构如下（逻辑分层）：
|
||||
|
||||
- **`log.go` (Facade/Entry Point)**:
|
||||
- 这是对外暴露的统一入口。包含全局单例的定义、初始化函数 (`Init`)、以及最常用的静态方法代理（如 `Info`, `Error`, `WithContext`）。
|
||||
- **设计意图**: 让其他模块只 import 这一个包就能完成 90% 的工作。
|
||||
- **`options.go` (Configuration)**:
|
||||
- 定义配置结构体（Level, Filename, MaxSize, MaxAge 等）。
|
||||
- **设计意图**: 将配置解析逻辑与日志初始化逻辑分离，方便单元测试。
|
||||
- **`zap.go` (Core Implementation)**:
|
||||
- 负责 `zap.Logger` 的具体构建。包含 Encoder 配置（JSON vs Console）、Writer 配置（Lumberjack 集成）和 Level 动态调整逻辑。
|
||||
- 这是“脏活累活”集中的地方，屏蔽 Zap 的复杂构建细节。
|
||||
- **`context.go` (The Bridge)**:
|
||||
- **核心组件**。实现 `TraceID` 的提取逻辑。
|
||||
- 定义如何从 `context.Context` 中挖掘元数据，并将其转化为 `zap.Field`。
|
||||
|
||||
---
|
||||
|
||||
# 2. 调用方式与依赖注入 (Invocation & DI)
|
||||
|
||||
这里有一个经典的架构冲突：**Singleton（单例） vs Dependency Injection（依赖注入）**。我们的策略是 **“依赖注入为主，单例为辅”**，但在具体使用上有一个极其重要的**反直觉设计**。
|
||||
|
||||
## A. 为什么 Service 层不应保存 Request Logger？
|
||||
|
||||
你可能会想在 Service 初始化时注入一个带 Context 的 Logger。
|
||||
|
||||
- **错误做法**: `type UserService struct { logger *zap.Logger }`，然后在请求进来时试图把 request-scoped 的 logger 塞进去。
|
||||
- **架构事实**: 在 Wire 依赖注入中，`Service`、`Repository` 通常是 **单例 (Singleton)** 的（即整个应用生命周期只有一个实例）。
|
||||
- **结论**: 你**不能**把属于某一次 HTTP 请求的 `TraceID` 注入到单例的 Struct 成员变量中。
|
||||
|
||||
## B. 正确的调用范式 (The Best Practice)
|
||||
|
||||
Logger 作为**工具能力**被注入，Context 作为**请求参数**被传递。
|
||||
|
||||
1. **依赖注入 (Setup Phase)**:
|
||||
|
||||
- 在 `NewUserUsecase` 时，注入基础的 `*zap.Logger`（不带 TraceID）。
|
||||
- 这个 Logger 配置好了输出路径、Level 等全局属性。
|
||||
|
||||
2. **方法调用 (Runtime Phase)**:
|
||||
|
||||
- 在具体的方法（如 `Register`）中，使用 `log.WithContext(ctx)` 来“临时”生成一个带有 TraceID 的 Logger 实例。
|
||||
|
||||
**示例逻辑流**:
|
||||
|
||||
- **Struct 定义**: `struct { baseLogger *zap.Logger }`
|
||||
- **方法内部**: `l := log.WithContext(ctx, u.baseLogger)` -> `l.Info("user registered")`
|
||||
- **说明**: 这里的 `WithContext` 是一个纯内存操作（浅拷贝），开销极小，可以放心高频调用。
|
||||
|
||||
## C. 高性能场景：作用域复用 (Scoped Logger)
|
||||
|
||||
虽然 `log.WithContext` 是浅拷贝，但在循环或长链路中频繁调用仍会产生大量临时对象，增加 GC 压力。
|
||||
|
||||
- **反模式 (Anti-Pattern)**: 在 `for` 循环内部调用 `log.WithContext(ctx)`。
|
||||
- **最佳实践 (Best Practice)**: **作用域提升**。在函数或循环入口处调用一次 `WithContext`，生成局部变量 `l` (Logger)，随后全程复用该变量。
|
||||
|
||||
---
|
||||
|
||||
# 3. 数据流与 TraceID 传递 (Data Flow)
|
||||
|
||||
这是实现“全链路可观测性”的生命线。数据流必须打通以下四个关卡：
|
||||
|
||||
## 关卡 1：入口 (Entry - Middleware)
|
||||
|
||||
- **位置**: `internal/middleware/trace.go` (需新建) 或集成在 `response` 包中。
|
||||
- **行为**: 当 HTTP 请求到达，生成一个 UUID。
|
||||
- **动作**: 使用 `c.Set("X-Trace-ID", uuid)` 将其放入 Gin 的上下文存储中。同时，将其放入 HTTP Response **动作**:
|
||||
1. 调用 `pkg/log.WithTraceID(ctx, uuid)` 将 `UUID` 注入标准 `Context`。
|
||||
2. 执行 `c.Request = c.Request.WithContext(newCtx)` 将其回写。
|
||||
3. (可选) 同时放入 Gin 上下文存储和 Response Header 供前端使用。
|
||||
|
||||
## 关卡 2：桥接 (Bridge - Context Adapter)
|
||||
|
||||
- **位置**: `internal/pkg/log/context.go`
|
||||
- **设计原则**: `pkg/log` **不依赖** `gin`，只识别标准库 `context.Context`。
|
||||
- **行为**: `log.WithContext(ctx) 调用内部帮助函数 GetTraceID(ctx) 获取 TraceID。`
|
||||
- **前置条件**: 必须依赖上游（Middleware）将 TraceID 提前注入到标准 Context 中。
|
||||
- **输出**: 返回一个预置了 `zap.String("trace_id", id)` 字段的 Logger。
|
||||
|
||||
## 关卡 3：穿透 (Propagation - Service/Repo)
|
||||
|
||||
- **行为**: 所有的业务方法签名必须包含 `ctx context.Context` 作为第一个参数。
|
||||
- **动作**: 严禁在层级调用中丢弃 Context（例如使用 `context.Background()` 替代传入的 ctx），这会导致链路断裂。
|
||||
|
||||
## 关卡 4：异步与后台边界 (Async & Background Boundary)
|
||||
|
||||
- **高危场景**: 在 Handler 中启动 Goroutine 处理耗时任务。
|
||||
- **陷阱**: `gin.Context` 是非线程安全的。如果 Goroutine 执行时 HTTP 请求已结束，Gin 会重置该 Context，导致数据竞争或脏读。
|
||||
- **解决方案**: 必须在主协程中执行 `ctx.Copy()`，将副本传递给 Goroutine。日志模块必须支持处理这种副本 Context。
|
||||
- **新增场景：后台任务 (Background Tasks)**
|
||||
- **场景**: 定时任务 (Cron)、消息队列消费者 (MQ Consumer)、系统初始化。
|
||||
- **问题**: 初始 `context.Background()` 不包含 TraceID。
|
||||
- **动作**: 必须调用 `log.StartBackgroundTrace(ctx)` 进行“播种”。该函数会检测 Context，若无 TraceID 则生成新 ID 并注入，确保链路可追踪。
|
||||
|
||||
---
|
||||
|
||||
# 4. 关键架构思考：防腐层 (Anti-Corruption Layer)
|
||||
|
||||
我们在设计时还需考虑一层“防腐”。
|
||||
|
||||
- **问题**: 如果未来我们想给所有的日志加一个字段，比如 `env=prod`，或者想把所有的 `trace_id` 改名为 `traceId`。
|
||||
- **对策**: 所有的业务代码**严禁**直接手动构建 `zap.String("trace_id", …)`。
|
||||
- **约束**: 这个字段的 Key 必须定义在 `pkg/log` 的常量中，且只能由 `WithContext` 内部逻辑自动附加。业务开发者只负责传 Context，不负责管 ID 怎么拼写。
|
||||
|
||||
---
|
||||
|
||||
# 总结
|
||||
|
||||
- **代码位置**: `internal/pkg/log`，包含 `log.go` (入口), `zap.go` (实现), `context.go` (桥接)。
|
||||
- **调用方式**: 注入 Base Logger -> 方法内 `WithContext(ctx)` -> 打印。
|
||||
- **数据流**: Middleware 生成 -> Gin Context 携带 -> Log Adapter 提取 -> Zap Field 输出。
|
||||
- **并发安全**: 警惕 Gin Context 在 Goroutine 中的误用，强调 `Copy()` 机制。
|
||||
```
|
||||
|
||||
==== 02_ 日志\05_ 目录结构与职责.md ====
|
||||
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 目录结构与职责
|
||||
date created: 星期三, 十二月 10日 2025, 10:45:40 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:40:48 晚上
|
||||
---
|
||||
|
||||
# 目录结构与职责
|
||||
|
||||
## 1. 目录结构设计 (Directory Structure)
|
||||
|
||||
该结构旨在实现 **“配置分离”**、**“核心隐藏”** 与 **“上下文桥接”**。
|
||||
|
||||
```Plaintext
|
||||
internal/
|
||||
├── middleware/ # [Global] 全局中间件层
|
||||
│ ├── access_log.go # [New] HTTP 请求访问日志 (请求入/出记录, 耗时统计)
|
||||
│ └── trace.go # [New] 链路追踪 (生成/透传 TraceID -> 注入 Context)
|
||||
│
|
||||
└── pkg/
|
||||
└── log/ # [Level 0] 全局日志核心包 (基于 Zap)
|
||||
├── log.go # [Facade] 对外入口 (Init, Global L(), Static Proxies)
|
||||
├── options.go # [Config] 配置定义 (Level, FilePath, MaxSize)
|
||||
├── zap.go # [Core] Zap 实例构建 (Encoder, Core, AtomicLevel)
|
||||
├── writer.go # [IO] 输出源管理 (Lumberjack 轮转, Console/File 双写)
|
||||
├── context.go # [Bridge] 上下文桥接 (WithContext, TraceID 提取)
|
||||
└── standard.go # [Schema] 标准字段定义 (Standardized Field Constructors)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 文件职责详解 (Responsibilities)
|
||||
|
||||
### A. `internal/pkg/log` (核心日志包)
|
||||
|
||||
这是一个基础设施包，不应依赖任何业务逻辑（User, Order 等）。
|
||||
|
||||
| **文件名** | **职责描述** | **关键设计点 (Design Decisions)** |
|
||||
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **`log.go`** | **门面 (Facade) 与单例管理**。<br>1. 维护私有全局变量 `globalLogger`。<br>2. 提供 `Init(opts)` 初始化入口。<br>3. 提供 `L()` 获取底层 `*zap.Logger`。<br>4. 提供 `Info/Error` 等静态代理方法。 | **单例兜底**：在 `init()` 中初始化一个默认的 `Nop` 或 `Console` Logger，防止未初始化调用导致 Panic。<br>**Caller 修正**：<br>1. 底层 `globalLogger` 配置 `AddCallerSkip(0)`。<br>2. 静态代理方法 (`Info`, `Error`) 内部使用 `WithOptions(AddCallerSkip(1))`。<br>3. `L()` 和 `WithContext()` 返回原生 Logger (Skip 0)，确保业务层直接调用时行号正确。 |
|
||||
| **`options.go`** | **配置对象 (DTO)**。<br>定义 `Options` 结构体，用于接收 Viper 的配置映射。 | **配置解耦**：只定义 struct，不包含逻辑。支持从 `config.yaml` 的 `log` 节点自动 Unmarshal。 |
|
||||
| **`zap.go`** | **核心构建工厂 (Factory)**。<br>负责组装 Encoder (JSON/Console)、Writer 和 Level。<br>实现 `New(opts)` 函数。 | **环境隔离**：<br>- Dev: ConsoleEncoder + StackTrace (Warn 级)<br>- Prod: JsonEncoder + StackTrace (Panic 级) |
|
||||
| **`writer.go`** | **IO 输出管理**。<br>封装 `lumberjack.Logger`。<br>实现 `zapcore.WriteSyncer` 接口。 | **可靠性**：配置 `Lumberjack` 的 `Compress: true` 和 `MaxSize: 100MB`。实现 Console + File 的 **Tee (双写)** 模式。 |
|
||||
| **`context.go`** | **上下文装饰器与播种器 (Decorator & Seeder)**。<br>1. `WithContext(ctx)`: 提取 TraceID。<br>2. **[New] `StartBackgroundTrace(ctx)`**: 为后台任务生成并注入根 TraceID。 | **零侵入**：仅通过 `zap.With()` 附加字段，返回 **派生 Logger**，不修改全局 Logger，线程安全。 |
|
||||
| **`standard.go`** | **标准化字段与存取器 (Schema & Accessor)**。<br>1. 定义**私有** Context Key 类型，防止碰撞。<br>2. 提供 `WithTraceID(ctx, id)` 和 `GetTraceID(ctx)` 公开方法。<br>3. 定义标准字段构造器 (如 `zap.String("trace_id", …)`)。 | **规范约束**：<br>- 统一使用 snake_case。<br>- 防止拼写错误 (如 `uid` vs `user_id`)。 |
|
||||
|
||||
### B. `internal/middleware` (中间件集成)
|
||||
|
||||
这是日志模块与 HTTP 框架 (Gin) 结合的触点。
|
||||
|
||||
| **文件名** | **职责描述** | **交互逻辑** |
|
||||
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
|
||||
| **`trace.go`** | **链路起点**。<br>链路追踪 (生成 TraceID -> **注入标准 Context** -> 挂载回 Gin Request) | **上下游打通**：保证 TraceID 在微服务或网关间的透传能力。 |
|
||||
| **`access_log.go`** | **流量审计**。<br>1. 记录 `Start Time`。<br>2. 执行 `c.Next()`。<br>3. 计算 `Latency`。<br>4. 打印结构化日志。 | **字段映射**：<br>`path`, `method`, `status`, `client_ip`, `latency`, `user_agent`。**必须使用 `log.WithContext(c)`**。 |
|
||||
| `recovery.go` | 结构化灾难恢复。<br>1. `defer recover()` 捕获 Panic。<br>2. 获取 Stack Trace。<br>3. **调用 `pkg/log` 记录 JSON 格式的 Error 日志** (包含 `stack` 字段)。<br>4. 返回 500 响应。 | **替代 Gin 默认组件**：必须使用 `gin.New()` 启动，手动注册此中间件，杜绝默认的控制台文本打印。 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 数据流转图示 (Data Flow)
|
||||
|
||||
为了确保你理解“上下文”是如何流动的，以下是逻辑路径：
|
||||
|
||||
1. **Request In** -> `middleware/trace.go` -> 生成 `trace_id` -> **Wrap 进 `std.Context`**。 …
|
||||
2. **`pkg/log/context.go`** -> 从 **`std.Context`** 取出 `trace_id` -> …
|
||||
3. **`pkg/log/context.go`** -> 从 `gin.Context` 取出 `trace_id` -> 创建带字段的 `zap.Logger`。
|
||||
4. **`pkg/log/zap.go`** -> 序列化为 JSON `{…"trace_id":"xyz"…}`。
|
||||
5. **`pkg/log/writer.go`** -> 写入 `app.log` 文件 (由 Lumberjack 轮转)。
|
||||
|
||||
## 4. 依赖关系检查 (Dependency Check)
|
||||
|
||||
- `pkg/log` **不依赖** `middleware` (防止循环依赖)。
|
||||
- `middleware` **依赖** `pkg/log` (调用日志打印)。
|
||||
- `pkg/log` **仅依赖** `uber-go/zap`, `natefinch/lumberjack`。**严禁依赖** `gin` 或其他 Web 框架。所有 Context 操作均基于 Go 标准库接口。
|
||||
|
||||
这个结构完全穷尽了我们在前几轮讨论中确定的技术决策。如果确认无误，我们将在下一步生成具体的代码实现。
|
||||
|
||||
```bash
|
||||
|
||||
==== 02_日志\06_日志模块开发规范与质量保证手册.md ====
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 《日志模块开发规范与质量保证手册》
|
||||
- 一、 核心开发规范 (The Golden Rules)
|
||||
date created: 星期三, 十二月 10日 2025, 10:53:19 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:31:04 晚上
|
||||
---
|
||||
|
||||
# 《日志模块开发规范与质量保证手册》
|
||||
|
||||
---
|
||||
|
||||
## 一、 核心开发规范 (The Golden Rules)
|
||||
|
||||
这部分是“软约束”，属于团队共识，通过 Code Review 和 AI 辅助检查来执行。
|
||||
|
||||
### 1. 键名命名公约 (Key Naming Convention)
|
||||
|
||||
日志是给机器（ELK/Loki）读的，键名必须统一，方便建立索引。
|
||||
|
||||
- **规则**: 严禁使用 CamelCase (小驼峰) 或 PascalCase (大驼峰)，**必须且只能使用 snake_case (下划线命名)**。
|
||||
- **反例**: `userId`, `IPAddress`, `httpStatus`
|
||||
- **正例**: `user_id`, `client_ip`, `http_status`
|
||||
- **理由**: 多数数据库和搜索引擎（如 Elasticsearch）的分词器对下划线更友好，且 SQL 查询习惯也是下划线。
|
||||
|
||||
### 2. 类型安全铁律 (Type Safety Strictness)
|
||||
|
||||
利用 Zap 的强类型优势，拒绝隐式转换。
|
||||
|
||||
- **规则**: 在业务热点路径（Hot Path）中，**严禁使用 `zap.Any`、`zap.Reflect` 或 `Sugar` 模式**。
|
||||
- **例外**: 仅在应用启动（Init）、Panic 恢复或非高频的配置加载阶段允许使用 `SugaredLogger`。
|
||||
- **理由**: `zap.Any` 会触发反射（Reflection），导致内存逃逸和 GC 压力。这是高性能系统的“隐形杀手”。
|
||||
|
||||
### 3. 上下文优先原则 (Context First)
|
||||
|
||||
日志不是孤岛，必须依附于请求上下文。
|
||||
|
||||
- **规则**: 所有 Controller、Service、Repository 层的方法，如果需要打印日志，**必须**使用 `log.WithContext(ctx).Info(…)` 及其变体。
|
||||
- **禁止**: 严禁在业务流程中直接调用全局的 `log.Info(…)`（除非是系统级事件，如定时任务启动）。
|
||||
- **理由**: 只有通过 `WithContext`，才能将 TraceID 串联起来。
|
||||
|
||||
### 4. 哨兵值与魔法字符串 (Sentinels & Magic Strings)
|
||||
|
||||
- **规则**: 核心日志字段的 Key 必须定义为常量（Constant）。
|
||||
- **实现**: 在 `pkg/log/standard.go` 中定义 `const TraceIDKey = "trace_id"`。
|
||||
- **禁止**: 代码中出现手写的 `zap.String("trace_id", …)`，防止拼写错误（如写成 `traceid`）。
|
||||
|
||||
### 5. 热点路径复用原则 (Hot Path Reuse)
|
||||
|
||||
针对循环（Loop）或复杂长流程函数，严禁重复构建 Context Logger。
|
||||
|
||||
- **规则**: 必须在作用域入口处初始化 Logger 实例，并在该作用域内复用。
|
||||
- **反例 (Bad)**:
|
||||
|
||||
```Go
|
||||
for _, item := range items {
|
||||
// ❌ 每次循环都分配内存
|
||||
log.WithContext(ctx).Info("processing", zap.String("id", item.ID))
|
||||
}
|
||||
```
|
||||
|
||||
- **正例 (Good)**:
|
||||
|
||||
```Go
|
||||
// ✅ 只分配一次，复用 l
|
||||
l := log.WithContext(ctx)
|
||||
for _, item := range items {
|
||||
l.Info("processing", zap.String("id", item.ID))
|
||||
}
|
||||
```
|
||||
|
||||
- **理由**: 减少大量临时的 `zap.Logger` 结构体分配，降低 GC 的 Scavenge 阶段耗时。
|
||||
|
||||
### 6. 后台任务播种原则 (Background Trace Seeding)
|
||||
|
||||
所有非 HTTP 触发的后台任务入口（Goroutine, Cron, MQ Handler），必须是“有状态”的。
|
||||
|
||||
- **规则**: 任务的第一行代码必须调用 `StartBackgroundTrace`。
|
||||
- **反例 (Bad)**:
|
||||
|
||||
```Go
|
||||
func ProcessOrder(msg []byte) {
|
||||
ctx := context.Background()
|
||||
// ❌ 此时 ctx 空空如也，日志将丢失 TraceID
|
||||
log.WithContext(ctx).Info("processing order")
|
||||
}
|
||||
```
|
||||
|
||||
- **正例 (Good)**:
|
||||
|
||||
```Go
|
||||
func ProcessOrder(msg []byte) {
|
||||
// ✅ 自动生成一个新的 TraceID 注入 ctx
|
||||
ctx := log.StartBackgroundTrace(context.Background())
|
||||
log.WithContext(ctx).Info("processing order")
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 二、 Linter 规则配置 (Automated Enforcement)
|
||||
|
||||
这部分是“硬约束”，我们将在 `.golangci.yml` 中配置这些规则，强行阻断不合规代码的提交。
|
||||
|
||||
### 1. 禁用标准库日志 (`depguard`)
|
||||
|
||||
防止开发人员手滑使用了 Go 原生的 `log` 或 `fmt` 打印日志。
|
||||
|
||||
Linter: depguard
|
||||
|
||||
配置策略:
|
||||
|
||||
- **Deny**:
|
||||
- `log`: 标准库日志（无结构化，无法分级）。
|
||||
- `fmt.Print*`: 控制台打印（生产环境绝对禁止）。
|
||||
- `github.com/sirupsen/logrus`: 防止引入其他日志库。
|
||||
|
||||
### 2. 强制错误处理 (`errcheck`)
|
||||
|
||||
Zap 的 `Sync()` 方法可能会返回错误（特别是在 Linux 的 `/dev/stdout` 上），通常需要忽略，但写入文件的错误不能忽略。
|
||||
|
||||
Linter: errcheck / gosec
|
||||
|
||||
配置策略:
|
||||
|
||||
- 对 `logger.Sync()` 的错误处理进行豁免（Exclude），因为在某些 OS 下 stdout sync 必然报错，这是已知 issue。
|
||||
- 但对 `logger.Info` 等方法的 IO 错误，原则上 Zap 内部处理了，不需要业务层捕获。
|
||||
|
||||
### 3. 自定义规则 (`ruleguard` - 高级)
|
||||
|
||||
标准的 Linter 无法检测“键名必须是 snake_case”。如果需要极致的管控，我们可以引入 `ruleguard`。
|
||||
|
||||
AI 辅助检查逻辑:
|
||||
|
||||
由于配置 ruleguard 较复杂，我们约定在 AI 生成代码阶段 执行此逻辑：
|
||||
|
||||
- **Check 1**: 正则匹配所有 `zap.String("([a-z]+[A-Z][a-z]+)", …)` 模式，如果发现驼峰命名，立刻自我修正。
|
||||
- **Check 2**: 扫描代码中是否存在 `fmt.Print`，如有则报错。
|
||||
|
||||
---
|
||||
|
||||
## 三、 安全与脱敏规范 (Security & Masking)
|
||||
|
||||
这是日志系统的“红线”。
|
||||
|
||||
### 1. PII (个人敏感信息) 零容忍
|
||||
|
||||
- **黑名单字段**: `password`, `token`, `access_token`, `refresh_token`, `credit_card`, `id_card`.
|
||||
- **处理方式**:
|
||||
- **方案 A (拦截器)**: 在 `zapcore` 层加 Hook，但这会损耗性能。
|
||||
- **方案 B (显式脱敏)**: 要求 AI 在生成代码时，对于敏感字段，自动包裹脱敏函数。例如 `zap.String("mobile", mask.Mobile(u.Mobile))`。
|
||||
- **决策**: 采用 **方案 B**。依赖编码时的自觉和 AI 的辅助，性能最优。
|
||||
|
||||
### 2. 大字段截断
|
||||
|
||||
- **规则**: 禁止将 Base64 图片数据、巨大的 HTML 内容直接打入日志。
|
||||
- **限制**: 单个 Field 的 Value 长度建议限制在 2KB 以内。
|
||||
|
||||
---
|
||||
|
||||
## 四、 AI 辅助编码的“质量契约” (AI Quality Contract)
|
||||
|
||||
为了确保我（AI）生成的代码符合上述规范，请你（用户）在审查我的代码时，使用以下 **Checklist** 进行验证。这也是我对你的承诺：
|
||||
|
||||
1. **Imports 检查**: 确认没有引入 `log` 或 `fmt`。
|
||||
2. **Context 检查**: 确认 `log.WithContext(ctx)` 是日志调用的唯一起手式。
|
||||
3. **Keys 检查**: 确认所有 JSON Key 都是 `snake_case`。
|
||||
4. **Args 检查**: 确认使用的是 `zap.String/Int` 等强类型构造器，而非 `zap.Any`。
|
||||
5. **Config 检查**: 确认没有硬编码的路径（如 `/var/log`），必须来自 `options.go`。
|
||||
|
||||
---
|
||||
|
||||
## 五、 总结与下一步
|
||||
|
||||
我们确立了：
|
||||
|
||||
1. **命名**: 强制 snake_case。
|
||||
2. **类型**: 拒绝 `zap.Any`，拒绝 `fmt`。
|
||||
3. **上下文**: 强制 `WithContext`。
|
||||
4. **安全**: 显式脱敏。
|
||||
```
|
||||
|
||||
==== 02_ 日志\07_ 日志模块工程化实施标准.md ====
|
||||
|
||||
```markdown
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 日志模块工程化实施标准
|
||||
date created: 星期三, 十二月 10日 2025, 10:58:53 晚上
|
||||
date modified: 星期三, 十二月 10日 2025, 11:42:26 晚上
|
||||
---
|
||||
|
||||
# 日志模块工程化实施标准
|
||||
|
||||
---
|
||||
|
||||
## 一、 注释与文档规范 (Documentation Standards)
|
||||
|
||||
目标：“中文友好 (Chinese Friendly)” 且 “符合 GoDoc 标准”。
|
||||
|
||||
我们采用 混合语言策略：结构定义用英文（为了 IDE 兼容性），业务解释用中文（为了团队协作）。
|
||||
|
||||
### 1. 导出的包与函数 (Exported Symbols)
|
||||
|
||||
所有对外暴露的函数（首字母大写），必须编写文档注释。
|
||||
|
||||
- **格式要求**：
|
||||
- 第一行：`// FunctionName 简短的英文或中文摘要` (符合 Go Lint 检查)。
|
||||
- 空一行。
|
||||
- 详细说明：**必须使用中文**，解释函数的行为、副作用（Side Effects）和潜在风险。
|
||||
- 参数说明：如果有复杂参数，使用 `// - param: explanation` 格式。
|
||||
- **范例 (Style Guide)**:
|
||||
|
||||
> // WithContext returns a logger with the trace ID injected.
|
||||
>
|
||||
> //
|
||||
>
|
||||
> // [功能]: 从 context.Context 中提取 TraceID 并附加到 Logger 字段中。
|
||||
>
|
||||
> // [注意]: 这是一个轻量级操作，但如果 ctx 为 nil，将返回原始 Logger 的 fallback。
|
||||
>
|
||||
> // [场景]: 务必在 Controller 或 Service 的入口处优先调用。
|
||||
|
||||
### 2. 内部实现细节 (Internal Logic)
|
||||
|
||||
对于 `internal/pkg/log` 内部复杂的逻辑（如 `lumberjack` 的配置转换），必须在代码块上方添加中文注释。
|
||||
|
||||
- **原则**：解释 **“为什么这么做 (Why)”**，而不是“做了什么 (What)”。代码本身已经展示了做了什么。
|
||||
- **范例**:
|
||||
|
||||
> // [Why]: 这里不使用 zap.NewProduction 自带的 OutputPaths，
|
||||
>
|
||||
> // 因为我们需要同时输出到控制台 (为了 Docker 采集) 和文件 (为了本地容灾)，
|
||||
>
|
||||
> // 且文件输出需要通过 Lumberjack 进行轮转控制。
|
||||
|
||||
### 3. README 维护
|
||||
|
||||
在 `internal/pkg/log/README.md` 中维护一份**“速查手册”**。
|
||||
|
||||
- **必填内容**：
|
||||
- 如何在 `config.yaml` 中配置（给出默认值）。
|
||||
- 如何动态调整日志级别（如通过信号或 API）。
|
||||
- 常见错误码（Code）与日志关键字的对应关系。
|
||||
|
||||
---
|
||||
|
||||
## 二、 可拓展性设计 (Extensibility Design)
|
||||
|
||||
虽然我们拒绝“过度封装”，但必须为未来的变化预留接口（Hook Points）。
|
||||
|
||||
### 1. 配置扩展：Functional Options 模式
|
||||
|
||||
我们在 `Init` 函数中，不应列出所有参数，而应使用 `Option` 模式。
|
||||
|
||||
- **设计**: `func Init(opts …Option) error`
|
||||
- **预留能力**: 未来如果需要添加“发送日志到 Kafka”或“开启 Sentry 报警”，只需新增一个 `WithKafka(addr)` 的 Option，而无需修改 `Init` 的函数签名，保证了对旧代码的兼容性。
|
||||
|
||||
### 2. 核心扩展：Zap Hooks
|
||||
|
||||
Zap 原生支持 `Hooks`。我们的封装必须暴露这一能力。
|
||||
|
||||
- **场景**: 当日志级别为 `Error` 或 `Fatal` 时，可能需要同步触发飞书/钉钉报警。
|
||||
- **实现标准**: 在 `zap.go` 的构建逻辑中，检查配置是否定义了 Hooks。这允许我们在不侵入日志核心代码的情况下，挂载报警逻辑。
|
||||
|
||||
### 3. 字段扩展：Context Key Registry
|
||||
|
||||
随着业务发展，需要记录的元数据会增加（如 `TenantID`, `RequestID`, `SpanID`）。
|
||||
|
||||
- **标准**: 不要在 `context.go` 里写死 key 的提取逻辑。
|
||||
- **设计**: 定义一个 `type ContextExtractor func(ctx) []Field` 类型。默认提供 `TraceIDExtractor`。允许在初始化时注册新的 Extractor。这使得业务线可以自定义需要提取的 Context 字段。
|
||||
|
||||
---
|
||||
|
||||
## 三、 查漏补缺 (Gap Analysis)
|
||||
|
||||
在之前的讨论中，有几个隐蔽但致命的工程细节尚未覆盖，这里作为最后防线进行补充。
|
||||
|
||||
### 1. 关于 `Logger.Fatal` 的使用禁令
|
||||
|
||||
- **风险**: `zap.Logger.Fatal` 会在打印日志后调用 `os.Exit(1)`。
|
||||
- **工程标准**: **在 Web 服务（HTTP Server）中，严禁在业务逻辑层调用 `Fatal`。**
|
||||
- _原因_: 这会直接杀死整个进程，导致所有正在处理的请求中断（没有 Graceful Shutdown）。
|
||||
- _替代_: 遇到不可恢复错误，使用 `Error` 级别日志，并返回 `500` 错误给客户端，由上层中间件处理。
|
||||
- _例外_: 仅在 `main.go` 启动阶段（如连不上数据库、读不到配置）可以使用 `Fatal`。
|
||||
|
||||
### 2. 时间格式的一致性
|
||||
|
||||
- **问题**: Zap 默认的时间格式可能是浮点数（Unix Epoch）或非标准字符串。
|
||||
- **标准**: 生产环境统一配置为 **`ISO8601` (2025-12-10T22:00:00.000Z)**。
|
||||
- _理由_: 这种格式跨时区友好，且能被几乎所有日志分析工具（ELK, Splunk, CloudWatch）自动识别并建立时间索引。
|
||||
|
||||
### 3. 动态日志级别 (Hot Reload)
|
||||
|
||||
- **需求**: 线上出 Bug 时，需要临时把 Level 调成 Debug，查完再调回 Info，且不能重启服务。
|
||||
- **实现标准**: 利用 `zap.AtomicLevel`。
|
||||
- 我们需要暴露一个 HTTP 接口（如 `PUT /admin/log/level`）或监听配置文件的 `fsnotify` 事件。
|
||||
- 收到变更信号后，直接调用 `atomicLevel.SetLevel(zap.DebugLevel)`。这是线程安全的，无需重启实例。
|
||||
|
||||
### 4. 测试支持 (Testing Support)
|
||||
|
||||
- **问题**: 单元测试时，不仅不想看到日志刷屏，有时还需要断言“是否打印了某条错误日志”。
|
||||
- **标准**:
|
||||
- 提供 `pkg/log/test_helper.go`。
|
||||
- 封装 `zaptest/observer`。
|
||||
- 允许测试代码通过 `log.NewTestLogger()` 获取一个观察者对象，从而断言 `logs.FilterMessage("error").Len() == 1`。
|
||||
|
||||
### 5. 链路完整性保障
|
||||
|
||||
- **风险**: 开发者容易遗忘在 `go func()` 中传递 Context。
|
||||
- **标准**: 在 Code Review 时，重点检查所有 `go` 关键字后是否跟随了 Context 的传递或播种操作。
|
||||
|
||||
### 6. 框架初始化与 Panic 处理
|
||||
|
||||
- **风险**: `gin.Default()` 会自动注册只打印文本日志的 Recovery 中间件，破坏 JSON 格式。
|
||||
- **标准**:
|
||||
1. 必须使用 `gin.New()` 初始化 Engine。
|
||||
2. 必须手动注册我们自定义的 `middleware.Recovery` 和 `middleware.AccessLog`。
|
||||
3. 确保 Panic 日志中包含 TraceID（从 `c.Request.Context` 中尝试恢复）。
|
||||
|
||||
---
|
||||
|
||||
## 四、 总结与就绪确认
|
||||
|
||||
至此，我们已经完成了日志模块的**全生命周期设计**：
|
||||
|
||||
1. **架构**: 基础设施层，无业务依赖。
|
||||
2. **技术栈**: Zap + Lumberjack + Context Adapter。
|
||||
3. **模式**: 单例兜底 + 依赖注入，强类型约束。
|
||||
4. **规范**: Snake_case 键名，中文友好文档，严禁 Fatal。
|
||||
```
|
||||
Reference in New Issue
Block a user