3.1 Task 和 *Task

func Read(task Task)       // 收到一份结构体副本
func Update(task *Task)    // 收到原对象地址，可以修改调用者数据

Repository 创建任务使用指针：

Create(ctx context.Context, task *Task) error

因为数据库生成 ID 后，需要写回调用者传入的对象：

task.ID = generatedID

指针不是“性能优化专用工具”。优先根据是否需要共享和修改同一对象来决定。

3.2 []Task 和 []byte

[]Task 是 Task 切片，类似 Python 的 list[Task]。

tasks := []Task{task1, task2}

[]byte(task.Payload) 是类型转换：

json.Unmarshal([]byte(task.Payload), &payload)

task.Payload 是字符串，json.Unmarshal 接受字节切片，所以先把字符串编码为字节。它不是数组索引，也不是特殊 JSON 语法。

4.1 ServiceContext 为什么还要赋值

repo := repository.NewMemoryTaskRepository()
svcCtx := &svc.ServiceContext{TaskRepo: repo}

ServiceContext 中声明字段：

type ServiceContext struct {
    TaskRepo repository.TaskRepository
}

这里只说明“它将来能保存一个 TaskRepository”，并没有创建或赋值。类似 Python：

class ServiceContext:
    task_repo: TaskRepository

ctx = ServiceContext()
ctx.task_repo = MemoryTaskRepository()

依赖注入包含两部分：

1. 用接口定义调用方需要的能力。
2. 在程序组装处把具体实现传进去。

所以不是“Repository 定义不同接口”就自动完成依赖注入，真正的注入发生在 ServiceContext 初始化时。

Handler

负责 HTTP 协议：

func GetTaskHandler(svcCtx *svc.ServiceContext) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        var req types.TaskReq
        // 解析请求、调用 logic、写 HTTP 响应
    }
}

Logic

负责业务规则：

identity, err := auth.IdentityFromContext(ctx)
task, err := repo.GetByID(ctx, identity.UserID, req.Id)

Repository

负责存储细节：

db.WithContext(ctx).
    Where("id = ? AND owner_id = ?", id, ownerID).
    First(&task)

分层的价值不是目录整齐，而是隔离变化：HTTP 格式变化不影响 SQL，MySQL 换成内存实现不影响业务规则。

8.1 context.Background()

ctx := context.Background()

它是一个不会自动取消、没有 deadline 的根 context。通常在 main、测试或清理操作的根部使用。

8.2 派生 Context

ctx, cancel := context.WithTimeout(parent, 3*time.Second)
defer cancel()

子 context 会继承父 context。以下任一事件发生时，子 context 完成：

• 父 context 取消
• 自己被 cancel()
• 三秒超时

8.3 ctx.Done() 和 ctx.Err()

ctx.Done() 返回只读 channel：

<-ctx.Done()

context 被取消或超时时，这个 channel 会被关闭。它不是 goroutine，也不是“开启了一个任务”。

ctx.Err() 返回取消原因：

context.Canceled
context.DeadlineExceeded

if err := ctx.Err(); err != nil {
    return err
}

表示任务开始执行前先检查：上游是不是已经取消了。如果已经取消，就不再做无意义工作。

8.4 Worker Context 和 Task Context

workerCtx：控制整个 worker 进程
taskCtx：从 workerCtx 派生，额外拥有单个任务超时

taskCtx, cancel := context.WithTimeout(workerCtx, taskTimeout)
defer cancel()

worker 退出时，workerCtx 取消，所有 taskCtx 一起取消。单个任务超时，只取消这个 taskCtx，不会停止整个 worker。

9.1 Goroutine

go doWork()

goroutine 是 Go 运行时调度的轻量并发执行单元。它可以粗略类比协程，但调度模型和 Python asyncio 不同。

channel 不是 goroutine。下面两个都是 channel：

timer.C
ctx.Done()

它们只负责发送或表达事件，不负责执行代码。

9.2 GMP 调度模型

GMP 是 Go runtime 调度 goroutine 的核心模型：

G = Goroutine：等待执行的任务
M = Machine：操作系统线程
P = Processor：执行 Go 代码所需的调度资源

可以暂时类比为：

G = 工作任务
M = 工人
P = 工位和工具

它们的基本关系是：

大量 G
  ↓ 进入运行队列
少量 P
  ↓ 与 M 绑定
若干 M
  ↓
CPU 执行

执行下面的代码时，runtime 会创建一个新的 G：

go handleTask()

G 保存待执行函数、当前执行位置、goroutine 栈和调度状态。G 不是操作系统线程，所以一个进程可以创建大量 goroutine，而不需要为每个 goroutine 创建一个线程。

M 对应操作系统线程。CPU 最终执行的仍然是线程，但 runtime 会把多个 G 调度到较少的 M 上执行。

P 保存执行 Go 代码所需的调度状态，其中包括本地 goroutine 运行队列。M 必须取得一个 P，才能执行普通 Go 代码：

M + P -> 执行某个 G

GOMAXPROCS 主要控制 P 的数量：

runtime.GOMAXPROCS(4)

这不表示程序最多只能创建 4 个 goroutine，而是表示最多有 4 个 P 可让 Go 代码并行执行。程序仍然可以有成千上万个 G，其余 G 在运行队列或等待队列中等待调度。

假设有两个 P：

P1 本地队列：G1、G3
P2 本地队列：G2、G4

M1 + P1 -> 执行 G1
M2 + P2 -> 执行 G2

G1 暂停、阻塞或者时间片结束后，M1 可以继续执行 P1 队列中的 G3。

goroutine 等待 channel 时：

value := <-ch

等待中的 G 会被挂起，M 可以继续执行其他可运行的 G：

G1 等待 channel -> G1 进入等待状态
M + P             -> 改为执行 G2

对于 Go 网络 I/O，runtime 通常通过 netpoll 监听就绪事件，等待网络的 G 会被挂起，不需要让一个 M 一直空等。

如果 M 进入阻塞系统调用，runtime 可以把它的 P 交给另一个 M：

原来：M1 + P1 + G1
M1 被系统调用阻塞
随后：M2 + P1 + G2

系统调用完成后，G1 会重新等待调度。这样一个被阻塞的操作系统线程不会长期占住 P。

每个 P 通常优先执行自己的本地队列。当某个 P 没有任务，而另一个 P 的队列很忙时，空闲的 P 可以从对方队列取得一部分 G：

之前：P1 为空，P2 有 G1、G2、G3、G4
之后：P1 取得部分 G，两个 P 继续工作

这个过程称为 Work Stealing，即工作窃取，用来平衡不同 P 的任务量。除了本地队列，runtime 还会处理全局运行队列、网络事件和定时器等来源的可运行 G。

GMP 同时支持并发和并行：

并发：多个 G 在一段时间内交替推进
并行：多个 G 在多个 CPU 核心上同时执行

GOMAXPROCS=1 时，多个 goroutine 仍然可以并发推进，但普通 Go 代码通常只有一个 P 在执行；有多个 P 时，多个 G 才有机会在不同线程和 CPU 核心上并行执行。

面试时可以回答：

GMP 是 Go runtime 的 goroutine 调度模型。G 表示 goroutine，M 表示操作系统线程，P 表示执行 Go 代码所需的调度资源。M 需要绑定 P 才能运行 G，每个 P 有本地运行队列。runtime 通过本地队列、全局队列、工作窃取、网络轮询、阻塞处理和抢占，把大量 goroutine 调度到较少的操作系统线程上。GOMAXPROCS 主要决定 P 的数量和 Go 代码的最大并行度。

9.3 nil channel、无缓冲 channel、有缓冲 channel

var ch chan int        // nil channel
ch1 := make(chan int)  // 无缓冲 channel
ch2 := make(chan int, 3)

区别：

make(chan int) 不是“没有 channel”，而是已经创建 channel，只是没有内部存储槽位。发送和接收必须会合。

