游戏邮件系统：不只是发个通知

这是"游戏运营工具"系列的第一篇。很多人觉得发邮件是件简单的事——不就是个消息推送吗？但真正做过游戏运营的人都知道，邮件系统是运营的核心基础设施之一。今天我们来聊聊这个看似简单、实则复杂的技术系统。

引言

"给所有 30 级以上的玩家发一封活动通知，附带 100 金币奖励。"

听起来很简单，对吧？

但如果我告诉你，这个需求背后涉及：

• 如何在 5 分钟内完成 200 万封邮件的发送？
• 如何确保玩家登录后第一时间看到邮件？
• 如何防止邮件被恶意刷取？
• 如何让运营同事能独立完成这类操作？

邮件系统，从来就不是"发个通知"那么简单。它是游戏运营的隐形基础设施，支撑着从日常通知到大型活动的各种场景。一套好的邮件系统，能让运营事半功倍；一套有问题的邮件系统，则可能成为事故的源头。

一、游戏邮件系统的特殊性

1.1 与普通邮件的本质区别

游戏邮件系统和我们日常使用的 Email 有本质不同：

游戏邮件是游戏运营的核心触达渠道，它不只是传递信息，更是发放奖励、维系关系、驱动活跃的重要工具。

1.2 游戏邮件的独特价值

为什么游戏厂商要花大力气建设邮件系统，而不是直接用第三方推送？

1.3 典型使用场景

邮件系统在游戏运营中的应用场景非常广泛：

• 维护公告、版本更新提醒
• 活动预告、限时福利通知
• 系统规则变更说明

• 充值返利、首充奖励
• 活动排名奖励
• 补偿礼包（维护补偿、bug 补偿）

• 流失玩家的定向召回
• 高价值玩家的 VIP 专属关怀
• 新手引导的阶段性奖励

• 新功能/新英雄介绍
• 限时优惠提醒
• 联动活动宣传

可以说，邮件系统是连接游戏与玩家的核心桥梁之一。

二、邮件系统的核心功能

2.1 邮件类型划分

从业务角度，游戏邮件可以分为以下几类，每类的技术处理方式有所不同：

技术特点：不需要预先计算目标玩家列表，采用"延迟计算"策略——邮件元数据只存一份，玩家登录时动态判断是否应该收到。

技术特点：需要预先计算符合条件的玩家列表，或者存储筛选条件在玩家登录时动态匹配。

技术特点：最简单的形式，直接写入玩家邮箱即可。

技术特点：需要任务调度系统支持，到期自动触发发送流程。

2.2 附件系统设计

邮件附件是游戏邮件的核心价值之一。一个完善的附件系统需要处理多个维度：

• 货币类：金币、钻石、绑定钻石等
• 道具类：消耗品、装备、材料
• 外观类：皮肤、称号、头像框
• 特殊类：碎片、积分、抽奖券

不同类型的物品，在显示、领取、使用时有不同的处理逻辑。

// 附件项定义
type Attachment struct {
    Type        int    `json:"type"`         // 物品类型：1=货币 2=道具 3=外观
    ItemID      int    `json:"item_id"`      // 物品ID
    Count       int    `json:"count"`        // 数量
    ExpireAt    int64  `json:"expire_at"`    // 过期时间（0表示永不过期）
    ExtraData   string `json:"extra_data"`   // 扩展数据（如装备属性）
}

// 邮件定义
type Mail struct {
    ID           int64         `json:"id"`
    Title        string        `json:"title"`
    Content      string        `json:"content"`
    Sender       string        `json:"sender"`
    Attachments  []Attachment  `json:"attachments"`
    ExpireAt     int64         `json:"expire_at"`
    CreatedAt    int64         `json:"created_at"`
}

• 一次性领取：领取后邮件消失
• 可重复领取：每天/每周可领一次
• 有条件领取：达到某等级、完成某任务才能领取
• 选择性领取：多个附件中选一个

• 附件本身的有效期（道具过期时间）
• 邮件的有效期（多久未领取自动删除）
• 领取后的使用期限

这些时间维度需要清晰区分，避免玩家困惑。

• 同一邮件不能重复领取
• 异常领取行为检测（短时间大量领取）
• 账号异常检测（新注册账号批量领取）

2.3 筛选能力

定向邮件的核心在于筛选。筛选能力越强，运营能做的精准触达就越多。

常见的筛选维度：

