按品类回看问题
品类是读者最顺手的入口：提起卡牌、MOBA、SLG 或者放置类，脑中立刻有具体的产品画面。但品类也是最容易误用的标签，很多人想从“这是什么品类”直接推出“该用什么架构”，中间跳过了真正起作用的那一环——这个品类把系统压力集中在了哪些问题上。这一页按常见品类回看知识库，目的不是给品类贴架构答案，而是提醒读者同一品类会同时在多个目录里产生问题切面。
回看的基本方法
比较有效的回看路径，是先问两个比品类更底层的问题：
- 玩家的关键状态以什么为单位生灭：一局、一个账号、一个世界，还是一次会话。
- 系统最贵的故障会落在哪：判罚争议、资产错误、开不了局，还是活动事故。
这两个答案基本决定了该重点回看哪些目录。品类名词只负责唤起直觉，真正的技术压力分布要靠这两个问题落地。同一品类换一个平台、换一种商业化模式，答案就会明显移动，所以下面的每个方向都值得带着自己项目的这两个答案来对照，而不是按图索骥。下面按常见方向逐一展开，每个方向给出的都是该品类在知识库各目录里的主要切面，而不是完整清单。
房间制品类的切面
麻将、斗地主、桌球、派对游戏这类产品，主玩法在一局内闭合，局外只保留结果和资产。它们看起来简单，但问题切面并不少：
- 同步与战斗：结算准确性、断线重连、托管与超时代打，是这一品类最受关注的公平性问题。
- 数据建模：局外资产、战绩、段位的权威归属，结算链路上临时状态和长期资产的边界。
- 通用服务：匹配质量、好友邀请、观战和回放，往往决定产品寿命。
- 平台 SDK：小游戏渠道的登录、分享和支付适配，常常反过来影响客户端选型。
- 可观测性：对局异常的定位和争议取证，直接关系客服成本。
房间制品类最容易出的工程事故，往往不是“做不出玩法”，而是结算和重连这类看似边角的链路不稳。
强实时对战品类的切面
MOBA、FPS、格斗、竞速类产品的第一性问题，是延迟、抖动和作弊直接吃掉公平性：
- 同步与战斗：帧同步还是状态同步、预测与和解、服务端裁决时机，几乎决定整个架构。
- 执行模型：固定 Tick 的推进、补帧与追帧预算、单帧耗时控制。
- 网络接入：传输层选择、弱网优化、包频与合包策略。
- 可观测性：帧耗时分布、帧差、输入延迟的量化，没有这些就没有调优依据。
这一品类的读者回看主线时，值得把同步与执行模型两条线对照着读，它们共同构成公平性的底座。
持续在线品类的切面
MMO、开放世界、大世界社交类产品的状态长期存活，复杂度随内容持续累积：
- 服务拆分：跨服玩法、场景迁移、热点治理，是这类项目绕不开的分布式课题。
- 数据建模：世界状态、玩家上下文、分区与合服时的数据结构弹性。
- 执行模型：AOI 与广播成本、大数量实体的调度。
- 容量扩缩专题：开服放量、跨服流量、长线增长下的扩容路径。
- 版本发布：不停服更新、多端共存、长周期内容更替的发布纪律。
这类项目的技术债有个特点：单点看都不严重，叠在世界模型上几年后开始互相放大，回看时值得按“什么会随时间恶化”来排序。
长线成长品类的切面
卡牌、SLG、放置与模拟经营类产品的重心不在局内对抗，而在周期、资产和节奏：
- 运营与商业化：活动框架、付费链路、生命周期管理是产品主体而不是附属。
- 配置管线专题：数值表、活动配置、校验与发布流程，直接决定迭代速度。
- 数据建模：成长资产、抽卡记录、订单与补偿的审计能力。
- 版本发布：多节奏变更的共存、热修复窗口、回滚安全。
- 安全与风控：套利、刷单、工作室对经济系统的侵蚀。
这一品类常见的误判是把技术投入全部押在玩法实现上，结果长线运营期真正消耗团队的却是活动链路和配置治理。
平台生态品类的切面
小游戏、超休闲以及任何重度依赖渠道分发的产品，平台约束会重塑技术形态：
- 平台 SDK：登录、支付、广告、社交分享的接入形态与审核适配。
- 版本发布：包体控制、多渠道打包、平台审核节奏对发布窗口的挤压。
- 安全与风控：平台侧规则与自身风控的衔接。
- 运营与商业化：广告变现链路、跨平台数据口径。
这类产品常被低估的一点是：平台约束往往反过来决定客户端引擎和包结构，选型阶段的回看顺序应该是平台先行。
同一品类内部的差异往往更大
按品类回看时有一层容易被忽略的提醒：品类内部的工程差异，常常大过品类之间的差异。同是卡牌，实时的对战卡牌和纯回合的养成卡牌几乎是两个技术物种；同是休闲游戏，接了重度广告变现的和纯内购的，商业化链路的复杂度天差地别。造成差异的主要变量通常是：
- 平台与渠道：小游戏平台、原生多端、海外多渠道，各自的接入和发布压力不同。
- 商业化模式：内购、广告、订阅混搭的程度，直接改变运营和风控的权重。
- 运营节奏：赛季制、版本制还是长草期运营，决定了配置管线和发布纪律的形态。
所以品类回看给出的只是第一层索引，落到自己项目时，还要回到问题模型里用共享状态和资产复杂度重新校准一次。
常见误区
- 把品类页当架构模板，觉得选定品类就等于选定了技术方案。
- 只看自己品类相关的内容，忽略了相邻品类里同构的问题切面。
- 用品类名词代替问题分析，跳过状态生灭和最贵故障这两个根本问题。
- 忽略品类内部差异，拿别的产品的做法直接套在自己的运营形态上。
- 回看变成一次性浏览，没有带着当前项目的具体问题去对照。
品类回看的价值，在于让熟悉的产品语境成为进入技术问题的门。门推开了就该往里走：真正决定架构的从来不是品类标签，而是标签背后那些可以逐一验证的问题。