9.4 select 是否启动多个 goroutine

不会。

select {
case <-timer.C:
    return nil
case <-ctx.Done():
    return ctx.Err()
}

当前 goroutine 同时等待多个 channel 操作，哪个先就绪就执行哪个 case。等待期间 goroutine 会挂起，不会持续循环占用 CPU。

9.5 Timer 为什么不持续占用当前 goroutine 的 CPU

timer := time.NewTimer(duration)

Go runtime 管理定时器。时间未到时，等待它的 goroutine 被挂起；runtime 到时间后让 timer.C 可接收，再唤醒等待者。

timer.C：时间到后收到一个时间值
ctx.Done()：取消时 channel 被关闭

虽然触发机制不同，对 select 来说它们都表现为“接收操作已就绪”。

9.6 Channel 死锁和 WaitGroup

典型错误：

ch := make(chan int)

go func() {
    defer wg.Done()
    ch <- 1
}()

wg.Wait()
value := <-ch

子 goroutine 等待接收方，主 goroutine 等待 wg.Done()，形成环形等待：

主 goroutine：等待子 goroutine 完成
子 goroutine：等待主 goroutine接收

wg.Done() 在发送语句之后，发送没完成就永远执行不到 Done。

解决方法包括：

• 先启动接收
• 调整 Wait 顺序
• 使用合适容量的缓冲 channel
• 重新设计所有权和退出协议

不能把“加缓冲”当成所有死锁的通用修复。

9.7 关闭 Channel

发送方负责关闭 channel：

close(ch)

接收方判断：

value, ok := <-ch
if !ok {
    // channel 已关闭并且数据已读完
}

关闭 channel 不是清空 channel；缓冲中的数据仍可以继续读取。向已关闭 channel 发送会 panic。

15.1 AutoMigrate

db.AutoMigrate(&repository.User{}, &repository.Task{})

GORM 根据 struct 和 tag 创建或补充表、列和索引。它适合演示项目和简单迁移；复杂生产迁移更适合版本化 SQL 工具。

项目在 internal/database/migrate.go 中先处理旧数据，再执行 AutoMigrate，避免直接增加非空或唯一字段失败。

15.2 表并不是定义 struct 时自动创建

type Task struct { ... }

只定义 Go 类型。必须执行 AutoMigrate 或 SQL migration，数据库里才会出现对应表。

15.3 WithContext

db.WithContext(ctx).First(&task)

它把请求取消和 deadline 传给数据库操作。用户断开、RPC 超时或服务退出时，驱动有机会停止仍在执行的 SQL。

它不会创建新 goroutine，也不会自动开启事务。

幂等创建

客户端发送：

Idempotency-Key: import-2026-10-01

数据库建立 (owner_id, idempotency_key) 唯一索引。相同用户使用相同 key 重复请求时返回原任务。

为什么最终需要数据库唯一约束：

请求 A：先查，没有
请求 B：先查，也没有
A 插入
B 插入

只靠应用层“先查再插”存在竞争，唯一索引才是并发下的最终保证。

分布式锁

加锁：

SET key random-token NX PX ttl

释放时用 Lua 比较 token 后删除，避免锁过期后误删其他进程新获得的锁。

分布式锁不能替代：

• 数据库唯一约束
• 条件更新
• 幂等业务设计

表驱动测试

tests := []struct {
    name string
    input string
    want int
}{
    {name: "valid", input: "...", want: 200},
    {name: "missing", input: "...", want: 404},
}

for _, tt := range tests {
    t.Run(tt.name, func(t *testing.T) {
        // Arrange / Act / Assert
    })
}

表驱动测试没有特殊运行机制，本质是“测试数据切片 + 循环 + 子测试”。价值是多个同类输入共享相同测试流程，新增边界条件只需要加一行数据。

测试层次

纯函数测试：状态转换、参数校验
Repository 测试：内存实现和真实 MySQL
Logic 测试：注入 fake Repository / fake RPC
HTTP 测试：httptest
gRPC 往返测试：bufconn
端到端测试：真实进程和依赖

常用命令：

go test ./...
go test -race ./...
go vet ./...

-race 检测运行期间发生的数据竞争，它不能证明程序绝对没有竞态，但对并发代码非常重要。

字段编号

int64 owner_id = 1;

1 是二进制协议字段编号，不是默认值。

协议发布以后：

• 可以添加新的字段编号。
• 不应随意修改已有编号。
• 删除字段后不要复用旧编号。
• 可以使用 reserved 保留删除的编号和名称。

message Example {
  int64 id = 1;
  reserved 2;
  string status = 3;
}

为什么使用 Protobuf

• 有明确的强类型契约。
• 二进制体积通常比 JSON 小。
• 序列化速度快。
• 可以生成多语言客户端和服务端代码。
• 字段编号支持一定程度的前后兼容。

缺点是协议需要生成，调试时不如 JSON 直观，字段演进必须遵守兼容规则。

哪些文件不要手改

pb/task.pb.go
pb/task_grpc.pb.go
taskservice/task_service.go
internal/server/task_service_server.go

它们由协议和模板生成，重新运行 goctl 时可能被覆盖。

主要业务修改位置：