// 筛选条件定义
type MailFilter struct {
    LevelRange      *IntRange   `json:"level_range"`       // 等级范围
    VIPRange        *IntRange   `json:"vip_range"`         // VIP等级范围
    LastLoginDays   *IntRange   `json:"last_login_days"`   // 最后登录天数
    TotalRecharge   *IntRange   `json:"total_recharge"`    // 累计充值金额
    RegisterTime    *TimeRange  `json:"register_time"`     // 注册时间范围
    Channels        []string    `json:"channels"`          // 渠道列表
    Platforms       []string    `json:"platforms"`         // 平台列表
    CustomTags      []string    `json:"custom_tags"`       // 自定义标签
}

type IntRange struct {
    Min *int `json:"min"`
    Max *int `json:"max"`
}

type TimeRange struct {
    Start *int64 `json:"start"`
    End   *int64 `json:"end"`
}

复杂的筛选条件可以组合使用，比如"iOS 平台 + 累计充值超过 500 元 + 7 天未登录"，实现精准召回。

2.4 状态管理

邮件从创建到消亡，经历多个状态：

已创建 → 待发送 → 发送中 → 已送达 → 已阅读 → 已领取 → 已过期/已删除

                    ┌─────────────────────────────────────────┐
                    │                                         │
                    ▼                                         │
┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐  │  ┌──────────┐
│ 已创建   │───▶│ 待发送   │───▶│ 发送中   │───▶│ 已送达   │──┼─▶│ 已过期   │
└──────────┘    └──────────┘    └──────────┘    └──────────┘  │  └──────────┘
                                                    │         │
                                                    ▼         │
                                               ┌──────────┐  │
                                               │ 已阅读   │  │
                                               └──────────┘  │
                                                    │         │
                                    ┌───────────────┼─────────┘
                                    ▼               ▼
                               ┌──────────┐  ┌──────────┐
                               │ 已领取   │  │ 已删除   │
                               └──────────┘  └──────────┘

每个状态的转换都需要记录时间和操作者，这有几个重要意义：

三、邮件模板系统详解

3.1 为什么需要模板？

运营每天可能要发几十封不同类型的邮件。如果没有模板系统：

• 内容风格不统一，影响品牌形象
• 格式容易出错，变量替换遗漏
• 效率低下，每次都要从头写
• 难以追踪效果，无法对比优化

模板系统让运营能快速创建标准化的邮件，同时保留个性化空间。

3.2 模板引擎设计

一个灵活的模板系统需要支持变量替换、条件渲染、循环等能力。

标题：【{event_type}】{event_name} 奖励已发放

亲爱的 {player_name}：

{if rank <= 10}
恭喜您在「{event_name}」活动中获得第 {rank} 名！这是您应得的荣耀！
{else}
感谢您参与「{event_name}」活动，您获得了第 {rank} 名的好成绩！
{endif}

奖励内容：
{foreach reward in rewards}
- {reward.name} x {reward.count}
{endforeach}

{if vip_level >= 5}
作为尊贵的 VIP{vip_level} 会员，您还额外获得了 10% 奖励加成！
{endif}

领取截止：{expire_date}

请及时领取，祝您游戏愉快！

{game_name} 运营团队

// 模板引擎
type TemplateEngine struct {
    templates map[string]*Template
}

// 模板定义
type Template struct {
    ID          int64  `json:"id"`
    Code        string `json:"code"`        // 模板编码
    Name        string `json:"name"`        // 模板名称
    Category    string `json:"category"`    // 分类：system/activity/marketing
    TitleTmpl   string `json:"title_tmpl"`  // 标题模板
    ContentTmpl string `json:"content_tmpl"` // 正文模板
    DefaultTTL  int    `json:"default_ttl"` // 默认有效期（小时）
    Version     int    `json:"version"`     // 版本号
}

// 渲染上下文
type RenderContext struct {
    Player    *PlayerInfo
    Event     *EventInfo
    Rewards   []RewardInfo
    Variables map[string]interface{}
}

// 渲染模板
func (e *TemplateEngine) Render(tmplCode string, ctx *RenderContext) (title, content string, err error) {
    tmpl, ok := e.templates[tmplCode]
    if !ok {
        return "", "", fmt.Errorf("template not found: %s", tmplCode)
    }
    
    title, err = e.renderString(tmpl.TitleTmpl, ctx)
    if err != nil {
        return "", "", err
    }
    
    content, err = e.renderString(tmpl.ContentTmpl, ctx)
    if err != nil {
        return "", "", err
    }
    
    return title, content, nil
}

// 解析变量
func (e *TemplateEngine) renderString(tmpl string, ctx *RenderContext) (string, error) {
    // 变量替换：{variable} -> 实际值
    result := variableRegex.ReplaceAllStringFunc(tmpl, func(match string) string {
        varName := strings.Trim(match, "{}")
        return e.getVariable(varName, ctx)
    })
    
    // 条件渲染：{if condition}...{endif}
    result = e.processConditionals(result, ctx)
    
    // 循环渲染：{foreach item in list}...{endforeach}
    result = e.processLoops(result, ctx)
    
    return result, nil
}

