子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学"明白"，也用"到位"
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
引言
当你把一个鸿蒙游戏 Demo 跑起来之后，很快就会遇到三个"产品化问题"：
怎么赚钱？（支付）
怎么留住用户？（排行榜）
怎么让用户传播？（社交）在 HarmonyOS 里，这三件事和传统手游并不完全一样。
很多人会直接照搬手游方案，结果就是：
- 接入复杂
- 体验割裂
- 审核困难
一、整体架构设计
在写具体功能之前，先做一件很重要的事：
把这些能力"服务化"
推荐结构
entry
├─ pages
├─ components
├─ services
│ ├─ payment
│ ├─ leaderboard
│ └─ social
├─ models
└─ utils核心原则：
UI 不直接调用能力，而是通过 Service 层
二、支付接入
1、设计 PaymentService
ts
// services/payment/PaymentService.ets
export class PaymentService {
async createOrder(productId: string) {
// 调用后端生成订单
return {
orderId: "123",
amount: 6.0
}
}
async pay(order) {
// 调用系统支付能力
return {
success: true
}
}
}2、页面调用
ts
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、关键点
不要在前端直接控制金额
ts
// ❌ 错误
amount = 1.0正确：
金额由后端控制支付结果必须校验
ts
// 后端验证订单本质：
前端只是触发，核心逻辑在服务端
三、排行榜
1、设计 LeaderboardService
ts
// 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、页面展示
ts
@State list: any[] = []
async loadRank() {
this.list = await leaderboardService.getTopList()
}3、组件展示
ts
ForEach(this.list, (item, index) => {
Text(`${index + 1}. ${item.name} - ${item.score}`)
})4、关键优化点
排行榜分层
全球榜
好友榜
本地榜缓存机制
ts
cache.get("leaderboard")防作弊
ts
// 后端校验分数本质：
排行榜不是 UI，而是数据系统
四、社交系统
1、基础能力：分享
ts
// services/social/SocialService.ets
export class SocialService {
share(text: string) {
// 调用系统分享能力
}
}页面调用
ts
socialService.share(`我拿了 ${this.score} 分！`)这是最简单也是最有效的增长手段。
2、好友系统
数据结构
ts
interface Friend {
id: string
name: string
}服务
ts
async getFriends() {
return await fetch("/api/friends")
}3、互动玩法
比"功能"更重要的是"玩法"。
示例
- 分享成绩 → 挑战好友
- 好友排行榜
- AI 生成战绩卡片
示例代码
ts
const card = await ai.generateShareCard({
score: this.score
})
socialService.share(card)本质：
社交不是"功能"，而是"传播机制"
五、AI 在三大模块中的作用
1、AI + 支付
ts
agent.run("帮我买一个最划算的礼包")AI 推荐商品。
2、AI + 排行榜
ts
agent.run("我怎么才能上榜？")AI 给出策略。
3、AI + 社交
ts
const text = await ai.generateText({
score: this.score
})自动生成分享文案。
本质：
AI 提升"转化率"和"互动性"
六、多设备场景下的特殊设计
在 HarmonyOS 中，还要考虑：
1、支付设备选择
手机支付
TV 显示示例
ts
if (device === 'tv') {
showQRCode()
}2、排行榜展示分离
手机 → 查看
TV → 展示3、社交入口统一
所有设备共享用户关系本质：
能力可以跨设备调用
七、常见错误
1、把支付写死在 UI：应该放 Service。
2、排行榜只做前端排序：必须后端控制。
3、社交只做"分享按钮"：缺少玩法设计。
4、忽略多设备场景：导致体验割裂。
总结
鸿蒙游戏中的三大核心能力：
支付（变现）
排行榜（留存）
社交（增长）在 HarmonyOS 中，正确的做法是：
1、服务化设计
PaymentService
LeaderboardService
SocialService2、数据驱动
排行榜 / 订单 → 后端控制3、玩法优先
社交 ≠ 功能4、多端协同
手机 / TV / 平板 联动最后一句话总结：
在鸿蒙游戏里，支付、排行榜、社交，不只是"功能模块"，而是"游戏系统的一部分"。