task.proto
internal/logic
internal/svc
internal/config
etc/*.yaml

User 和 Order 两个服务如何连接

假设系统中有两个独立服务：

user-rpc   用户 RPC 服务
order-api  订单 HTTP 服务

完整调用链是：

前端
-> order-api Handler
-> order-api Logic
-> User RPC Client
-> 网络
-> user-rpc Server
-> user-rpc Logic
-> User Repository
-> MySQL

这里需要先区分三个动作：

1. goctl 根据 .proto 生成代码，不负责启动服务。
2. user-rpc 和 order-api 分别通过各自的 main 启动，是两个独立进程。
3. Order Logic 调用生成的 User RPC Client，不直接调用 User Logic。

syntax = "proto3";

package user;
option go_package = "./userpb";

message GetUserRequest {
  int64 user_id = 1;
}

message GetUserResponse {
  int64 id = 1;
  string name = 2;
  string email = 3;
}

service UserService {
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
}

goctl rpc protoc user.proto \
  --go_out=. \
  --go-grpc_out=. \
  --zrpc_out=.

func main() {
    var c config.Config
    conf.MustLoad(*configFile, &c)

    ctx := svc.NewServiceContext(c)
    server := zrpc.MustNewServer(
        c.RpcServerConf,
        func(grpcServer *grpc.Server) {
            userpb.RegisterUserServiceServer(
                grpcServer,
                userserver.NewUserServiceServer(ctx),
            )
        },
    )

    defer server.Stop()
    server.Start()
}

UserRpc:
  Endpoints:
    - 127.0.0.1:8081

type Config struct {
    rest.RestConf
    UserRpc zrpc.RpcClientConf
}

type ServiceContext struct {
    Config  config.Config
    UserRpc userservice.UserService
}

func NewServiceContext(c config.Config) *ServiceContext {
    return &ServiceContext{
        Config: c,
        UserRpc: userservice.NewUserService(
            zrpc.MustNewClient(c.UserRpc),
        ),
    }
}

func (l *CreateOrderLogic) CreateOrder(
    req *types.CreateOrderReq,
) (*types.CreateOrderResp, error) {
    userResp, err := l.svcCtx.UserRpc.GetUser(
        l.ctx,
        &userpb.GetUserRequest{
            UserId: req.UserID,
        },
    )
    if err != nil {
        return nil, fmt.Errorf("get user: %w", err)
    }

    order := repository.Order{
        UserID: req.UserID,
        Amount: req.Amount,
    }
    // 保存订单……

    return &types.CreateOrderResp{
        OrderID:  order.ID,
        UserID:   userResp.Id,
        UserName: userResp.Name,
    }, nil
}

userpb.GetUserRequest
-> Protobuf 二进制序列化
-> gRPC 网络传输
-> User RPC Server
-> User Logic
-> Protobuf 响应序列化
-> Order 取得 userpb.GetUserResponse

repository.User          User 服务数据库模型
userpb.GetUserResponse   User RPC 对外传输模型
repository.Order         Order 服务数据库模型
types.CreateOrderResp    Order API 的 HTTP 响应模型

return &userpb.GetUserResponse{
    Id:    user.ID,
    Name:  user.Name,
    Email: user.Email,
}, nil

return &types.CreateOrderResp{
    OrderID:  order.ID,
    UserID:   userResp.Id,
    UserName: userResp.Name,
}, nil

写 user.proto
-> goctl 生成 userpb、客户端和服务端代码
-> 实现并启动 user-rpc
-> Order 配置 User RPC 地址
-> Order ServiceContext 初始化客户端
-> Order Logic 调用 User RPC Client
-> 将 Protobuf 响应转换为 Order 自己的结构

5.1 API 读取身份

API logic 从 JWT context 取得当前用户：

identity, err := auth.IdentityFromContext(l.ctx)

API 不相信客户端直接传入 owner ID，而是使用认证结果。

5.2 API 调用生成客户端

task, err := l.svcCtx.TaskRPC.GetTask(
    l.ctx,
    &taskservice.GetTaskRequest{
        OwnerId: identity.UserID,
        TaskId:  req.Id,
    },
)

TaskRPC 是接口：

type TaskService interface {
    GetTask(ctx context.Context, in *GetTaskRequest, opts ...grpc.CallOption) (*Task, error)
}

因此单元测试可以注入 fake RPC，不需要启动网络服务。

5.3 客户端代理

goctl 生成的代理内部：

func (m *defaultTaskService) GetTask(...) (*Task, error) {
    client := pb.NewTaskServiceClient(m.cli.Conn())
    return client.GetTask(ctx, in, opts...)
}

真正的 gRPC generated client 会调用：

cc.Invoke(ctx, "/task.TaskService/GetTask", in, out)

/task.TaskService/GetTask 是完整 RPC 方法名。

5.4 服务端适配层

func (s *TaskServiceServer) GetTask(
    ctx context.Context,
    in *pb.GetTaskRequest,
) (*pb.Task, error) {
    l := logic.NewGetTaskLogic(ctx, s.svcCtx)
    return l.GetTask(in)
}

这层类似 HTTP handler：负责接收协议请求并转给业务 logic，不写复杂业务。

5.5 RPC Logic

task, err := l.svcCtx.TaskRepo.GetByID(
    l.ctx,
    in.GetOwnerId(),
    in.GetTaskId(),
)

Repository 查询 MySQL，RPC logic 再把领域模型转换为 pb.Task。

最终边界：

API ServiceContext -> Task RPC Client
RPC ServiceContext -> TaskRepository -> MySQL

8.1 直连

TaskRPC:
  Endpoints:
    - 127.0.0.1:8080

适合：

• 本地开发
• 单个固定实例
• 初次学习调用链

问题：实例扩缩容或 IP 变化后，客户端配置需要修改。

8.2 etcd 注册与发现

RPC Server 配置：

Etcd:
  Hosts:
    - 127.0.0.1:2379
  Key: task.rpc

服务启动后，把自己的可用地址注册到 task.rpc。

API Client 配置：

TaskRPC:
  Etcd:
    Hosts:
      - 127.0.0.1:2379
    Key: task.rpc

工作过程：

Task RPC 实例 A --注册--> etcd task.rpc
Task RPC 实例 B --注册--> etcd task.rpc

API --查询/监听--> etcd
API 得到 A、B 地址
API 负载均衡选择实例

实例停止或租约过期后，etcd 会移除对应地址，客户端监听到变化后更新连接列表。

etcd 不转发业务请求，它只保存和通知服务实例信息。

8.3 DNS/Kubernetes 服务发现

在 Kubernetes 中，也可以通过稳定 Service DNS：

task-rpc.default.svc.cluster.local

是否使用 etcd 要结合部署环境。已经有 Kubernetes Service 时，再单独引入 etcd 可能增加重复基础设施。

限流

控制单位时间允许的请求量，防止服务过载：

正常流量 -> 放行
超出容量 -> 快速拒绝 ResourceExhausted

熔断

当下游连续失败或超时较多时，暂时停止真实调用，快速返回错误：

Closed：正常请求
Open：直接失败，不再压下游
Half-Open：少量试探请求判断是否恢复

熔断不是修复故障，而是阻止故障扩散。

Logic 单元测试

给 RPC ServiceContext 注入内存 Repository，直接测试业务：

svcCtx := &svc.ServiceContext{TaskRepo: memoryRepo}
logic := NewGetTaskLogic(ctx, svcCtx)

API 单元测试

API 的 TaskRPC 是接口，可以注入 fake：

svcCtx := &svc.ServiceContext{TaskRPC: fakeTaskRPC}

验证：

• JWT 用户 ID 是否成为 owner ID。
• NotFound 是否映射成领域错误。
• Unavailable 是否映射成 503。

gRPC 往返测试

项目使用 bufconn 建立内存 gRPC 连接，真实经过：

Protobuf 序列化
-> gRPC Client
-> gRPC Server
-> Server Adapter
-> Logic
-> 响应反序列化

它比直接调用 logic 更接近真实通信，又不依赖固定端口和 MySQL。

30 秒版本

我用 Go 和 go-zero 实现了一个异步任务平台。API 提供 JWT 登录、任务创建、查询、分页、取消和 SSE 状态推送；独立 worker 使用固定大小 goroutine pool 执行任务。MySQL 是任务状态的事实来源，通过事务和 FOR UPDATE SKIP LOCKED 支持多 worker 原子领取；失败任务采用指数退避重试，创建接口使用幂等键。Redis 用于详情缓存和跨进程事件广播。另外实现了一条 API 到 Task RPC 的 zRPC 查询链路，用于学习 Protobuf、超时和错误映射。

两分钟版本

按照“业务问题、核心设计、可靠性、验证”介绍：

项目解决的是耗时操作不能阻塞 HTTP 请求的问题。API 收到请求后只创建 pending 任务，worker 独立领取并执行。为了控制资源，我没有为每条任务无限创建 goroutine，而是使用固定 worker 数和有界 channel 提供并发限制与背压。

多 worker 部署时，领取过程使用 MySQL 事务和 FOR UPDATE SKIP LOCKED，完成状态更新还要求 status=running 和正确的 worker_id，防止旧 worker 覆盖取消或重新领取后的状态。任务失败后根据错误类型决定永久失败或指数退避重试，worker 异常退出后会恢复过期 running 任务。

API 使用 JWT 和 owner_id 做租户隔离，Redis 使用 cache-aside 缓存详情，并通过 Pub/Sub 把 worker 事件转发到 API 的 SSE 连接。Redis 故障只影响性能和实时事件，不影响 MySQL 中的任务正确性。项目通过内存 Repository 单测、MySQL 集成测试、HTTP 测试、真实 gRPC 往返测试和 race detector 验证。

1. Go 的 interface 有什么特点？

Go interface 是一组方法集合，类型不需要显式声明 implements。只要方法集满足接口，就隐式实现。

项目中的 TaskRepository 同时由内存仓库和 GORM 仓库实现。logic 只依赖接口，因此测试可以替换为内存实现。

追问：接口应该定义在哪里？

通常定义在使用方附近，只暴露调用方真正需要的方法。避免为了“统一”创建包含大量无关方法的大接口。

2. 值接收者和指针接收者有什么区别？

值接收者会复制接收对象，方法不能直接修改原对象；指针接收者接收地址，可以修改原对象，也避免复制较大的 struct。

如果某个类型的方法有一部分使用指针接收者，通常统一使用指针接收者，避免方法集和接口实现产生混淆。

3. Task、*Task、[]Task 有什么区别？

• Task 是结构体值。
• *Task 是指向 Task 的指针，可能为 nil。
• []Task 是 Task 切片，包含连续的 Task 值视图。

Repository 的 Create 使用 *Task，因为数据库生成的 ID 要写回调用方。List 返回 []Task，调用方得到任务列表。

4. Slice 和 array 有什么区别？

数组长度属于类型，例如 [3]int；slice 是对底层数组一段区域的描述，包含指针、长度和容量。

append 在容量不足时会分配新底层数组，因此 append 后的新 slice 可能不再与旧 slice 共享数组。多个 goroutine 并发修改共享 slice 仍需要同步。

5. Map 是否并发安全？

普通 map 不支持无同步的并发读写，可能数据竞争甚至运行时 panic。

项目的 Memory Repository 使用 sync.RWMutex：读操作加读锁，写操作加写锁。sync.Map 适合特定读多写少或 key 集合不稳定场景，不应该默认替代普通 map 和明确的锁。

6. defer 什么时候执行？

defer 在当前函数返回前按后进先出执行。参数在注册 defer 时求值，闭包中的变量则在执行时读取。

项目用它关闭 timer、取消 context、释放数据库连接和执行 wg.Done()。需要注意 defer 属于函数作用域，在大循环里不断 defer 可能导致资源直到函数结束才释放。

7. Go 如何处理错误？

Go 把 error 当普通返回值显式传递。使用 %w 包装错误保留错误链，再用 errors.Is 判断哨兵错误，用 errors.As提取具体错误类型。

项目把 GORM 的 RecordNotFound 转成 ErrTaskNotFound，handler 最终返回 404，实现底层错误与 HTTP 协议解耦。

8. panic 和 error 如何选择？

可预期的业务失败、依赖失败和输入错误应该返回 error。panic 更适合程序无法继续的内部不变量破坏，或启动阶段的不可恢复配置错误。

HTTP 请求处理中不应该用 panic 表达“任务不存在”。框架虽然可能 recover，但会丢失清晰的业务语义。

9. 为什么项目中经常返回对象副本？

Memory Repository 的 map 保存结构体值，Get 时再复制返回，避免调用者在没有锁的情况下修改仓库内部对象。

如果结构体包含指针字段，只复制 struct 仍可能共享指针指向的数据，所以项目的 cloneTask 还复制了时间和幂等键指针。

10. []byte(task.Payload) 是什么？

这是把 string 转成字节切片，因为 json.Unmarshal 接受 []byte。它会产生包含 UTF-8 字节的切片，不是启动 goroutine，也不是 JSON 专用语法。

11. Goroutine 和线程有什么区别？

goroutine 由 Go runtime 调度，初始栈较小且可以动态增长，多个 goroutine 复用较少的 OS 线程。线程由操作系统调度，创建和切换成本通常更高。

goroutine 轻量不代表可以无限创建。无限 goroutine 会消耗内存、连接和调度资源，所以项目使用固定 worker pool。

12. Channel 是 goroutine 吗？

不是。goroutine 是执行单元，channel 是同步和传值机制。

timer.C 和 ctx.Done() 都是 channel。select 等待它们时不会为每个 case 创建 goroutine。

13. 无缓冲 channel 和有缓冲 channel 有什么区别？

无缓冲 channel 的发送必须与接收同时会合；有缓冲 channel 在缓冲未满时可以先保存数据，发送方立即继续。

项目 worker 的 jobs channel 有界缓冲，用于吸收短期波动，同时在满时阻塞调度器形成背压。

14. nil channel 有什么行为？

对 nil channel 发送和接收都会永久阻塞，关闭 nil channel 会 panic。

在 select 中把某个 channel 设为 nil，可以动态禁用对应 case，因为它永远不会就绪。

15. 关闭 channel 后接收会发生什么？

缓冲数据会先被读完，之后接收立即返回元素类型零值，ok=false：

value, ok := <-ch

向已关闭 channel 发送会 panic；重复关闭也会 panic。通常由发送方负责关闭。

16. select 如何工作？

select 检查多个 channel 操作。一个 case 就绪时执行它；多个同时就绪时伪随机选择；没有就绪且没有 default 时，当前 goroutine 挂起。

select 不会持续忙轮询，也不会自动创建多个 goroutine。

17. 为什么无缓冲 channel 配合 WaitGroup 可能死锁？

如果子 goroutine 在发送，主 goroutine先 Wait，接收发生在 Wait 之后：

子 goroutine 等主 goroutine 接收
主 goroutine 等子 goroutine Done

形成环形等待。因为发送没完成，子 goroutine无法执行后面的 wg.Done()。

18. Mutex 和 Channel 如何选择？

保护共享状态通常使用 Mutex；传递任务、事件或所有权通常使用 Channel。

不要为了“Go 风格”强行用 channel 包装简单计数器，也不要让多个 goroutine 通过无锁共享 map 交换任务。

19. sync.Mutex 和 sync.RWMutex 有什么区别？

Mutex 同一时间只允许一个持有者。RWMutex 允许多个读锁并存，但写锁排斥所有读写。

读操作非常短或写竞争较多时，RWMutex 不一定更快。是否使用应以访问模式和 benchmark 为依据。

20. Context 包含什么？

主要包含取消、deadline 和请求范围元数据。它应该作为函数第一个参数向下传递，不应该存进长期对象，也不应该把可选参数全部塞入 context。

项目中 JWT 身份、HTTP 取消、RPC deadline 和 SQL 取消都通过 context 传播。

21. ctx.Done() 与 ctx.Err() 的区别？

Done() 返回取消时会关闭的 channel，用来等待通知；Err() 返回完成原因，通常是 context.Canceled 或 context.DeadlineExceeded。

case <-ctx.Done():
    return ctx.Err()

22. 为什么创建 WithTimeout 后要调用 cancel？

即使操作提前完成，timer 和父子 context 关系也可能继续存在到 deadline。调用 cancel 可以及时释放相关资源。

常见写法：

ctx, cancel := context.WithTimeout(parent, time.Second)
defer cancel()

23. context.Background() 应该在哪里使用？

通常用于 main、测试或一个独立生命周期的根部。请求处理函数应该使用传入的 request context。

worker 完成状态清理时项目会创建短时 Background context，因为 worker 根 context 已取消，但仍需要把 running 任务恢复成 pending。这是明确的新清理生命周期，必须设置短超时。

24. Timer 为什么不会持续占用 CPU？

Go runtime 管理定时器堆和唤醒。等待 timer channel 的 goroutine 会被挂起，时间到后 runtime 让它重新可运行。

time.NewTimer 适合单次定时；time.NewTicker 适合周期事件。用完应 Stop，避免无用资源继续存在。

25. 如何检测并发数据竞争？

运行：

go test -race ./...

race detector 在运行路径上监控内存访问。它只能发现测试实际覆盖到的竞争，因此还需要有针对性的并发测试。

26. 为什么使用 Handler、Logic、Repository 分层？

Handler 隔离 HTTP，Logic 集中业务规则，Repository 隔离存储。每层面向一种变化，降低耦合并提高可测试性。

分层过多也会增加跳转成本。简单 CRUD 不需要为每行代码再抽象一层，边界应服务于真实变化和测试需求。

27. 什么是依赖注入？

对象不在内部硬编码创建依赖，而由外部组装后传入。

svcCtx := &ServiceContext{TaskRepo: memoryRepo}

ServiceContext 字段声明只是说明它能保存哪类依赖；赋值才是真正注入。

28. 为什么 logic 不直接使用 *gorm.DB？

直接依赖 GORM 会把 SQL、错误类型和数据库细节扩散到业务层，单元测试也必须连接数据库。

依赖 Repository 接口后，可以替换存储实现并把底层错误转换成稳定的领域错误。

29. API 和 worker 为什么拆成两个进程？

HTTP 请求短且面向用户，任务执行长且资源消耗不稳定。拆分后可以独立扩容、隔离故障和控制并发。

它们仍共享 MySQL 作为任务事实来源，因此仅仅有两个进程不等于完整微服务架构。

30. 如何实现优雅关闭？

根部监听 SIGINT/SIGTERM，取消 context；调度器停止领取新任务；worker 收到取消后结束或把任务重新安排；WaitGroup 等待 goroutine 退出；最后关闭数据库、Redis 和服务器。

必须设置最长关闭时间，否则一个不响应 context 的任务可能导致进程永远无法退出。

31. AutoMigrate 做什么？

根据 GORM model 创建或补充表、列和索引。它不会因为定义 struct 就自动执行。

生产中的复杂迁移通常需要有版本、可审查、可回滚的 SQL migration。项目为了兼容旧数据，在 AutoMigrate 前先回填新字段。

32. WithContext(ctx) 有什么作用？

把取消和 deadline 交给 GORM 和数据库驱动。上游取消后，仍在执行的 SQL 有机会中止。

它不会开启事务。事务使用 db.Transaction 或 Begin/Commit/Rollback。

33. 什么是数据库事务 ACID？

• Atomicity：事务内操作全成或全败。
• Consistency：事务前后满足约束和业务不变量。
• Isolation：并发事务相互影响受到隔离级别控制。
• Durability：提交结果在故障后仍保存。

事务不是自动解决所有并发问题，查询和更新是否在同一事务、锁定哪些行、条件是否完整都很关键。

34. MySQL 常见隔离级别有哪些？

Read Uncommitted、Read Committed、Repeatable Read、Serializable。InnoDB 默认通常是 Repeatable Read。

隔离级别越高，一般并发限制越强。还要结合 MVCC、快照读、当前读和具体 SQL 分析，不能只背“解决了哪种读问题”。

35. 什么是乐观锁和悲观锁？

悲观锁在操作前锁定资源，例如 SELECT ... FOR UPDATE；乐观锁通常用 version 或状态条件更新，提交时发现冲突。

项目领取批次使用行锁和 SKIP LOCKED；完成任务使用 status + worker_id 条件更新，属于乐观条件校验。

36. FOR UPDATE SKIP LOCKED 的作用？

FOR UPDATE 锁住选中行；SKIP LOCKED 遇到已经锁定的行直接跳过。多个 worker 可以各自领取不同任务，不需要等待同一行。

它必须放在事务中，并在同一事务内把任务更新为 running。

37. 为什么检查 RowsAffected？

SQL 没报错不代表业务更新成功。条件更新影响 0 行说明前置状态已经变化，例如任务被取消或 worker ID 不匹配。

项目把这种情况转换成 ErrTaskConflict，避免旧 worker 覆盖新状态。

38. Offset 分页有什么问题？

页数很深时数据库需要跳过越来越多记录，性能下降；并发插入还可能导致翻页重复或遗漏。

后台管理的小数据量列表可用 Offset。大列表使用基于 ID 或时间的游标分页。

39. 如何设计任务表索引？

索引应围绕查询模式：

• (owner_id, created_at) 支持用户任务列表。
• (status, next_run_at) 支持领取到期 pending 任务。
• (owner_id, idempotency_key) 唯一索引支持幂等创建。

索引会增加写入和存储成本，不应给每个字段机械加索引。

40. 什么是 Cache-Aside？

应用先查缓存，未命中查数据库并回填；更新数据库后删除缓存。

Redis 是派生数据，数据库是事实来源。缓存失败时项目回退数据库，保证核心读取仍可用。

41. 缓存穿透、击穿、雪崩分别是什么？

• 穿透：不断查询不存在的数据，缓存一直未命中。可缓存空结果、校验参数、使用布隆过滤器。
• 击穿：一个热点 key 过期，大量请求同时查数据库。可互斥重建、逻辑过期或提前刷新。
• 雪崩：大量 key 同时失效或 Redis 整体故障。可增加 TTL 抖动、限流、降级和高可用部署。

42. 为什么更新后删除缓存，而不是直接更新缓存？

删除策略较简单，下一次读从数据库加载最新值。直接更新缓存仍要处理数据库成功、缓存失败以及并发写顺序。

删除也不能完全消除所有竞态，高一致性场景可能需要版本号、延迟双删、订阅 binlog 或缩短 TTL。

43. Redis 分布式锁为什么需要随机 token？

锁可能在持有者执行期间过期，随后被另一个进程获取。旧持有者结束时如果直接 DEL，会误删新锁。

随机 token 标识锁所有者，Lua 脚本比较 token 后再删除，保证检查和删除原子执行。

44. JWT 的优缺点？

优点是服务端不必为每个 token 保存 session，适合水平扩展。缺点是签发后难以立即撤销，payload 可被解码，密钥泄漏影响大。

应使用 HTTPS、短期 access token、合理密钥轮换；敏感信息不要放 payload。需要主动注销时可以配合 token version、黑名单或 refresh token。

45. 认证和授权有什么区别？

认证确认调用者身份，授权判断身份能访问哪些资源。

项目 JWT middleware 负责认证；Repository 的 owner_id 条件参与授权和数据隔离。

46. SSE、WebSocket、轮询如何选择？

SSE 是服务端到客户端单向推送，基于 HTTP，适合任务状态和通知；WebSocket 双向通信，适合聊天和协作；轮询实现简单但有延迟和无效请求。

项目任务状态只需要单向推送，因此 SSE 足够。

47. SSE 连接如何清理？

监听 r.Context().Done()，客户端断开后退出循环并执行 unsubscribe。还要发送 heartbeat 避免代理关闭空闲连接，对慢客户端使用有限缓冲和明确的丢弃策略。

48. 为什么使用 Worker Pool？

限制并发数量，避免任务数量直接变成 goroutine 数、数据库连接数或外部请求数。有界队列还能提供背压。

并发数不是越大越好。CPU 密集任务接近 CPU 核数，I/O 密集任务可以更高，但应通过压测和下游容量确定。

49. 为什么任务要有状态机？

状态机明确允许的变化，防止 succeeded 再变 running、canceled 被旧 worker 写成 succeeded 等非法情况。

状态条件必须落实到数据库 UPDATE WHERE 中，不能只在内存中检查。

50. 什么是至少一次执行？

系统为了避免任务丢失，故障后可能重新执行同一任务，因此保证“至少执行一次”，但可能重复。

外部副作用必须设计幂等，例如使用 task ID 作为业务唯一键，或先记录执行结果再判断是否已完成。

51. 为什么重试需要指数退避和抖动？

依赖故障时立即高频重试会进一步压垮依赖。指数退避逐步降低频率，抖动避免大量任务在同一时刻同时重试。

还需要最大重试次数和永久错误分类，否则无效任务会无限消耗资源。

52. RPC 或任务超时是否代表执行失败？

不一定。超时只说明调用方没有按时得到结果，服务端或外部系统可能已经完成操作。

因此超时后的重试必须依赖幂等，不能通过“客户端看到超时”推断事务一定没有提交。

53. Worker 崩溃后 running 任务怎么办？

项目记录 started_at，并在启动时恢复超过阈值的 running 任务。阈值必须大于正常最长任务时间，否则会误恢复仍在执行的长任务。

更完整的方案是任务租约：worker 周期续租 lease_expires_at，只有租约过期才允许其他 worker 重新领取。

54. 用户取消正在运行的任务后会怎样？

数据库状态先改为 canceled。当前执行器可能还在运行，但它完成后使用 status=running AND worker_id=? 更新，条件不满足，因此不能覆盖 canceled。

进一步优化可以为每个运行任务保存 cancel function，让 API 取消事件通知对应 worker 尽快停止外部工作。

55. Redis 挂了以后系统还能工作吗？

MySQL 仍可创建、领取和更新任务，详情查询可以回退数据库。缓存加速和跨进程实时事件会降级。

这来自设计原则：Redis 不保存不可恢复的唯一事实。若把任务队列只放在无持久化 Redis 中，故障模型会完全不同。

56. RPC 和本地函数调用最大的区别？

RPC 经过网络，会超时、断连、重复、部分失败；本地调用通常只有返回或进程异常。

所以 RPC 接口需要超时、错误码、幂等、监控和兼容性设计，不能仅因为语法像函数就忽略分布式失败。

57. Protobuf 字段编号有什么意义？

编号用于二进制编码识别字段。发布后修改或复用编号会导致新旧版本错误解析数据。

删除字段应 reserved，新增字段使用新编号。

58. goctl 生成的 RPC 代码分哪些部分？

• pb：Protobuf message 和 gRPC 底层 client/server。
• taskservice：go-zero 客户端包装。
• internal/server：服务端适配层。
• internal/logic：业务实现入口。
• internal/svc：Repository、DB 等依赖组装。

生成文件不写业务逻辑，业务主要放 logic 和 ServiceContext。

59. 直连和服务发现有什么区别？

直连由配置提供固定地址，简单但不能自动感知实例变化。服务发现由实例注册地址，客户端监听可用列表并负载均衡。

etcd 只保存服务信息，不代理业务流量。在 Kubernetes 中也可以使用 Service DNS，不一定需要额外 etcd。

60. 什么是熔断？

下游持续失败时暂时停止调用，快速返回，避免线程、连接和队列被失败请求耗尽。经过等待后进入半开状态，用少量请求探测恢复。

熔断解决故障扩散，限流解决流量超过容量，两者目的不同。

61. 微服务为什么强调数据所有权？

如果多个服务都直接修改同一组表，任何服务都不能独立演进表结构和业务约束，服务边界只是形式上的。

数据独立会带来跨服务查询和事务成本，因此要在自治能力和复杂度之间权衡。

62. 跨服务事务如何处理？

优先使用本地事务加事件实现最终一致性，例如 Outbox。需要补偿的长流程可以使用 Saga。分布式强一致方案成本较高，只在业务确实需要时使用。

回答时应说明失败场景、重复消息、消费幂等和补偿，而不只是说“使用消息队列”。

63. 当前项目为什么没有继续拆多个微服务？

业务规模和团队规模不需要。继续拆分会增加网络错误、部署、配置、数据一致性和本地调试成本。

当前只实现一条 Task zRPC 链路用于验证技术和理解边界，这体现了按需求演进，而不是为了技术名词过度设计。

64. 表驱动测试有什么特殊之处？

没有特殊运行机制，本质是测试用例结构体切片加循环和 t.Run。优势是统一流程覆盖多个输入，易于增加边界条件并清晰显示失败用例名。

65. Fake、Mock 和集成测试如何选择？

Fake 是可工作的简化实现，例如内存 Repository；Mock 更关注交互和调用参数；集成测试连接真实依赖验证 SQL、驱动和配置。

业务逻辑优先用 fake 保持稳定，关键数据库语义再用真实 MySQL 集成测试验证。

66. 日志、指标、Trace 各解决什么问题？

• 日志记录离散事件和上下文。
• 指标展示聚合趋势、告警和容量。
• Trace 展示单次请求跨组件耗时。

例如先通过失败率指标发现异常，再按 task ID 查日志，最后用 trace 确认慢在 API、RPC 还是 SQL。

67. 为什么 Prometheus label 不能放 task ID？

task ID 取值无限增长，每个值都会形成新时间序列，导致内存、存储和查询成本爆炸。label 应选择有限集合，例如 task type、status 和 error category。

68. healthz 和 readyz 有什么区别？

healthz 表示进程是否存活；readyz 表示当前是否具备接收流量的条件。

进程可能活着但数据库连接不可用，此时 healthz 成功、readyz 失败，让负载均衡停止转发新请求而不必立刻重启进程。

69. 两个 worker 会不会执行同一任务？

正常领取阶段通过事务、行锁和 SKIP LOCKED 避免同时领取；状态完成更新还检查 worker ID。

但崩溃恢复和超时重试意味着系统整体仍是至少一次语义，极端故障下任务可能重复执行，所以 executor 的外部副作用仍需幂等。

70. 数据库成功、Redis 删除缓存失败怎么办？

数据库结果正确，但短时间可能读到旧缓存。项目记录错误并依靠 TTL 最终过期。

更高一致性需求可以使用版本号、事件驱动失效、重试队列或读取时校验版本，但会增加复杂度。

71. Task RPC 挂了，API 会怎样？

配置了 RPC 的任务详情查询会在超时后得到 gRPC Unavailable 或 DeadlineExceeded，API 转成 503。注册和当前仍保留本地实现的其他接口不一定受影响。

生产中应通过指标、熔断和 readiness 观察故障，而不是无限重试把故障放大。

72. 如何提高任务吞吐？

先测瓶颈，再选择：

• 增加 worker 数或实例数。
• 调整领取 batch 和 channel 容量。
• 优化任务 SQL 和索引。
• 批量更新或减少事务次数。
• 对 I/O 调用设置连接池和并发上限。
• 对 CPU 密集任务按核心数控制并发。

必须同时关注数据库、Redis和外部依赖容量，不能只调大 goroutine 数。

73. 如何证明项目真的支持并发？

提供三类证据：

1. race detector 通过。
2. 两个并发领取者只有一个能领取同一行的集成测试。
3. 固定任务量下，不同 worker 数的吞吐和 P95 数据。

仅说“使用了 goroutine”不能证明并发设计正确。

74. 如果要把项目变成更有简历价值的业务项目，怎么做？

可以加入 CSV 批处理：上传文件、分批校验、进度更新、生成结果文件、Webhook 通知、失败记录和人工重试。

再增加任务租约、Outbox、死信任务和压测数据。真实业务闭环和量化结果比继续堆中间件更有说服力。

2.1 编译器、Runtime 和操作系统的边界

它们会配合工作。例如：

编译器判断 task 需要逃逸到堆
-> Runtime 从堆分配内存
-> 操作系统提供底层虚拟内存页
-> task 不再可达后由 Runtime GC 回收

2.2 用项目请求串起 Runtime

一次创建任务请求进入项目后，可以从 Runtime 视角理解：

网络数据到达
-> netpoll 唤醒处理连接的 G
-> GMP 把 G 调度到 M 上执行
-> Handler、Logic 创建请求与 Task 对象
-> 逃逸对象从 Go 堆分配
-> G 等待 MySQL 时被挂起，M 执行其他 G
-> 请求结束，失去引用的堆对象等待 GC

因此 Runtime 不是一个孤立知识点。GMP、内存分配和 GC 一直在业务代码背后共同工作。

3.1 G 的常见状态

为了理解调度，先关注三个状态：

runnable：已经可以运行，正在队列中等待 P
running：正在某个 M 上执行
waiting：等待 channel、网络、锁、timer 或其他事件

状态变化示例：

创建 G -> runnable
获得 P 和 M -> running
等待 jobs channel -> waiting
channel 收到任务 -> runnable
再次被调度 -> running
函数结束 -> dead，可被 Runtime 复用相关结构

3.2 本地队列、全局队列和 Work Stealing

每个 P 有本地运行队列。新创建的 G 通常优先放入当前 P 的队列，减少多个 P 对同一个全局队列的争用。

P1 本地队列：G1、G3
P2 本地队列：G2、G4

M1 + P1 -> G1
M2 + P2 -> G2

Runtime 也有全局运行队列，用于存放部分等待调度的 G。调度器会在合适时机检查全局队列，避免其中的 G 长期得不到执行。

如果 P1 没有任务，而 P2 的队列很长，P1 可以从 P2 取得一部分 G，这就是 Work Stealing：

之前：P1 为空，P2 有 G1、G2、G3、G4
之后：P1 取得部分 G，两个 P 并行工作

3.3 Channel 阻塞

task := <-jobs

没有任务时，当前 G 进入 waiting。它会记录在 channel 的等待队列中，M 和 P 可以继续执行别的 G。

G1 等待 channel
-> G1 挂起
-> M + P 改为执行 G2
-> jobs 出现数据
-> G1 变为 runnable

“G 被阻塞”通常不等于“M 也被阻塞”。

3.4 网络 I/O 与 netpoll

网络读取没有数据时，Runtime 通常借助操作系统 I/O 多路复用机制，把 G 交给 netpoll 等待：

G1 等待 socket
-> G1 挂起
-> M 执行其他 G
-> socket 就绪
-> netpoll 让 G1 重新 runnable

这使大量网络连接不需要一一对应同等数量、一直等待的线程。

3.5 阻塞系统调用

某些系统调用可能真的阻塞 M。Runtime 可以把 P 从被阻塞的 M 上移走，让另一个 M 继续使用它：

原来：M1 + P1 + G1
M1 进入阻塞系统调用
随后：M2 + P1 + G2

系统调用完成后，G1 会重新参与调度。

3.6 抢占与 sysmon

如果一个 G 长时间执行计算而不主动等待，Runtime 仍需要让其他 G 获得运行机会。调度器可以在安全位置抢占长时间运行的 G。

Runtime 的系统监控逻辑还会参与网络轮询、定时器、长时间系统调用和抢占等工作。面试中知道它承担监控和辅助调度职责即可，不需要背具体源码函数。

3.7 放回项目 Worker Pool

项目启动固定数量 worker goroutine：

worker G1、G2、G3 等待 jobs
-> 没有任务时全部 waiting，不持续占用 CPU
-> 调度器取到任务并发送到 jobs
-> 某个 worker 变为 runnable
-> GMP 选择一个 P 和 M 执行它
-> worker 等待数据库或 timer 时再次挂起

Worker Pool 限制的是同时处理任务的业务并发量；GOMAXPROCS 限制的是执行普通 Go 代码的并行资源。两者不是同一个参数。

GMP 的核心不是记住字母，而是能解释：G 在哪里排队，什么事件让它挂起，什么事件让它重新 runnable，以及 M 阻塞时 P 如何继续工作。

4.1 栈与堆

栈 Stack：跟随函数调用分配和回收
堆 Heap：由 GC 判断对象何时不可达并回收

每个 goroutine 都有自己的可增长栈。函数调用产生栈帧，函数返回后栈帧可以整体失效，因此栈分配通常很快。

堆对象可以跨越函数调用继续存活，也可以被多个组件引用。堆分配本身和后续 GC 扫描都会产生成本。

与 Python 不同，Go 变量放在栈还是堆，不由 new、make 或是否使用指针直接决定，而由编译器逃逸分析决定。

4.2 什么是逃逸

如果编译器无法证明变量只在当前调用内安全使用，它就可能被移动到堆上：

func createNumber() *int {
    number := 10
    return &number
}

createNumber 返回后仍需要访问 number，所以它不能随当前栈帧失效。

使用指针不等于必然逃逸：

func update() int {
    number := 10
    pointer := &number
    *pointer = 20
    return number
}

如果指针没有离开当前调用，编译器仍可能把 number 保留在栈上，甚至优化到寄存器中。

4.3 常见逃逸场景

• 返回局部变量的指针。
• 把指针写入全局变量或长生命周期对象。
• 被闭包或新 goroutine 捕获。
• 传入编译器无法完整分析的接口调用。
• 局部对象过大，不适合当前 goroutine 栈。
• 某些 interface 装箱和反射调用。

当前项目创建任务时：

if key := strings.TrimSpace(req.IdempotencyKey); key != "" {
    idempotencyKey = &key
}

task := &repository.Task{
    IdempotencyKey: idempotencyKey,
}

执行逃逸分析：

go test -run '^$' -gcflags='-m=1' ./internal/logic

编译器会报告类似结果：

moved to heap: key
&repository.Task{...} escapes to heap

key 的地址保存进 Task；Task 又被 Repository、缓存和响应转换使用，因此这些对象需要跨越当前局部作用域。

逃逸不是 Bug。优化时应关注高频路径中大量、可避免的堆分配，而不是追求所有对象都在栈上。

5.1 mcache

每个 P 有本地 mcache。M 绑定 P 执行 G 时，小对象通常先从该 P 的 mcache 分配，常见路径不需要竞争全局锁。

P1 -> mcache1
P2 -> mcache2

5.2 Span 和 Size Class

span 是一组连续内存页。用于小对象的 span 会被切成固定大小的槽位：

32 字节规格：| 32B | 32B | 32B | 32B |
128 字节规格：| 128B | 128B | 128B |

这些规格称为 Size Class。对象会放入能容纳它的最小合适规格，因此可能产生少量内部碎片，但分配和回收会更快。

5.3 mcentral 与 mheap

mcache 某个规格用完后，从对应 mcentral 获取 span。mcentral 是多个 P 共享的；如果它也没有可用 span，再向 mheap 获取内存页。

可以类比为：

mcache   = 工位旁的零件盒
mcentral = 车间共享仓库
mheap    = 工厂总仓库

小对象通常按 Size Class 分配；大对象需要更多连续页，会直接走 mheap 的大对象路径。大量大对象会迅速推高堆大小和 GC 压力。

5.4 Slice 扩容与预分配

Slice 由指针、长度和容量组成。容量不足时，append 需要申请新的底层数组并复制旧数据：

申请更大数组 -> 复制旧元素 -> 追加新元素 -> 旧数组等待回收

项目分页代码已经预分配容量：

items := make([]types.TaskResp, 0, len(tasks))
for i := range tasks {
    items = append(items, *taskToResp(&tasks[i]))
}

已知结果长度时还可以直接按长度创建并用下标写入。是否值得修改，应由 benchmark 的 B/op 和 allocs/op 判断。

6.1 可达性与 GC Root

GC 不根据变量名或源码作用域判断对象死亡，而是判断能否从 GC Root 沿指针找到对象。常见 Root 包括：

• 全局变量。
• goroutine 栈。
• 寄存器中的指针。
• runtime 内部结构。

能从 Root 到达的对象存活，无法到达的堆对象可以回收。

6.2 并发三色标记

白色：还没有检查
灰色：对象已发现，但引用尚未扫描完成
黑色：对象及其引用已经扫描完成

GC 从 Root 开始把对象加入灰色集合，持续扫描灰色对象的引用。扫描完成的对象变黑；标记结束后仍为白色的对象不可达。

用项目对象举例。假设一个正在执行的 worker 栈上持有 task，Task 又引用 Payload 的底层字符串数据：

worker goroutine 栈（Root）
          |
          v
        Task ----------> Payload 数据

cache map -----------> 另一个 Task

orphan Task            无任何引用

标记过程可以理解为：

1. 从 goroutine 栈找到正在执行的 Task，把它变灰
2. 扫描 Task，发现 Payload，把 Payload 变灰，Task 变黑
3. 从全局 cache 找到另一个 Task，继续扫描
4. 灰色集合清空后，orphan Task 仍为白色，可以回收

关键判断不是“函数是否结束”，而是“是否还能沿引用链从 Root 到达”。如果一个泄漏的 goroutine 一直持有 Task，即使业务早已结束，Task 仍然可达，GC 也不能回收它。

6.3 写屏障

标记期间业务 goroutine 仍会修改指针。如果已经扫描的黑色对象突然引用一个尚未发现的白色对象，GC 可能漏标。写屏障在指针写入时执行辅助记录，维持标记正确性。

写屏障不是互斥锁，而是编译器和 runtime 配合插入的指针写入辅助逻辑。

6.4 GC 阶段与 STW

可以简化为：

短暂 STW，准备标记并开启写屏障
-> 与业务并发标记存活对象
-> 短暂 STW，结束标记并关闭写屏障
-> 清扫未存活对象，供后续分配复用

Go GC 不是完全没有 STW，而是把主要标记工作并发执行，尽量缩短暂停阶段。

6.5 GC Assist

如果业务 goroutine 分配速度过快，GC 标记速度可能跟不上。runtime 会要求分配内存的 goroutine 协助完成一部分标记工作，这称为 GC Assist。

大量分配 -> GC 跟不上 -> 业务 goroutine 协助标记 -> 请求延迟上升

因此降低无意义的临时对象分配，通常比盲目调整 GC 参数更有效。

6.6 GOGC 与 GOMEMLIMIT

GOGC 控制堆相对上次存活堆的增长目标：

GOGC=100 ./app

调低通常降低内存、增加 GC CPU；调高通常减少 GC 频率、增加内存。

GOMEMLIMIT 为 runtime 提供软内存目标：

GOMEMLIMIT=1GiB ./app

它不是操作系统的硬限制。容器内存还包含 goroutine 栈、线程栈、runtime 元数据和非 Go 内存，因此设置时必须保留余量。

6.7 回收、复用与归还系统

GC 判定对象死亡后，其空间可以被 runtime 复用，但不一定立即归还操作系统。Scavenger 会在合适时机释放部分空闲物理页。

所以可能出现：

HeapAlloc 已下降，但进程 RSS 没有立刻下降

这不一定是内存泄漏。需要结合存活堆、空闲堆、已释放页和 RSS 判断。

观察 GC：

GODEBUG=gctrace=1 ./app

重点观察 GC 频率、GC CPU、暂停时间、回收前后堆大小，以及 GC 后存活堆是否持续增长。

6.8 GMP 与 GC 如何一起工作

GC 并不是 GMP 之外的另一套执行系统。GC 的并发标记工作同样需要 CPU，并由 Runtime 与业务 goroutine 协调执行：

业务 G 通过 GMP 使用 P
GC 标记工作也需要 P 的执行时间
STW 阶段暂停业务 G
GC Assist 让分配过快的业务 G 帮助标记

这解释了两个常见现象：

分配速率很高
-> GC 更频繁、Assist 更多
-> CPU 上升，请求延迟可能变大

大量对象长期存活
-> 每轮 GC 需要扫描更多对象和指针
-> GC 成本上升，内存也难以下降

所以 Runtime 性能问题不能只看某一个参数。需要把调度、分配速率、存活堆和业务延迟放在一起分析。

8.1 开启诊断端点

在独立的内部管理端口注册 pprof，避免把诊断接口直接暴露到公网：

import (
    "net/http"
    _ "net/http/pprof"
)

go func() {
    _ = http.ListenAndServe("127.0.0.1:6060", nil)
}()

生产环境还应限制监听地址、网络访问和权限。pprof 采集会产生额外开销，按排查需要开启。

8.2 常用 Profile

采集 CPU Profile：

go tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=30

采集当前堆：

go tool pprof http://127.0.0.1:6060/debug/pprof/heap

采集 goroutine：

go tool pprof http://127.0.0.1:6060/debug/pprof/goroutine

pprof 交互命令：

top       查看累计消耗最多的函数
top -cum  查看包含子调用后的累计消耗
list fn   查看函数内具体热点行
web       生成调用关系图

CPU 高时看 CPU Profile；内存持续上涨时同时看 inuse_space 和 alloc_space。前者回答“谁仍占着内存”，后者回答“谁曾经大量分配”。

10.1 永久等待发送

func produce(ch chan<- int) {
    result := calculate()
    ch <- result // 没有接收方时永久等待
}

修复时加入明确取消路径：

select {
case ch <- result:
case <-ctx.Done():
    return
}

10.2 永久等待接收

for task := range jobs {
    handle(task)
}

如果发送方永远不关闭 jobs，worker 无法退出。需要明确 channel 所有权：通常由发送方负责关闭，并且关闭动作只能发生一次。

10.3 缺少网络超时

client := &http.Client{}
resp, err := client.Do(req)

请求可能长期等待。应设置客户端超时或使用带 deadline 的 Context，并正确关闭响应体。

10.4 忘记停止后台循环

go func() {
    ticker := time.NewTicker(time.Second)
    for range ticker.C {
        refresh()
    }
}()

改为可取消生命周期：

go func() {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()

    for {
        select {
        case <-ticker.C:
            refresh()
        case <-ctx.Done():
            return
        }
    }
}()

10.5 WaitGroup 环形等待

如果子 goroutine 等待主 goroutine 接收，主 goroutine 却先 Wait，双方会永久等待。WaitGroup 只负责计数，不会自动解除 channel 阻塞。

10.6 泄漏排查流程

runtime.NumGoroutine 或监控曲线持续上涨
-> 采集两次 goroutine profile
-> 按调用栈聚合并比较增长
-> 找到大量相同阻塞栈
-> 判断在等 channel、锁、网络、timer 还是 Context
-> 补齐退出条件、超时和资源关闭
-> 压测后确认 goroutine 数回落或保持稳定

快速查看文本调用栈：

curl 'http://127.0.0.1:6060/debug/pprof/goroutine?debug=2'

重点不是“goroutine 数量大”，而是数量是否持续增长，以及相同调用栈是否不断堆积。固定 worker pool 长期保留固定数量 goroutine 属于正常行为。

13.1 Runtime 是什么？

Runtime 是编译进 Go 可执行文件的底层运行支持系统，负责 goroutine 调度、栈和堆管理、GC、channel、timer、netpoll 和 panic 等机制。它不是独立服务，也不是解释器。

13.2 G、M、P 分别是什么？

G 是 goroutine 及其执行状态，M 是操作系统线程，P 是执行普通 Go 代码所需的调度资源。M 绑定 P 后从运行队列取得 G 执行，GOMAXPROCS 主要决定 P 的数量。

13.3 变量什么时候逃逸到堆？

当编译器不能证明变量只在当前栈帧内安全使用时，例如返回局部指针、被闭包或 goroutine 捕获、保存到长生命周期对象，变量可能逃逸。最终结论应使用 -gcflags=-m 验证。

13.4 使用指针一定会产生堆分配吗？

不一定。指针只在当前函数内使用时，对象仍可能位于栈或寄存器。是否逃逸由生命周期和编译器分析决定。

13.5 mcache、mcentral、mheap 分别做什么？

mcache 为每个 P 提供小对象快速分配；mcentral 管理共享的同规格 span；mheap 管理全局堆、内存页和大对象，并在需要时向操作系统申请内存。

13.6 Go GC 是否完全没有 STW？

不是。主要标记工作并发执行，但标记准备和结束等阶段仍有短暂 STW。

13.7 写屏障解决什么问题？

它记录并发标记期间的指针变化，防止业务 goroutine 修改对象关系后出现漏标，保证可达对象不会被错误回收。

13.8 Heap Profile 和 Alloc Profile 有什么区别？

Heap 的 inuse 视角强调当前仍存活的内存，适合找谁持有内存；Alloc 的累计视角强调历史分配总量，适合找高频临时分配。

13.9 如何判断 goroutine 泄漏？

先观察 goroutine 数是否在稳定流量下持续上涨，再对比多个时间点的 goroutine profile。如果某类阻塞调用栈持续增加且没有合理退出路径，才能判断泄漏。

13.10 CPU 高如何排查？

先确认流量与 GC CPU，再采集异常窗口的 CPU profile，通过 top、top -cum 和 list 定位热点；在本地用 benchmark 或相同负载复现，修改后用相同条件对比。

13.11 为什么 GC 后 RSS 没立即下降？

死亡对象的空间可能已经变为 runtime 可复用内存，但物理页尚未由 scavenger 归还操作系统。还要排查 goroutine 栈、线程栈和非 Go 内存。

13.12 sync.Pool 能解决所有分配问题吗？

不能。Pool 中对象可能随 GC 被清理，也会增加生命周期和维护复杂度。只适合可复用、创建成本明显并且经 profile 证明是热点的临时对象。