3.3 模板分类管理

按业务场景分类模板，便于查找和管理：

// 创建模板
type CreateTemplateRequest struct {
    Code        string `json:"code" binding:"required"`
    Name        string `json:"name" binding:"required"`
    Category    string `json:"category" binding:"required"`
    TitleTmpl   string `json:"title_tmpl" binding:"required"`
    ContentTmpl string `json:"content_tmpl" binding:"required"`
    DefaultTTL  int    `json:"default_ttl"`
}

// 模板预览
type PreviewTemplateRequest struct {
    TemplateCode string                 `json:"template_code"`
    SampleData   map[string]interface{} `json:"sample_data"`
}

// 返回预览结果
type PreviewTemplateResponse struct {
    Title     string `json:"title"`
    Content   string `json:"content"`
    Variables []string `json:"variables"` // 模板中使用的变量列表
}

3.4 模板版本管理

模板上线后可能需要修改，但已发送的邮件不应受影响。因此需要版本管理：

// 发送邮件时记录模板版本
type Mail struct {
    ID              int64  `json:"id"`
    TemplateCode    string `json:"template_code"`
    TemplateVersion int    `json:"template_version"` // 记录使用的版本
    // ... 其他字段
}

// 获取模板时指定版本
func (s *TemplateService) GetTemplate(code string, version int) (*Template, error) {
    if version == 0 {
        // 获取最新版本
        return s.getLatestTemplate(code)
    }
    // 获取指定版本
    return s.getTemplateByVersion(code, version)
}

3.5 模板效果追踪

同一类型的邮件，使用不同模板，效果可能差异很大。

• 打开率：收到邮件的玩家中，有多少打开了
• 领取率：打开邮件的玩家中，有多少领取了附件
• 点击率：如果邮件中有链接，有多少人点击了

// A/B 测试配置
type ABTestConfig struct {
    ID           int64   `json:"id"`
    Name         string  `json:"name"`
    TemplateA    string  `json:"template_a"`    // 模板A编码
    TemplateB    string  `json:"template_b"`    // 模板B编码
    Ratio        float64 `json:"ratio"`         // A组比例（0.0-1.0）
    TargetCount  int     `json:"target_count"`  // 目标样本量
    StartTime    int64   `json:"start_time"`
    EndTime      int64   `json:"end_time"`
}

// 根据玩家ID分组
func (s *ABTestService) GetTemplateForPlayer(testID int64, playerID int64) (string, error) {
    config, err := s.getTestConfig(testID)
    if err != nil {
        return "", err
    }
    
    // 使用玩家ID的哈希值进行分组，保证同一玩家始终在同一组
    hash := crc32.ChecksumIEEE([]byte(fmt.Sprintf("%d", playerID)))
    if float64(hash%100)/100 < config.Ratio {
        return config.TemplateA, nil
    }
    return config.TemplateB, nil
}

// 统计测试结果
type ABTestResult struct {
    TemplateCode   string  `json:"template_code"`
    SentCount      int     `json:"sent_count"`
    OpenCount      int     `json:"open_count"`
    ClaimCount     int     `json:"claim_count"`
    OpenRate       float64 `json:"open_rate"`
    ClaimRate      float64 `json:"claim_rate"`
}

四、批量发送的技术挑战与解决方案

4.1 规模的挑战

假设你的游戏有 500 万活跃玩家，要发一封全服邮件：

4.2 延迟写入策略（核心优化）

传统方式：为每个玩家创建一条邮件记录。500 万玩家 = 500 万条记录。

核心思路：

• 邮件元数据（内容、附件、筛选条件）存储一次
• 玩家登录时，根据筛选条件判断是否应该收到这封邮件
• 领取后才创建实际的领取记录

这种方式让"全服邮件"变成了"一份数据 + 规则"，无论玩家多少，存储成本恒定。

// 邮件定义（只存一份）
type MailDefinition struct {
    ID           int64        `json:"id"`
    Type         int          `json:"type"`          // 1=全服 2=定向 3=个人
    Title        string       `json:"title"`
    Content      string       `json:"content"`
    Attachments  []Attachment `json:"attachments"`
    Filter       *MailFilter  `json:"filter"`        // 筛选条件
    StartTime    int64        `json:"start_time"`    // 生效开始时间
    EndTime      int64        `json:"end_time"`      // 生效结束时间
    CreatedAt    int64        `json:"created_at"`
}

