papp

type AppCtx ¶ added in v0.0.6

type AppCtx struct {
	context.Context

	// 业务通用传递字段
	UserId int32

	// 需要与ctx绑定的工具对象
	Log *plogger.PLogWarper
	// contains filtered or unexported fields
}

-------------------------------------------------- 封装一个请求的上下文

-------------------------------------------------- 1：基础库保持通用性，使用标准 context.Context，通过依赖注入传递工具 2：框架回调入口处完成 AppCtx 创建，后续业务代码直接传递

3：业务层统一使用 AppCtx，享受便捷的日志、追踪和状态管理等等封装

减少样板代码：避免重复提取 trace_id、user_id 等字段
统一日志格式：自动为所有日志添加追踪字段
保持类型安全：结构体字段替代 context.Value 类型转换
提升开发效率：业务代码中提供简单直观的 API

-------------------------------------------------- 选择在/pkg/app层封装AppCtx，因为这是业务层与基础设施层的分界点。 业务层处理具体业务逻辑，需要便捷访问请求级数据（如用户信息、追踪ID）， 而基础库应保持通用性，如基础层需要嵌入业务相关处理，应该以注入的方式进行。 这样设计希望能在业务便捷性和架构清晰度之间取得平衡。

-------------------------------------------------- 我们最终可以这样去比喻：

在处理业务开发时，想象入住一家高级酒店，每位客人入住时都会分配一位专属管家。管家提前知道客人的姓名、偏好、行程安排等所有信息。客人只需对管家说“安排明天的行程”，管家就会自动安排好车辆、餐厅、景点门票等一切事务。

而处理基建开发时，想想这是一家标准化的连锁餐厅，提供统一的厨房设备、食材和烹饪流程。但允许各分店根据当地口味调整调料和配菜。总店提供核心厨艺培训，分店可以注入本地特色食材。

-------------------------------------------------- 封装位置决策树

问1：这个功能是否与当前请求的上下文强相关？
↓
├── 是（如：需要用户ID、trace_id、请求超时）
│   └── 问2：是否业务层所有模块都需要？
│       ├── 是 → 升级"AppCtx管家"的能力（添加到AppCtx结构体/方法）
│       └── 否 → 业务模块自行处理（"客人自己解决"）
│
└── 否（如：通用工具、数据转换、第三方集成）
    ↓
    ├── 问3：是否会被多个业务模块使用？
    │   ├── 是 → 开发基础库功能（"标准化餐厅的新菜式"）
    │   │   ├── 问4：是否需要业务上下文？
    │   │   │   ├── 是 → 支持依赖注入（接受Logger等）或参数传递（"客人定制"）
    │   │   │   └── 否 → 保持纯净实现
    │   │   │
    │   │   └── 问5：是否预期会被其他项目使用？
    │   │       ├── 是 → 放在通用/pkg/
    │   │       └── 否 → 放在项目内部/internal/pkg/
    │   │
    │   └── 否 → 直接在业务模块中实现（"分店特色菜"）
    │
    └── 问6：是否是横切关注点（如：日志、监控、缓存）？
        ├── 是 → 设计为中间件/拦截器模式
        └── 否 → 继续按常规判断

--------------------------------------------------

func NewAppCtx(ctx context.Context) *AppCtx

type ServiceConfig ¶

type ServiceConfig struct {
	Http httpConfig
	Grpc grpcConfig
}