创游世界广播命名规范与最佳实践
一句话摘要
本文档整理创游世界中广播的命名规范与使用最佳实践，帮助你建立清晰的广播命名体系，避免项目做大后广播命名混乱、难以维护的问题。
适合谁阅读
- 项目越做越乱，想整理广播命名的创作者
- 想学习如何正确使用广播解耦系统的开发者
- 需要建立团队协作规范的进阶用户
你将学到什么
- 广播命名的基本原则
- 不同场景的命名建议
- 广播使用的常见误区
- 解耦设计的最佳实践
- 项目广播架构建议
💡 如果你想快速查找广播用法，请查看：创游世界广播使用速查卡
为什么要关注广播命名
广播是创游世界中常用的跨对象通信机制。如果命名混乱：
- 很难追踪「谁发了什么广播」
- 重构时容易漏改、错改
- 多人协作时沟通成本飙升
- 排查问题无从下手
好的广播命名 = 项目可维护性的基石。
📚 相关阅读：广播机制深度解析 - 广播原理详解
广播命名基本原则
原则一：表达「事件」或「意图」，而非「实现」
| ✅ 推荐命名 | ❌ 不推荐命名 |
|---|---|
| 道具_获得_玩家 | 扣钱加道具更新UI |
| 刷新_商店界面 | 读取金币读取道具改值 |
| 敌人_死亡_通知 | 发送广播1 |
| 请求_打开背包 | 打开那个界面 |
| 任务_完成_通知 | 刷新任务 |
好的广播名 = 一句话能说清楚「发生了什么」或「想要做什么」
原则二：使用统一的分隔符
推荐使用下划线_作为分隔符：
动作_对象_类型
事件_对象_状态
请求_目标_操作
通知_对象_内容原则三：同类型广播使用统一的命名模式
如果你的项目有：
- 道具获得：
道具_获得 - 道具使用：
道具_使用 - 道具丢弃：
道具_丢弃
那这三个广播就应该保持一致的命名风格，而不是：
道具_获得使用道具广播discard_item
场景化命名建议
UI 交互类广播
| 场景 | 推荐命名 | 说明 |
|---|---|---|
| 玩家点击购买按钮 | 请求_购买_道具 | UI发给地图 |
| 玩家点击使用道具 | 请求_使用_道具 | UI发给地图 |
| 玩家点击对话选项 | 对话_选项_选择 | UI发给对话系统 |
| 玩家关闭界面 | 请求_关闭_界面 | UI发给地图 |
📚 相关阅读：UI系统与切换机制解析 - UI系统详解
状态变化类广播
| 场景 | 推荐命名 | 说明 |
|---|---|---|
| 玩家获得道具 | 道具_获得_玩家 | 地图发给所有需要知道的 |
| 玩家消耗金币 | 金币_消耗_玩家 | 地图发给UI |
| 敌人死亡 | 敌人_死亡_通知 | 物体发给地图 |
| 任务完成 | 任务_完成_通知 | 任务系统发给UI |
📚 相关阅读：创游世界战斗系统设计入门 - 战斗系统
UI 刷新类广播
| 场景 | 推荐命名 | 说明 |
|---|---|---|
| 刷新金币显示 | 刷新_界面_金币 | 地图发给UI |
| 刷新背包显示 | 刷新_界面_背包 | 地图发给UI |
| 刷新生命条 | 刷新_界面_生命 | 地图发给UI |
| 刷新任务列表 | 刷新_界面_任务 | 任务系统发给UI |
📚 相关阅读：创游世界UI数据同步架构 - UI同步架构
流程控制类广播
| 场景 | 推荐命名 | 说明 |
|---|---|---|
| 开始战斗 | 战斗_开始_通知 | 地图发给所有战斗参与者 |
| 战斗结束 | 战斗_结束_通知 | 地图发给所有 |
| 进入下一波 | 波次_进入_N | 地图发给怪物生成器 |
| 游戏胜利 | 游戏_胜利_通知 | 系统发给全局 |
📚 相关阅读：创游世界商店系统实战设计指南 - 商店系统
广播使用误区与正确做法
误区一：一个广播做太多事
❌ 错误做法：
发送广播"购买道具"
→ 扣钱
→ 加道具
→ 刷新背包
→ 刷新金币
→ 播放音效
这个广播承担了太多语义，广播名称也过于笼统。✅ 正确做法：
UI 发送广播 "请求_购买_道具"
↓
地图脚本处理：扣钱、判断库存、扣除金币
↓
地图脚本发送广播 "道具_获得_玩家"（如果购买成功）
↓
收到 "道具_获得_玩家" 后：
- 背包脚本处理道具入库
- 音效脚本播放获得音效
UI 收到 "道具_获得_玩家" 后：
- 刷新背包显示
- 刷新金币显示分解后的广播职责更清晰，排查问题更容易。
误区二：广播里携带太多参数
❌ 不推荐：
发送广播 "道具获得"，参数：道具ID、道具数量、金币变化、当前金币余额...
→ 广播携带太多数据，导致广播职责不清晰
→ 参数一多，监听者不知道该用哪个
→ 后续增加新参数时要改所有发送和接收的地方✅ 推荐：
发送广播 "请求_购买_道具"，参数：道具ID、数量
↓
地图处理后，发送 "道具_获得_玩家"，参数：道具ID、数量
↓
如果金币不足，发送 "请求_失败_金币不足"
每次广播只携带必要的、最小化的参数。📚 相关阅读：脚本作用域与数据流深度研究 - 数据分层
误区三：命名不一致
| 同一事件出现多种命名 | 问题 |
|---|---|
道具_获得 | 部分地方用 |
获得道具 | 部分地方用 |
item_get | 混用英文 |
收到道具通知 | 部分地方用 |
后果：广播追踪困难，不知道哪些地方在监听、哪些地方在发送。
建议：在项目初期就制定广播命名表，所有人统一使用。
📚 相关阅读：创游世界项目维护与代码组织规范 - 项目维护
项目广播架构建议
推荐分层架构
┌─────────────────────────────────────────┐
│ UI 层 │
│ 负责：显示、接收输入、发送请求广播 │
└──────────────────┬──────────────────────┘
│ 发送请求广播
↓
┌─────────────────────────────────────────┐
│ 地图层 │
│ 负责：真值处理、公共逻辑、状态管理 │
│ 收到请求 → 处理 → 发送状态变化广播 │
└──────────────────┬──────────────────────┘
│ 发送状态变化广播
┌───────┴───────┐
↓ ↓
┌─────────────────┐ ┌─────────────────┐
│ UI 层 │ │ 物体层 │
│ 刷新显示 │ │ 各自处理逻辑 │
└─────────────────┘ └─────────────────┘📚 相关阅读：创游世界广播驱动项目结构实战 - 广播架构实战
广播流向原则
| 方向 | 广播类型 | 示例 |
|---|---|---|
| UI → 地图 | 请求/意图类 | 请求_购买、请求_使用 |
| 地图 → UI | 刷新/通知类 | 刷新_界面、状态_更新 |
| 地图 → 物体 | 指令/事件类 | 敌人_死亡、波次_进入 |
| 物体 → 地图 | 事件上报类 | 道具_拾取、伤害_造成 |
命名规范参考表
前缀规范
| 前缀 | 用途 | 示例 |
|---|---|---|
请求_ | UI/对象向地图发起的操作请求 | 请求_购买、请求_打开 |
通知_ | 系统向多方告知事件 | 通知_游戏开始、通知_切换地图 |
刷新_ | 通知UI刷新显示 | 刷新_界面_金币、刷新_背包 |
指令_ | 指令性广播，让接收方执行动作 | 指令_播放动画、指令_生成怪物 |
状态_ | 状态变化通知 | 状态_死亡、状态_激活 |
常用后缀
| 后缀 | 用途 | 示例 |
|---|---|---|
_玩家 | 广播目标是玩家相关 | 道具_获得_玩家、金币_变化_玩家 |
_敌人 | 广播目标是敌人相关 | 敌人_死亡_通知、敌人_受伤_通知 |
_界面 | 广播目标是UI界面 | 刷新_界面_背包、刷新_界面_任务 |
_地图 | 广播目标是地图层 | 地图_切换_通知、地图_初始化 |
📚 相关阅读：创游世界新手避坑完全指南 - 广播避坑
常见问题
Q：一个功能应该用几个广播？
A： 取决于功能复杂度。一个简单的「购买道具」功能可能需要：
请求_购买_道具（UI → 地图）道具_获得_玩家（地图 → 相关系统）刷新_界面_金币（地图 → UI）刷新_界面_背包（地图 → UI）
关键原则是「广播表达意图，不表达实现」。
📚 相关阅读：常见问题与避坑指南 - 问题解决
Q：广播名称太长怎么办？
A： 可以适当简化，但保持语义完整：
- 复杂项目：
道具_获得_玩家_通知 - 中等项目：
道具_获得_通知 - 简单项目：
获得道具
但不要简化为「广播1」「按钮1」这样完全无意义的名称。
Q：多人协作时怎么统一广播命名？
A： 建议：
- 在项目初期制定《广播命名表》
- 所有广播命名必须查表，不允许自创
- 新增广播需要登记到表中
- 定期 review 广播使用情况，合并重复命名
📚 相关阅读：创游世界项目维护与代码组织规范 - 项目维护
相关页面
脚本系统
- 广播驱动项目结构实战 - 广播架构实战
- 创游世界UI数据同步架构 - UI同步架构
- 脚本作用域与数据流深度研究 - 数据分层
- 创游世界战斗系统设计入门 - 战斗系统
- 创游世界背包与货币系统设计入门 - 背包货币
教程资料
- 广播机制深度解析 - 广播原理详解
- 创游世界广播使用速查卡 - 广播速查
- UI系统与切换机制解析 - UI系统详解
- 创游世界新手避坑完全指南 - 避坑指南
- 常见问题与避坑指南 - 问题解决
项目设计
- 创游世界商店系统实战设计指南 - 商店系统
- 创游世界项目维护与代码组织规范 - 项目维护
导航入口
- 教程资料导航 - 教程资料总入口
- 创游世界知识库总导航 - 知识库总导航
- 新手阅读路线 - 学习路线导航
待验证问题
以下问题需要进一步验证：
| 问题 | 状态 | 验证方向 |
|---|---|---|
| 广播参数数量是否有性能影响 | 🔄 待验证 | 需要压测确认 |
| 广播嵌套调用是否有深度限制 | 🔄 待验证 | 需要实际测试 |
📝 说明：广播命名规范已稳定，进阶行为属于研究范畴。
后续优化方向
- [ ] 补充更多游戏类型的广播命名示例
- [ ] 添加典型项目结构的广播命名模板
- [ ] 补充团队协作时的广播管理规范
最后更新：2026-06-10维护者：Azek431