// 玩家邮件箱（只记录已领取的）
type PlayerMailbox struct {
    ID           int64 `json:"id"`
    PlayerID     int64 `json:"player_id"`
    MailDefID    int64 `json:"mail_def_id"`    // 关联邮件定义
    Status       int   `json:"status"`         // 1=已读 2=已领取
    ReadAt       int64 `json:"read_at"`
    ClaimedAt    int64 `json:"claimed_at"`
}

// 获取玩家邮件列表
func (s *MailService) GetPlayerMails(playerID int64, page, pageSize int) ([]*Mail, int64, error) {
    // 1. 获取所有生效中的邮件定义
    now := time.Now().Unix()
    mailDefs, err := s.getActiveMailDefinitions(now)
    if err != nil {
        return nil, 0, err
    }
    
    // 2. 获取玩家已处理的邮件
    processedMails, err := s.getPlayerProcessedMails(playerID)
    if err != nil {
        return nil, 0, err
    }
    processedMap := make(map[int64]bool)
    for _, pm := range processedMails {
        processedMap[pm.MailDefID] = true
    }
    
    // 3. 筛选玩家应该看到的邮件
    playerInfo, _ := s.getPlayerInfo(playerID)
    var mails []*Mail
    for _, def := range mailDefs {
        // 已处理过（已领取/已删除）
        if processedMap[def.ID] {
            continue
        }
        
        // 检查筛选条件
        if !s.matchFilter(playerInfo, def.Filter) {
            continue
        }
        
        // 转换为返回格式
        mails = append(mails, &Mail{
            ID:          def.ID,
            Title:       def.Title,
            Content:     def.Content,
            Attachments: def.Attachments,
            ExpireAt:    def.EndTime,
        })
    }
    
    // 4. 分页返回
    total := int64(len(mails))
    start := (page - 1) * pageSize
    end := start + pageSize
    if end > len(mails) {
        end = len(mails)
    }
    
    return mails[start:end], total, nil
}

// 匹配筛选条件
func (s *MailService) matchFilter(player *PlayerInfo, filter *MailFilter) bool {
    if filter == nil {
        return true // 无筛选条件，全服邮件
    }
    
    // 等级范围
    if filter.LevelRange != nil {
        if filter.LevelRange.Min != nil && player.Level < *filter.LevelRange.Min {
            return false
        }
        if filter.LevelRange.Max != nil && player.Level > *filter.LevelRange.Max {
            return false
        }
    }
    
    // VIP等级
    if filter.VIPRange != nil {
        if filter.VIPRange.Min != nil && player.VIPLevel < *filter.VIPRange.Min {
            return false
        }
        if filter.VIPRange.Max != nil && player.VIPLevel > *filter.VIPRange.Max {
            return false
        }
    }
    
    // 渠道
    if len(filter.Channels) > 0 {
        found := false
        for _, ch := range filter.Channels {
            if player.Channel == ch {
                found = true
                break
            }
        }
        if !found {
            return false
        }
    }
    
    return true
}

4.3 索引与缓存策略

玩家打开邮箱时，需要快速返回邮件列表。这涉及数据库层面的优化。

-- 邮件定义表索引
CREATE INDEX idx_mail_def_active ON mail_definitions(start_time, end_time);
CREATE INDEX idx_mail_def_type ON mail_definitions(type);

-- 玩家邮箱表索引
CREATE INDEX idx_player_mailbox_player ON player_mailbox(player_id);
CREATE INDEX idx_player_mailbox_player_def ON player_mailbox(player_id, mail_def_id);

// 缓存热门邮件定义
func (s *MailService) getActiveMailDefinitions(now int64) ([]*MailDefinition, error) {
    cacheKey := fmt.Sprintf("mail:defs:active:%d", now/300) // 5分钟更新一次
    
    // 先从缓存获取
    if cached, err := s.cache.Get(cacheKey); err == nil {
        return cached.([]*MailDefinition), nil
    }
    
    // 从数据库查询
    defs, err := s.repo.FindActiveMailDefinitions(now)
    if err != nil {
        return nil, err
    }
    
    // 写入缓存
    s.cache.Set(cacheKey, defs, 5*time.Minute)
    return defs, nil
}

// 缓存玩家未读数量
func (s *MailService) GetUnreadCount(playerID int64) (int, error) {
    cacheKey := fmt.Sprintf("mail:unread:%d", playerID)
    
    if cached, err := s.cache.Get(cacheKey); err == nil {
        return cached.(int), nil
    }
    
    // 计算未读数量
    mails, _, err := s.GetPlayerMails(playerID, 1, 1000)
    if err != nil {
        return 0, err
    }
    
    count := len(mails)
    s.cache.Set(cacheKey, count, 1*time.Minute)
    return count, nil
}

