Skill架构入门指南：从零搭建高可用的技能系统

6次阅读

共计 1608 个字符，预计需要花费 5 分钟才能阅读完成。

在游戏或 AI 系统中，技能系统（Skill System）往往是最容易出问题的模块之一。常见的问题包括：

状态同步问题：当多个玩家同时释放技能时，服务端和客户端的状态容易出现不同步，导致 ” 我明明按了技能，但没反应 ” 的情况。
技能打断引发的竞态条件：当一个技能正在执行时，如果被另一个更高优先级的技能打断，可能会出现资源未释放或状态不一致的问题。
冷却（CD/Cooldown）管理混乱：传统的基于时间戳的冷却检查在高并发场景下容易出现误差。

这些问题在传统 OOP 架构下尤其明显，因为技能逻辑往往分散在多个类中，耦合度高，难以维护。

目前主流的技术方案有两种：ECS（Entity Component System）和 Actor 模型。让我们做个简单对比：

特性	ECS	Actor 模型
耦合度	低	极低
并发处理	一般	优秀
状态管理	集中	分布式
适用场景	大规模实体	复杂交互

选择 Actor 模型的主要原因：

天然隔离：每个技能都是一个独立的 Actor，互不干扰
消息驱动：完美匹配技能系统的 ” 事件 - 响应 ” 模式
容错性：单个技能崩溃不会影响整个系统

type SkillActor struct {
    cooldown    int64 // 纳秒单位
    lastUsed    int64 // 最后使用时间(atomic)
}

func (s *SkillActor) TryUse() bool {now := time.Now().UnixNano()
    last := atomic.LoadInt64(&s.lastUsed)

    // 检查冷却是否结束（并发安全）if now - last < s.cooldown {return false}

    // CAS 操作确保原子性
    if !atomic.CompareAndSwapInt64(&s.lastUsed, last, now) {return false // 竞争失败}

    return true
}

关键点说明：

使用 atomic 包保证线程安全
CAS 模式解决竞态条件
时间单位选择纳秒避免精度问题

sequenceDiagram
    participant Player
    participant Scheduler
    participant SkillA
    participant SkillB

    Player->>Scheduler: 释放技能 A(优先级 2)
    Scheduler->>SkillA: 执行检查
    SkillA-->>Scheduler: 准备就绪

    Player->>Scheduler: 释放技能 B(优先级 1)
    Scheduler->>SkillA: 中断请求
    SkillA-->>Scheduler: 确认中断
    Scheduler->>SkillB: 立即执行

调度规则：