子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

当你把一个鸿蒙游戏 Demo 跑起来之后，很快就会遇到三个“产品化问题”：

怎么赚钱？（支付）
怎么留住用户？（排行榜）
怎么让用户传播？（社交）

在 HarmonyOS 里，这三件事和传统手游并不完全一样。

很多人会直接照搬手游方案，结果就是：

• 接入复杂
• 体验割裂
• 审核困难

一、整体架构设计

在写具体功能之前，先做一件很重要的事：

把这些能力“服务化”

推荐结构

entry
 ├─ pages
 ├─ components
 ├─ services
 │   ├─ payment
 │   ├─ leaderboard
 │   └─ social
 ├─ models
 └─ utils

核心原则：

UI 不直接调用能力，而是通过 Service 层

二、支付接入

1、设计 PaymentService

// services/payment/PaymentService.ets
export class PaymentService {

  async createOrder(productId: string) {
    // 调用后端生成订单
    return {
      orderId: "123",
      amount: 6.0
    }
  }

  async pay(order) {
    // 调用系统支付能力
    return {
      success: true
    }
  }

}

2、页面调用

const paymentService = new PaymentService()

async buyItem() {
  const order = await paymentService.createOrder("coin_pack")

  const result = await paymentService.pay(order)

  if (result.success) {
    this.addCoins()
  }
}

3、关键点

不要在前端直接控制金额

// ❌ 错误
amount = 1.0

正确：

金额由后端控制

支付结果必须校验

// 后端验证订单

本质：

前端只是触发，核心逻辑在服务端

三、排行榜

1、设计 LeaderboardService

// services/leaderboard/LeaderboardService.ets
export class LeaderboardService {

  async submitScore(score: number) {
    await fetch("/api/leaderboard/submit", {
      method: "POST",
      body: JSON.stringify({ score })
    })
  }

  async getTopList() {
    const res = await fetch("/api/leaderboard/top")
    return await res.json()
  }

}

2、页面展示

@State list: any[] = []

async loadRank() {
  this.list = await leaderboardService.getTopList()
}

3、组件展示

ForEach(this.list, (item, index) => {
  Text(`${index + 1}. ${item.name} - ${item.score}`)
})

4、关键优化点

排行榜分层

全球榜
好友榜
本地榜

缓存机制

cache.get("leaderboard")

防作弊

// 后端校验分数

本质：

排行榜不是 UI，而是数据系统

四、社交系统

1、基础能力：分享

// services/social/SocialService.ets
export class SocialService {

  share(text: string) {
    // 调用系统分享能力
  }

}

页面调用

socialService.share(`我拿了 ${this.score} 分！`)

这是最简单也是最有效的增长手段。

2、好友系统

数据结构

interface Friend {
  id: string
  name: string
}

服务

async getFriends() {
  return await fetch("/api/friends")
}

3、互动玩法

比“功能”更重要的是“玩法”。

示例

• 分享成绩 → 挑战好友
• 好友排行榜
• AI 生成战绩卡片

示例代码

const card = await ai.generateShareCard({
  score: this.score
})
socialService.share(card)

本质：

社交不是“功能”，而是“传播机制”

五、AI 在三大模块中的作用

1、AI + 支付

agent.run("帮我买一个最划算的礼包")

AI 推荐商品。

2、AI + 排行榜

agent.run("我怎么才能上榜？")

AI 给出策略。

3、AI + 社交

const text = await ai.generateText({
  score: this.score
})

自动生成分享文案。

本质：

AI 提升“转化率”和“互动性”

六、多设备场景下的特殊设计

在 HarmonyOS 中，还要考虑：

1、支付设备选择

手机支付
TV 显示

示例

if (device === 'tv') {
  showQRCode()
}

2、排行榜展示分离

手机 → 查看
TV → 展示

3、社交入口统一

所有设备共享用户关系

本质：

能力可以跨设备调用

七、常见错误

1、把支付写死在 UI：应该放 Service。

2、排行榜只做前端排序：必须后端控制。

3、社交只做“分享按钮”：缺少玩法设计。

4、忽略多设备场景：导致体验割裂。

总结

鸿蒙游戏中的三大核心能力：

支付（变现）
排行榜（留存）
社交（增长）

在 HarmonyOS 中，正确的做法是：

1、服务化设计

PaymentService
LeaderboardService
SocialService

2、数据驱动

排行榜 / 订单 → 后端控制

3、玩法优先

社交 ≠ 功能

4、多端协同

手机 / TV / 平板 联动

最后一句话总结：

在鸿蒙游戏里，支付、排行榜、社交，不只是“功能模块”，而是“游戏系统的一部分”。