// 领取后清除缓存
func (s *MailService) ClaimMail(playerID, mailID int64) error {
    // ... 领取逻辑
    
    // 清除未读数缓存
    s.cache.Delete(fmt.Sprintf("mail:unread:%d", playerID))
    
    return nil
}

• 玩家登录时预取未读邮件数量
• UI 层提前展示红点/数字角标

4.4 任务队列设计

大规模发送不能同步执行，需要任务队列解耦：

[运营后台] → 创建任务 → [任务队列] → [发送服务] → [存储层]

// 邮件发送任务
type MailSendTask struct {
    TaskID      int64        `json:"task_id"`
    MailDefID   int64        `json:"mail_def_id"`
    Type        string       `json:"type"`        // broadcast/targeted/personal
    TargetCount int          `json:"target_count"`
    Progress    int          `json:"progress"`    // 已处理数量
    Status      string       `json:"status"`      // pending/running/completed/failed
    CreatedAt   int64        `json:"created_at"`
    StartedAt   int64        `json:"started_at"`
    CompletedAt int64        `json:"completed_at"`
    Error       string       `json:"error"`
}

// 任务处理器
type MailTaskProcessor struct {
    queue      *TaskQueue
    mailService *MailService
    workerNum  int
}

func (p *MailTaskProcessor) Start() {
    for i := 0; i < p.workerNum; i++ {
        go p.worker()
    }
}

func (p *MailTaskProcessor) worker() {
    for {
        task, err := p.queue.Pop()
        if err != nil {
            time.Sleep(1 * time.Second)
            continue
        }
        
        p.processTask(task)
    }
}

func (p *MailTaskProcessor) processTask(task *MailSendTask) {
    // 更新状态为运行中
    task.Status = "running"
    task.StartedAt = time.Now().Unix()
    p.queue.UpdateTask(task)
    
    switch task.Type {
    case "targeted":
        // 定向邮件：分批处理玩家列表
        p.processTargetedMail(task)
    case "personal":
        // 个人邮件：直接写入
        p.processPersonalMail(task)
    }
}

func (p *MailTaskProcessor) processTargetedMail(task *MailSendTask) {
    // 获取筛选条件
    mailDef, _ := p.mailService.GetMailDefinition(task.MailDefID)
    
    // 分批获取目标玩家
    batchSize := 1000
    offset := 0
    
    for {
        players, err := p.mailService.GetPlayersByFilter(mailDef.Filter, offset, batchSize)
        if err != nil {
            task.Status = "failed"
            task.Error = err.Error()
            p.queue.UpdateTask(task)
            return
        }
        
        if len(players) == 0 {
            break
        }
        
        // 批量写入玩家邮箱
        for _, player := range players {
            p.mailService.CreatePlayerMail(player.ID, mailDef)
            task.Progress++
        }
        
        // 更新进度
        p.queue.UpdateTask(task)
        
        offset += batchSize
        
        // 控制写入速率，避免压垮数据库
        time.Sleep(100 * time.Millisecond)
    }
    
    task.Status = "completed"
    task.CompletedAt = time.Now().Unix()
    p.queue.UpdateTask(task)
}

• 削峰填谷：突发的大量发送请求不会压垮系统
• 失败重试：单个任务失败不影响整体，可以自动重试
• 进度追踪：运营可以看到发送进度和状态

4.5 幂等性保证

网络抖动、服务重启可能导致重复发送。每封邮件需要有唯一标识，确保同一邮件不会重复出现在玩家邮箱中。

// 创建玩家邮件（幂等）
func (s *MailService) CreatePlayerMail(playerID, mailDefID int64) error {
    // 使用唯一约束：player_id + mail_def_id
    mailbox := &PlayerMailbox{
        PlayerID:  playerID,
        MailDefID: mailDefID,
        Status:    0,
    }
    
    // INSERT IGNORE 或 ON DUPLICATE KEY UPDATE
    err := s.db.Exec(`
        INSERT IGNORE INTO player_mailbox (player_id, mail_def_id, status, created_at)
        VALUES (?, ?, 0, ?)
    `, playerID, mailDefID, time.Now().Unix())
    
    return err
}

// 领取附件（幂等）
func (s *MailService) ClaimAttachments(playerID, mailID int64) ([]Attachment, error) {
    // 使用分布式锁防止并发领取
    lockKey := fmt.Sprintf("mail:claim:%d:%d", playerID, mailID)
    lock := s.locker.Acquire(lockKey, 10*time.Second)
    if lock == nil {
        return nil, errors.New("please retry")
    }
    defer lock.Release()
    
    // 检查是否已领取
    mailbox, err := s.getPlayerMail(playerID, mailID)
    if err != nil {
        return nil, err
    }
    
    if mailbox.Status == StatusClaimed {
        // 已领取，返回空（幂等）
        return nil, nil
    }
    
    // 获取邮件定义
    mailDef, err := s.GetMailDefinition(mailID)
    if err != nil {
        return nil, err
    }
    
    // 发放附件
    for _, att := range mailDef.Attachments {
        if err := s.inventory.AddItem(playerID, att.ItemID, att.Count); err != nil {
            return nil, err
        }
    }
    
    // 更新状态
    mailbox.Status = StatusClaimed
    mailbox.ClaimedAt = time.Now().Unix()
    s.updatePlayerMail(mailbox)
    
    return mailDef.Attachments, nil
}

五、邮件送达可靠性保障

5.1 什么是"送达"？

在游戏邮件系统中，"送达"有几个层次，每个层次都有流失：

送达率优化，就是要让更多玩家走完这个漏斗，减少每个环节的流失。

5.2 可靠性架构设计

// 发送邮件时先写入消息队列
func (s *MailService) SendMail(req *SendMailRequest) (int64, error) {
    // 1. 创建邮件定义
    mailDef := &MailDefinition{
        Type:        req.Type,
        Title:       req.Title,
        Content:     req.Content,
        Attachments: req.Attachments,
        Filter:      req.Filter,
        StartTime:   time.Now().Unix(),
        EndTime:     time.Now().Add(7 * 24 * time.Hour).Unix(),
    }
    
    if err := s.repo.CreateMailDefinition(mailDef); err != nil {
        return 0, err
    }
    
    // 2. 写入消息队列（持久化，保证不丢失）
    msg := &MailSendMessage{
        MailDefID: mailDef.ID,
        Type:      req.Type,
        Filter:    req.Filter,
    }
    
    if err := s.mq.Publish("mail.send", msg); err != nil {
        // 消息队列写入失败，回滚
        s.repo.DeleteMailDefinition(mailDef.ID)
        return 0, err
    }
    
    return mailDef.ID, nil
}

// 消息消费失败时的重试
type MailConsumer struct {
    maxRetry    int
    retryDelay  time.Duration
}

func (c *MailConsumer) HandleMessage(msg *MailSendMessage) error {
    var lastErr error
    
    for i := 0; i < c.maxRetry; i++ {
        err := c.processMessage(msg)
        if err == nil {
            return nil
        }
        
        lastErr = err
        log.Printf("mail send retry %d/%d: %v", i+1, c.maxRetry, err)
        
        // 指数退避
        time.Sleep(c.retryDelay * time.Duration(1<<i))
    }
    
    // 重试次数用尽，写入死信队列
    c.sendToDeadLetterQueue(msg, lastErr)
    return lastErr
}

// 监控指标
type MailMetrics struct {
    // 发送相关
    SendTotal      prometheus.Counter
    SendSuccess    prometheus.Counter
    SendFailed     prometheus.Counter
    SendLatency    prometheus.Histogram
    
    // 领取相关
    ClaimTotal     prometheus.Counter
    ClaimSuccess   prometheus.Counter
    ClaimFailed    prometheus.Counter
    
    // 队列相关
    QueueSize      prometheus.Gauge
    QueueLag       prometheus.Gauge
}

// 关键告警规则
var alertRules = []AlertRule{
    {
        Name:      "mail_send_failure_rate",
        Condition: "rate(mail_send_failed[5m]) / rate(mail_send_total[5m]) > 0.01",
        Severity:  "critical",
        Message:   "邮件发送失败率超过1%",
    },
    {
        Name:      "mail_queue_lag",
        Condition: "mail_queue_lag > 10000",
        Severity:  "warning",
        Message:   "邮件队列积压超过10000",
    },
    {
        Name:      "mail_claim_failure",
        Condition: "rate(mail_claim_failed[5m]) > 10",
        Severity:  "warning",
        Message:   "邮件领取失败频率异常",
    },
}

5.3 数据一致性保障

// 领取附件的分布式事务
func (s *MailService) ClaimWithTransaction(playerID, mailID int64) error {
    // 使用 Saga 模式
    tx := s.txManager.Begin()
    
    // Step 1: 锁定邮件
    mailbox, err := s.lockMail(tx, playerID, mailID)
    if err != nil {
        tx.Rollback()
        return err
    }
    
    // Step 2: 发放物品
    mailDef, _ := s.GetMailDefinition(mailID)
    for _, att := range mailDef.Attachments {
        if err := s.inventory.AddItemWithTx(tx, playerID, att.ItemID, att.Count); err != nil {
            tx.Rollback()
            return err
        }
    }
    
    // Step 3: 更新邮件状态
    if err := s.updateMailStatus(tx, mailbox, StatusClaimed); err != nil {
        tx.Rollback()
        return err
    }
    
    // Step 4: 记录领取日志
    if err := s.logClaim(tx, playerID, mailID, mailDef.Attachments); err != nil {
        tx.Rollback()
        return err
    }
    
    return tx.Commit()
}

万一事务失败后无法自动恢复，需要人工补偿机制：

// 领取记录表（用于对账和补偿）
type ClaimRecord struct {
    ID          int64         `json:"id"`
    PlayerID    int64         `json:"player_id"`
    MailID      int64         `json:"mail_id"`
    Attachments []Attachment  `json:"attachments"`
    Status      int           `json:"status"` // 0=待处理 1=成功 2=失败
    RetryCount  int           `json:"retry_count"`
    CreatedAt   int64         `json:"created_at"`
}

// 定时检查异常领取记录
func (s *MailService) CheckFailedClaims() {
    records, _ := s.repo.GetFailedClaimRecords()
    for _, record := range records {
        if record.RetryCount >= 3 {
            // 多次失败，发送告警
            s.alertService.Send("mail_claim_failed", record)
            continue
        }
        
        // 重试发放
        if err := s.retryClaim(record); err != nil {
            record.RetryCount++
            s.repo.UpdateClaimRecord(record)
        } else {
            record.Status = 1
            s.repo.UpdateClaimRecord(record)
        }
    }
}

5.4 提升展示率与阅读率

玩家收到邮件，但可能根本没注意到。如何提升展示率？

• 好：【奖励】您有未领取的周年庆礼包
• 差：关于游戏周年庆活动奖励发放的通知

5.5 数据分析与迭代

持续追踪邮件漏斗数据，发现问题并优化：

// 邮件漏斗统计
type MailFunnelStats struct {
    MailDefID    int64   `json:"mail_def_id"`
    SentCount    int     `json:"sent_count"`    // 发送量
    ViewCount    int     `json:"view_count"`    // 展示量
    OpenCount    int     `json:"open_count"`    // 打开量
    ClaimCount   int     `json:"claim_count"`   // 领取量
    ViewRate     float64 `json:"view_rate"`     // 展示率
    OpenRate     float64 `json:"open_rate"`     // 打开率
    ClaimRate    float64 `json:"claim_rate"`    // 领取率
}

// 计算漏斗数据
func (s *MailService) GetMailFunnelStats(mailDefID int64) (*MailFunnelStats, error) {
    stats := &MailFunnelStats{MailDefID: mailDefID}
    
    // 发送量（对于定向邮件）
    stats.SentCount = s.repo.GetSentCount(mailDefID)
    
    // 阅读量
    stats.OpenCount = s.repo.GetOpenCount(mailDefID)
    
    // 领取量
    stats.ClaimCount = s.repo.GetClaimCount(mailDefID)
    
    // 计算转化率
    if stats.SentCount > 0 {
        stats.OpenRate = float64(stats.OpenCount) / float64(stats.SentCount)
        stats.ClaimRate = float64(stats.ClaimCount) / float64(stats.SentCount)
    }
    
    return stats, nil
}

六、安全与防刷机制

6.1 常见风险

邮件系统涉及虚拟物品发放，是黑产的重点关注对象。

6.2 防护策略

// 领取行为风控检测
type ClaimRiskChecker struct {
    // 阈值配置
    MaxClaimsPerMinute    int // 每分钟最大领取次数
    MaxClaimsPerDay       int // 每天最大领取次数
    NewAccountGracePeriod int // 新账号观察期（天）
}

func (c *ClaimRiskChecker) CheckClaimRisk(playerID int64) error {
    // 1. 检查每分钟领取频率
    minuteCount := c.getClaimCount(playerID, time.Now().Add(-time.Minute))
    if minuteCount >= c.MaxClaimsPerMinute {
        return errors.New("claim too frequent")
    }
    
    // 2. 检查每日领取频率
    dayCount := c.getClaimCount(playerID, time.Now().Add(-24*time.Hour))
    if dayCount >= c.MaxClaimsPerDay {
        return errors.New("daily limit exceeded")
    }
    
    // 3. 检查账号状态
    player := c.getPlayer(playerID)
    if time.Since(time.Unix(player.CreatedAt, 0)) < time.Duration(c.NewAccountGracePeriod)*24*time.Hour {
        // 新账号，更严格的限制
        if dayCount >= 3 {
            return errors.New("new account limit")
        }
    }
    
    return nil
}

七、运营工具设计

7.1 简洁的创建界面

让运营同事能独立完成邮件发送，不需要技术介入。

7.2 预览与测试

发送前充分预览和测试，避免"发出去就收不回来"的尴尬。

• 在手机端模拟展示效果
• 检查变量替换是否正确
• 验证附件配置是否完整

7.3 发送管理

发送不是"发完就不管"，还需要持续管理。

• 取消待发送的邮件
• 撤回已发送但未领取的邮件
• 延长或缩短有效期

7.4 效果分析

发送完成后，提供数据看板，让运营了解效果。

• 送达数量、阅读数量、领取数量
• 各环节转化率
• 与历史邮件的效果对比

八、系统架构概览

8.1 整体架构

一个完整的游戏邮件系统，通常包含以下核心模块：

┌─────────────────────────────────────────────────────────────────┐
│                        运营管理后台                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐           │
│  │ 邮件创建 │ │ 模板管理 │ │ 发送管理 │ │ 效果分析 │           │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘           │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                        API 服务层                                │
│  ┌──────────────┐ ┌──────────────┐ ┌──────────────┐            │
│  │ 邮件查询 API │ │ 邮件发送 API │ │ 附件领取 API │            │
│  └──────────────┘ └──────────────┘ └──────────────┘            │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                        核心业务层                                │
│  ┌──────────────┐ ┌──────────────┐ ┌──────────────┐            │
│  │ 筛选匹配服务 │ │ 模板渲染服务 │ │ 附件发放服务 │            │
│  └──────────────┘ └──────────────┘ └──────────────┘            │
└───────────────────────────┬─────────────────────────────────────┘
                            │
            ┌───────────────┼───────────────┐
            ▼               ▼               ▼
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│   存储层     │   │  任务调度层  │   │   缓存层     │
│  ┌────────┐  │   │  ┌────────┐  │   │  ┌────────┐  │
│  │ MySQL  │  │   │  │ Redis  │  │   │  │ Redis  │  │
│  └────────┘  │   │  │ Queue  │  │   │  │ Cache  │  │
└──────────────┘   └──────────────┘   └──────────────┘

8.2 核心数据模型

8.3 与其他系统的交互

邮件系统不是孤立的，需要与多个系统协作：

九、总结

游戏邮件系统，表面看是"发个通知"，实际上是一个涉及存储、计算、推送、安全、数据分析的复杂系统。

1. 延迟写入： 全服邮件不等于为每个玩家存一份，聪明地利用规则和动态计算，大幅降低存储成本

1. 模板化： 标准化提升效率，个性化保留灵活度，同时支持效果追踪和持续优化

1. 批量处理： 任务队列、分片并行、异步化，应对大规模发送的挑战

1. 送达优化： 从技术送达走向行为转化，关注完整的漏斗，而不只是"发出去"

1. 安全防护： 服务端校验、唯一性约束、异常监控，保护虚拟资产安全

• 让运营能快速创建和发送邮件，不需要技术介入
• 让玩家第一时间看到有价值的邮件，并顺畅地完成领取
• 让技术团队不担心性能和安全，系统稳定可靠
• 让管理层能看到清晰的效果数据，支持数据驱动决策

邮件系统是游戏运营的基础设施。它不像战斗系统那样炫酷，不像社交系统那样热闹，但它默默支撑着日常运营的方方面面。投入资源把它做好，回报是长期且可观的。

在设计和评估邮件系统时，可以参考以下清单：

• [ ] 支持全服邮件、定向邮件、个人邮件、定时邮件
• [ ] 支持多种类型的附件（货币、道具、外观等）
• [ ] 支持灵活的筛选条件组合
• [ ] 支持邮件模板管理和版本控制
• [ ] 支持 A/B 测试

• [ ] 全服邮件采用延迟写入策略
• [ ] 支持任务队列异步处理
• [ ] 数据库索引合理，查询效率高
• [ ] 支持缓存热门邮件内容

• [ ] 消息队列持久化，保证不丢失
• [ ] 失败自动重试机制
• [ ] 死信队列处理异常消息
• [ ] 分布式事务保证数据一致性
• [ ] 补偿机制处理异常情况

• [ ] 服务端校验所有领取操作
• [ ] 数据库层面唯一性约束
• [ ] 完整的操作日志记录
• [ ] 异常领取行为监控
• [ ] 风控系统联动

• [ ] 简洁直观的创建界面
• [ ] 发送前预览和测试功能
• [ ] 实时进度反馈
• [ ] 完整的效果数据看板
• [ ] 支持撤回和修改

• [ ] 关键指标监控
• [ ] 告警规则配置
• [ ] 链路追踪支持
• [ ] 日志完整记录

这份清单可以帮助你快速评估现有系统的完善程度，或指导新系统的设计。