企业官网建设流程全解析

GameRoom：匹配与游戏路由

一、GameRoom概述

GameRoom是NearPlay从社交发现到游戏互动的关键桥梁。当用户在游戏列表中选择一个游戏后，先进入GameRoom进行玩家匹配，匹配完成后再跳转到具体游戏页面。GameRoom不仅负责匹配，还提供位置共享请求机制——游戏结束后玩家可以线下见面，真正实现Near加Play的产品定位。

1.1 GameRoom产品定位与Near+Play闭环

NearPlay的产品名称本身就揭示了其核心价值主张——Near代表基于位置的附近发现，Play代表游戏社交互动。这两者的结合构成了一个完整的社交闭环：通过位置发现附近的人，通过游戏与这些人建立联系，再通过位置共享将线上联系延伸到线下交往。GameRoom在这个闭环中扮演着承上启下的枢纽角色——它连接了发现阶段和互动阶段，同时为线下延伸阶段提供了起点。

要理解GameRoom的产品定位，需要从用户旅程的视角审视整个NearPlay体验。用户打开应用后，首页展示附近的人——这是发现的起点。用户浏览游戏列表，对某个游戏产生兴趣——这是兴趣的激发。用户点击游戏卡片，进入GameRoom——这是从发现到互动的转折点。在GameRoom中，用户看到附近有谁在线，经过匹配找到游戏伙伴——这是社交连接的建立。匹配完成后进入游戏，在游戏互动中建立初步的社交印象——这是关系种子的播种。游戏结束后回到GameRoom，通过位置共享请求获取对方的大致位置，为线下见面创造条件——这是线上到线下的延伸。

GameRoom在这个旅程中的独特价值在于，它是唯一一个同时涉及Near和Play两个维度的地方。首页只涉及Near（发现附近的人），游戏页面只涉及Play（游戏互动），而GameRoom既需要Near的数据（附近在线用户的距离信息）来完成匹配，又需要Play的上下文（哪种游戏、需要多少人）来指导匹配逻辑，最后还通过位置共享请求将两个维度连接起来。这种三位一体的功能定位使得GameRoom成为整个应用中架构复杂度最高的页面之一。

从产品竞争的角度来看，GameRoom的设计是NearPlay与纯线上游戏平台的核心差异化点。市场上的大多数游戏匹配系统只关注Play维度——根据玩家的段位、经验值、在线状态进行匹配，不考虑玩家的地理位置。这种纯技能导向的匹配对于竞技游戏是合理的，但对于NearPlay这种以线下社交为目标的平台来说，距离因素的重要性远超技能因素。一个与你同城的初级玩家，比一个远在千里之外的高级玩家更有社交价值——因为只有前者才有可能在线下见面。GameRoom的匹配算法将距离作为首要排序维度，正是这种产品逻辑的体现。

GameRoom的位置共享请求机制更是NearPlay闭环设计的点睛之笔。它不是在游戏开始前就暴露位置信息——那样会造成隐私风险和社交压力；也不是在游戏中持续共享位置——那样会分散游戏注意力；而是在匹配完成后、游戏开始前这个特定时刻，提供了一个主动的位置共享邀请。这个时机的选择极其精妙：此时玩家已经通过匹配建立了初步的社交连接（我们即将一起玩），但尚未进入游戏状态（还没有互动经历），位置共享请求此时充当了一个社交信号——我愿意在线下见你。如果对方同意，这个信号为游戏结束后的线下延伸创造了条件；如果对方拒绝，也不影响即将开始的游戏体验——位置共享是完全可选的社交增强，而非游戏的必要条件。

从信息架构的角度来看，GameRoom占据了从游戏列表到具体游戏之间的过渡空间。这种过渡空间在用户体验设计中有着特殊的地位——它是用户从浏览模式进入沉浸模式的缓冲区。在游戏列表中，用户的注意力是分散的，他们在多个选项之间比较和犹豫；在具体游戏中，用户的注意力是集中的，他们全身心投入游戏互动。GameRoom作为过渡空间，需要完成从分散注意力到集中注意力的引导——匹配过程的等待时间恰好提供了这种引导，用户在等待中逐渐聚焦于即将开始的游戏，从浏览心态切换到参与心态。

1.2 GameRoom三大功能

1. 玩家匹配：从附近在线用户中逐步搜索，扩大半径直到找到足够玩家
2. 游戏路由：根据gameId跳转到对应游戏页面，传递GameRoomParams
3. 位置共享：匹配完成后，玩家可以申请获取对方大概定位，方便线下见面

1.3 GameRoom在应用中的位置

┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────────┐ │ Index │───▶│GameList │───▶│GameRoom │───▶│ WerewolfGame │ │ 游戏Tab │ │ 6游戏卡片│ │ 匹配+路由│ │ /ScriptKill/ │ └─────────┘ └─────────┘ └────┬─────┘ │ ...Game │ │ └──────────────┘ 位置共享请求 │ ┌─────▼─────┐ │ Location │ │ Dialog │ └───────────┘

二、匹配算法深度分析

2.1 逐步扩大半径的匹配策略

GameRoom的匹配算法采用了一种逐步扩大搜索半径的递进策略——从一公里开始搜索，每次扩大一公里，直到找到足够玩家或达到十公里上限。这种策略的设计考量不仅仅是为了找到玩家，更是为了优化匹配结果的质量——距离越近的玩家，线下社交的可能性越高。

从算法复杂度的角度来分析，逐步扩大策略的时间复杂度取决于nearbyOnlineUsers数组的大小和匹配半径的增长方式。当前实现在每一步中都对整个nearbyOnlineUsers数组执行filter操作，筛选距离小于等于当前半径的用户。如果附近在线用户总数为N、最大半径为R（当前为十），最坏情况下需要执行R次filter操作，每次遍历N个用户，总时间复杂度为O(N×R)。在当前Mock数据规模下（几十个用户），这个复杂度完全不是问题。但在真实场景中，如果某城市有数千名在线用户，可能需要优化为预先按距离排序、使用二分查找定位当前半径范围内的用户，将复杂度降低到O(N×logN + R×logN)。

逐步扩大半径的每一步之间设置了一点五秒的延迟。这个延迟看似浪费了匹配时间，实际上具有重要的用户体验价值。首先，它创造了一种搜索的仪式感——用户看到搜索范围从一公里逐步扩大到二公里、三公里，就像雷达扫描一样一圈圈向外扩展，这种视觉化的搜索过程比瞬间返回结果更有参与感。其次，延迟让用户有时间消化中间结果——在搜索过程中，已经匹配到的玩家实时出现在列表中，用户可以提前了解队友的情况。第三，延迟避免了短时间内大量UI更新导致的界面闪烁——如果瞬间完成全部搜索，用户可能来不及看清中间状态。

一点五秒这个具体数值的选取是基于人类感知心理学的研究。人的短期记忆持续约十五到三十秒，一点五秒的间隔确保了每个搜索步骤都在用户的短期记忆窗口内，用户能够感知到进度的连续变化。如果间隔过短（如零点一秒），搜索过程几乎瞬间完成，用户来不及体验搜索的仪式感；如果间隔过长（如五秒），用户会觉得搜索过程拖沓，产生等待焦虑。一点五秒恰好在这两个极端之间取得了平衡。

2.2 匹配终止条件与四人门槛

匹配算法有两个终止条件：匹配人数达到四人，或者搜索半径达到十公里上限。四人门槛的选择是六种游戏最低人数要求的最大公约数——狼人杀至少需要六人，但看谁反应快只需要两人，四人位于这个范围的中间偏下位置。选择四人而非更高门槛（如六人或八人）的考量是：在用户密度不高的区域（如非一线城市），严格要求六人以上才能开局可能导致长时间等待甚至永远无法开局，这会严重损害用户体验。四人门槛确保了在大多数场景下都能在合理时间内完成匹配。

然而，统一的四人门槛对不同游戏的影响是不均匀的。对于你画我猜和真心话大冒险，四人已经足够获得良好的游戏体验；但对于狼人杀，四人局意味着只有一狼一预言家一村民一猎人，角色配置极度简化，游戏深度大打折扣。未来的改进方向是根据gameId动态调整匹配人数要求——狼人杀匹配到六人以上才完成，看谁反应快两人即可开局。这需要在GameRoomParams中增加minPlayers和maxPlayers字段，由游戏列表页在跳转时传入。

十公里的搜索半径上限是一个重要的产品参数。它定义了NearPlay的Near概念的最大范围——超过十公里的用户即使在线也不会被匹配到。十公里的选择基于城市社交的实践经验：在一线城市，十公里半径覆盖了从市中心到近郊的范围，乘公共交通约需三十到六十分钟，这个通勤时间对于线下聚会是可接受的。在中小城市，十公里半径可能覆盖整个城市，搜索范围实际上是无限制的。未来可以根据城市等级和交通状况动态调整搜索半径上限——在北上广深可以放宽到十五甚至二十公里（地铁网络发达，通勤时间可控），在小城市可以收紧到五公里（超过五公里意味着出城，社交意愿急剧下降）。

2.3 doMatchStep递归匹配的工程实现

doMatchStep方法使用递归调用（通过setTimeout实现）而非循环来实现逐步匹配。这种实现方式的选择有着深层的工程考量。首先，ArkTS的单线程事件循环模型意味着任何长时间运行的循环都会阻塞UI渲染——如果用while循环逐步扩大半径，循环期间UI不会更新，用户看不到搜索进度的变化。setTimeout将每一步匹配放到事件循环的下一个迭代中执行，确保了UI有机会在步骤之间更新。其次，递归方式天然支持提前终止——当匹配人数达到门槛时直接return，不需要额外的循环退出标志。第三，递归方式让匹配过程可以被中断——如果未来添加取消匹配功能，只需clearTimeout取消下一个步骤的定时器即可。

doMatchStep中的数组更新使用了不可变模式——this.matchedUsers = [...this.matchedUsers, user]。这不仅是ArkTS @State刷新的要求，也是一种防御性编程的好习惯。不可变更新确保了ForEach渲染的数据源在渲染过程中不会发生变化，避免了列表渲染的不一致问题。但当前实现中有一个潜在的性能问题：在每次doMatchStep中，如果有多个新匹配的用户，会为每个用户都创建一次新的matchedUsers数组。更好的做法是先收集所有新匹配用户，然后一次性创建新数组。不过在当前的小数据规模下，这个优化不是必要的。

2.4 匹配算法的公平性与多样性

当前的匹配算法完全基于距离排序——距离越近的玩家优先被匹配。这种策略保证了匹配结果中最近的玩家占多数，有利于线下社交。但从游戏体验的角度看，距离不是唯一的重要维度。玩家之间的能力匹配、游戏偏好的一致性、以及社交兼容性都会影响游戏体验的质量。

理想的匹配算法应该在多个维度之间进行权衡。距离维度确保线下社交的可能性，能力维度确保游戏的竞争平衡，偏好维度确保游戏的趣味一致性，社交维度确保互动的和谐性。实现这种多维度匹配需要一个综合的匹配评分函数，将各个维度的匹配度加权求和为总评分。NearPlay的NearUser模型中已经预留了matchScore字段，这正是为未来多维度匹配准备的数据基础。MatchEngine可以根据用户的游戏偏好标签、历史游戏表现评分、以及距离信息，计算出一个综合匹配分数，GameRoom的匹配算法按匹配分数降序而非距离升序来选择玩家。

然而，多维度匹配引入了新的产品决策问题——各维度的权重如何设定？距离权重过高会退化为当前的距离优先模式，游戏偏好权重过高会匹配到远距离但游戏品味相似的用户，能力权重过高会匹配到实力相当但可能完全不想线下见面的对手。这些权重可能需要根据用户的行为数据动态调整——如果数据分析发现大多数用户在游戏结束后并不会线下见面，那么距离的权重就应该降低，匹配应该更注重游戏体验的质量。

三、位置共享请求与隐私设计

3.1 位置共享的产品价值与隐私边界

位置共享请求机制是GameRoom中最具产品创新性的功能，也是隐私设计挑战最大的功能。它的核心价值在于将线上游戏互动延伸到线下社交——当两名玩家通过游戏建立了初步印象后，位置共享为线下面见提供了可能性。但这种价值必须在不侵犯用户隐私的前提下实现。

隐私设计的核心原则是最小化披露——只共享用户明确同意共享的最少信息。当前实现中的位置共享并非精确的GPS定位，而是距离信息——对方只知道你在几公里外，不知道你的具体位置。这种大概定位的策略在隐私保护和社交便利之间取得了平衡：距离信息足以判断是否值得线下见面（两公里内很方便，十公里外可能太远），又不足以定位到具体的住址或工作地点。

位置共享请求的双向同意机制是隐私保护的第二道防线。发起者主动申请查看对方位置，对方可以同意或拒绝。这意味着位置信息的流动方向是单向的——只有被查看方需要同意，查看方不需要暴露自己的位置。未来可以考虑双向交换模式——双方同时同意共享位置，要么都看到对方位置，要么都看不到。这种对称的隐私设计更公平，避免了一个人看到对方位置却自己隐藏的尴尬局面。

位置共享请求的时序设计也蕴含着隐私考量——它只在匹配完成后才能发起，而非在匹配过程中或游戏开始前就暴露位置。这个时序确保了位置共享是匹配成功后的一种可选社交行为，而非匹配的前提条件。如果位置共享在匹配前就需要，那么位置信息就变成了一种筛选标准——距离近的用户更容易被匹配到，距离远的用户被边缘化。这虽然有利于线下社交，但会造成隐私压力——用户必须暴露位置才能参与匹配，这对于注重隐私的用户是一种排斥。

LocationShareRequest数据模型包含fromUserId、fromNickname、toUserId和status四个字段。fromUserId和fromNickname标识请求发起者，toUserId标识请求目标，status记录请求的当前状态（PENDING等待处理、ACCEPTED已同意、REJECTED已拒绝）。这个简洁的数据模型覆盖了位置共享请求的完整生命周期——创建时状态为PENDING，处理后变为ACCEPTED或REJECTED。状态的不可逆性（一旦同意或拒绝就不能撤销）是MVP阶段的简化设计，未来可能需要支持撤销同意——当用户改变主意时，可以收回位置共享授权。

3.2 LocationDialog处理对话框的交互设计

位置共享请求的处理通过LocationDialog对话框实现。对话框采用半透明遮罩覆盖整个页面，中央显示白色圆角面板，包含请求说明文字和拒绝、同意两个按钮。这种模态对话框设计强制用户做出选择——不处理请求就无法继续其他操作，确保了请求不会被忽略。

对话框的文案设计遵循了知情同意原则——用户在做出决定前必须清楚了解共享位置意味着什么。当前文案是对方请求查看你的大概定位，是否同意，其中大概定位这个措辞刻意弱化了定位的精确性，降低用户的心理负担。如果文案是对方请求查看你的精确位置，用户的同意意愿可能会显著降低。

同意和拒绝按钮的视觉设计采用了颜色引导策略——同意按钮为绿色（#4CAF50），拒绝按钮为灰色（#EEEEEE）。绿色在文化上象征着安全和认可，灰色则暗示着中立和犹豫。这种颜色引导在产品伦理上存在争议——它是否在操纵用户更倾向于同意？从用户体验的角度看，如果位置共享确实有助于产品核心价值（线下社交），那么适度的视觉引导是合理的。但按钮的位置安排应该保持中立——当前拒绝在左、同意在右的布局，符合从否定到肯定的阅读方向，不构成额外的引导。

3.3 位置共享请求的边界情况

当前实现中，位置共享请求只在本地创建，没有实际发送到对方设备。这意味着请求处理是对自己发出的请求的模拟处理——用户点击申请定位后，请求出现在自己的位置共享请求列表中，然后自己处理自己的请求。这在MVP阶段是可以接受的——主要验证了UI交互流程的完整性。但在真实场景中，请求需要通过WebSocket发送到对方设备，由对方决定是否同意。

另一个边界情况是同一用户可以被多次申请定位——当前实现没有对重复请求进行去重。如果用户对同一名玩家点击了多次申请定位，会创建多条PENDING状态的请求，每条都需要独立处理。未来的实现应该在requestLocation方法中检查是否已存在对该用户的未处理请求，避免重复申请。

四、gameRoutes路由映射设计

4.1 Record类型与路由表

gameRoutes使用Record<string, string>类型定义，将gameId字符串映射到游戏页面的URL字符串。这种映射表的设计模式在路由管理中极为常见——它将路由配置集中化，避免在业务逻辑中硬编码URL字符串。

Record类型在ArkTS中有特殊的意义。与JavaScript的普通对象不同，ArkTS的Record要求键和值都有明确的类型声明，这提供了编译时的类型安全——如果将非字符串值作为键或值使用，编译器会报错。但Record的键类型必须是string或number，不支持symbol或其他类型，因此gameId使用字符串’1’到’6’而非数字一到六。

六条路由映射的键值设计体现了业务语义到技术实现的对应关系。gameId’1’对应狼人杀页面，‘2’对应剧本杀，以此类推。这种数字编码虽然不如字符串编码（如’werewolf’、‘scriptkill’）直观，但更紧凑、传输效率更高，且与GameList中的GameItem.id字段格式一致。

4.2 enterGame路由跳转与兜底处理

enterGame方法中的路由查找使用了空值合并运算符——gameRoutes[this.gameId] ?? 'pages/Index'。当gameId不在映射表中时，默认跳转到首页。这种兜底处理防止了无效gameId导致的路由错误，但它也是一种信号——正常流程中不应该出现gameId无效的情况，如果走到了兜底逻辑，说明上游数据有问题。

路由跳转使用pushUrl而非replaceUrl，保留了GameRoom在路由栈中。这意味着游戏结束后用户可以通过back按钮回到GameRoom，重新查看匹配结果或发起位置共享请求。这种设计支持了一种常见的用户行为模式——游戏结束后回到GameRoom，与刚才一起玩的伙伴交流，然后决定是否线下见面。如果使用replaceUrl，游戏结束后back会跳过GameRoom直接回到游戏列表，中断了这条社交路径。

GameRoomParams的透传设计——从GameList传入GameRoom，再从GameRoom传入具体游戏页面——确保了每个页面都能获取完整的上下文信息。虽然当前实现中游戏页面只使用gameName来显示标题，但gameId在未来可以用于游戏内功能，如统计该游戏的胜率、推荐相似游戏等。透传而非重新获取的决策，避免了每个页面都从路由参数中重新解析信息的冗余。

五、匹配UI三态详解

5.1 初始状态——匹配前的期待

GameRoom的初始状态是用户进入页面后看到的第一个界面，它的设计目标是建立期待感和提供必要的信息。页面中心展示游戏名称（如狼人杀），下方是一行鼓励性文案开始匹配附近的玩家吧，再下方是匹配规则说明卡片，底部是开始匹配按钮。

匹配规则卡片使用浅橙色背景（#FFF3E0），与NearPlay的橙色主题色形成视觉呼应。四条规则清晰地解释了匹配逻辑：优先匹配距离相近的在线玩家、逐步扩大搜索范围、游戏中可申请获取对方大概定位、双方同意后共享位置方便线下交友。这四条规则不仅告知了匹配的技术机制，还传达了产品的社交理念——就近匹配、隐私保护、线下延伸。

规则卡片的背景色选择浅橙色而非白色或灰色，是基于视觉层级的考量。在浅灰色（#F5F5F5）的页面背景上，白色卡片缺乏视觉区分度，灰色卡片显得沉闷。浅橙色既与白色内容卡片有所区分，又与橙色按钮形成色系呼应，创造了视觉上的和谐感。这种细节层面的色彩设计看似微不足道，但它对用户的第一印象有着微妙而深远的影响。

开始匹配按钮的设计参数——八十百分比宽度、四十八像素高度、胶囊形状、橙色背景白色文字——构成了一个醒目的行动号召。八十百分比的宽度让按钮足够大以吸引注意力，又不至于宽到显得笨重。四十八像素的高度超过了推荐的四十四像素最小触摸目标尺寸，确保了良好的点击体验。胶囊形状（ButtonType.Capsule）圆润柔和，与方形的列表卡片形成视觉对比，暗示这是一个主要操作而非次要操作。

5.2 匹配中状态——搜索过程的仪式感

匹配中状态是GameRoom最动态的界面，它展示了搜索进度的实时变化。页面中心显示当前搜索状态文字（如正在搜索三公里内的在线玩家），下方是线性进度条，再下方是搜索范围数字和已匹配玩家列表。

进度条使用Progress组件的线性类型（ProgressType.Linear），当前半径与最大半径的比值即为进度百分比。一公里对应百分之十，十公里对应百分之百。这种映射让进度条的变化与搜索半径的增长同步——每扩大一公里，进度条增长百分之十。橙色进度条与主题色一致，在浅灰色背景上格外醒目。

已匹配玩家列表在匹配过程中实时增长，每匹配到一个新玩家就添加一行。列表项的设计简洁明了——头像emoji（二十八像素）、昵称（十六像素）、距离（十二像素灰色）。灰色背景（#F5F5F5）的卡片样式与匹配完成后的白色卡片形成对比，暗示这些匹配结果是暂时的——尚未确认的搜索结果。列表的高度固定为二百像素，当匹配玩家超过列表可视区域时自动滚动，不会占用过多页面空间。

匹配中状态的视觉节奏由每一点五秒一次的doMatchStep调用驱动。每次调用可能带来三种视觉变化：搜索范围数字加一、进度条增长、新玩家加入列表。这三种变化在同一时刻发生，创造了一种信息递增的节奏感。如果某一步没有匹配到新玩家，只有搜索范围和进度条变化，列表不变，这种信息的不对称增长让用户产生也许下一步就能匹配到人的期待。

5.3 匹配完成状态——社交连接的确认

匹配完成状态是GameRoom的信息密度最高的界面，它同时展示了匹配结果、位置共享请求和游戏入口。页面顶部是绿色完成提示文字（匹配完成已找到N名玩家），中间是详细玩家列表（每行包含头像、昵称、距离、在线状态、申请定位按钮），底部是位置共享请求区域和进入游戏按钮。

玩家列表的设计从匹配中状态升级为匹配完成状态——背景从灰色变为白色，增加了在线状态标识（灰色文字变绿色文字加在线标签），每行增加了申请定位按钮。这种视觉升级暗示了状态的转变——从暂时的搜索结果变为确认的游戏伙伴。申请定位按钮使用蓝色（#2196F3），与橙色的游戏品牌色形成区分，暗示这是一个独立的社交功能而非游戏功能。

进入游戏按钮的视觉设计——九十百分比宽度、四十八像素高度、橙色胶囊——与初始状态的开始匹配按钮保持了高度一致性。这种视觉一致性传达了一种隐含的叙事逻辑：开始匹配是旅程的起点，进入游戏是旅程的终点，两个按钮的相似设计暗示了这是同一条行动路径上的两个里程碑。

六、六种游戏人数差异

6.1 游戏人数需求对比

六种游戏对参与人数的要求差异极大，这是GameRoom匹配算法面临的核心业务挑战之一。

狼人杀是最严格的人数要求者。传统狼人杀至少需要六名玩家（两狼、一预言家、一女巫、两村民），八到十二人的配置才能提供丰富的角色组合和推理空间。少于六人时，角色过于单一，游戏失去了推理的深度——如果只有一狼一预言家，狼人几乎无处藏身。GameRoom统一的四人门槛对狼人杀来说远远不够，这意味着四人局的狼人杀将是一个极度简化的版本，游戏体验大打折扣。

剧本杀对人数的要求取决于具体剧本。单人剧本只需要一人，但多人剧本通常需要四到八人，且每个角色都有独特的剧情线，缺人会导致剧情不完整。剧本杀的人数要求是精确的——一个六人剧本就是需要六人，五人或七人都不行。这意味着GameRoom的匹配应该精确匹配到剧本要求的人数，而非使用统一的四人门槛。

谁是卧底是人数弹性较大的游戏。四人即可开局（一卧底三平民），六到八人能提供更好的推理体验。人数更多时，可以增加卧底数量来保持游戏平衡。这种弹性使得四人门槛对谁是卧底来说是基本可行的。

你画我猜对人数的要求最低——两人即可一人画一人猜，三人以上体验更好。四人门槛完全满足你画我猜的需求，甚至两人局在某些场景下也是可接受的。

真心话大冒险是人数弹性最大的游戏——两人即可互问真心话，十人以上的大群也完全没问题。人数越多，问题越多样，互动越丰富。四人门槛是真心话大冒险的最低舒适线。

看谁反应快是唯一一个两人即可获得完整体验的游戏——两个人抢拍比反应速度，规则简单直接。三人以上增加了竞争的多变性，但两人局已经足够有趣。四人门槛对看谁反应快来说反而偏高——如果强制等四人才能开局，可能错过两人即可开始的快速对局。

6.2 匹配偏好差异

不同游戏不仅对人数有不同要求，对匹配玩家的偏好也有差异。狼人杀偏好不认识的陌生人——如果玩家彼此认识，可能存在场外信息（如知道某人的微表情习惯），干扰游戏的公平性。剧本杀偏好愿意投入较长时间的玩家——一个完整剧本可能需要两到四个小时，中途退出会严重影响其他人的体验。谁是卧底偏好表达能力强的玩家——描述环节的质量直接影响推理的趣味性。你画我猜偏好创意型玩家——画技好不好不重要，但想法要有趣。真心话大冒险偏好愿意开放的玩家——如果大家都很保守，游戏会变得平淡无趣。看谁反应快偏好反应敏捷的玩家——这几乎是唯一一个对能力有明确要求的游戏。

当前的匹配算法完全没有考虑这些偏好差异，只按距离排序。未来的GameRoom可以在匹配界面增加偏好标签——如你是想认识新朋友还是和朋友一起玩、你希望玩多长时间、你更看重游戏竞技性还是社交趣味性。这些标签可以纳入匹配评分函数，使匹配结果更符合玩家的期望。

七、路由栈管理

7.1 三层线性路由栈

NearPlay的游戏入口路由栈由三层组成：Index（首页）→GameList（游戏列表）→GameRoom（匹配房间）→GamePage（具体游戏页面）。每一层都使用pushUrl跳转，形成了一个严格的线性栈结构。每一层都可以通过back按钮返回上一层，这是最直觉的导航模式。

线性路由栈的优势在于实现简单、行为可预测。用户永远可以通过连续按back回到首页，不会迷失在复杂的路由图中。但线性栈的缺点是缺乏快捷路径——如果用户在游戏结束后想直接玩另一个游戏，需要back三次回到首页再重新进入，操作路径冗长。

未来可以考虑实现游戏内的快捷切换——在GameOverUI中增加换一个游戏按钮，直接跳转到GameList页面，省去中间的back操作。这需要使用replaceUrl替换当前游戏页面，而非pushUrl叠加新页面，以控制路由栈的深度。

7.2 GameRoomParams的跨层传递

GameRoomParams在三层路由中透传——从GameList传入GameRoom，再从GameRoom传入GamePage。这种透传确保了每个页面都能获取完整的上下文信息，但也意味着GameRoomParams成为了一个跨页面的数据契约。如果未来GameRoomParams需要增加字段（如minPlayers、matchRadius等），所有消费这个参数的页面都需要同步更新。

透传的替代方案是使用AppStorage或PersistentStorage进行全局状态管理——GameList将选中的游戏信息写入全局存储，GameRoom和GamePage从全局存储读取。这种方案解耦了路由参数和业务数据，但引入了全局状态的复杂性和状态同步的潜在问题。在当前的MVP规模下，透传方案更为简单可靠。

八、nearbyOnlineUsers数据源

8.1 数据初始化与过滤

nearbyOnlineUsers在aboutToAppear中初始化，数据来源是MockUserData.getNearbyUsers，然后过滤出isOnline为true的用户。这个过滤确保了匹配算法只在在线用户中进行——离线用户无法参与游戏，匹配到也没有意义。

在线状态的判定在真实场景中远比布尔值过滤复杂。一个用户可能处于多种中间状态——刚刚上线但尚未完成初始化、在线但设置了免打扰模式、在线但正在另一局游戏中不可匹配。未来需要定义更细粒度的可用性状态，GameRoom只匹配当前可用的用户（在线且未在游戏中且未免打扰）。

8.2 NearUser数据结构的匹配用途

NearUser的distance字段是匹配算法的核心排序维度。所有在线用户按距离从近到远排列，匹配算法从最近的用户开始搜索，逐步扩大半径纳入更远的用户。这种距离优先的排序确保了匹配结果中近处用户占多数，最大化了线下社交的可能性。

matchScore和interests字段在当前GameRoom中未被使用——GameRoom只按距离匹配。这些字段是为MatchEngine准备的，MatchEngine会根据用户的兴趣标签匹配度和综合评分来计算matchScore。未来当GameRoom从单一距离匹配升级为多维度匹配时，这两个字段将发挥核心作用。

九、未来真实匹配服务设计

9.1 集中式匹配服务器架构

当前GameRoom的匹配逻辑完全在客户端执行——从本地Mock数据中筛选用户，通过setTimeout模拟搜索延迟。这种本地匹配在MVP阶段可以快速验证UI流程，但在真实场景中存在根本性的问题：客户端只能看到本地缓存的附近用户列表，无法知道这些用户当前是否真正在线、是否已被其他房间匹配、是否愿意参与该类型的游戏。

真实的匹配服务需要采用集中式服务器架构。匹配服务器维护全局的用户状态表——每个在线用户的位置、偏好、当前可用性、历史匹配记录。当客户端发起匹配请求时，服务器根据请求参数（游戏类型、人数要求、偏好标签）在全局状态表中搜索符合条件的用户，然后将匹配结果返回给发起请求的客户端。

集中式匹配的一个核心优势是避免重复匹配——同一个用户不能同时被匹配到两个房间。在客户端本地匹配的模式下，如果两个GameRoom同时匹配到同一个用户，该用户会出现在两个匹配列表中，导致两个房间都以为该用户会加入，但实际上他只能加入一个。集中式服务器通过原子性的匹配操作避免了这种竞态条件——一旦某个用户被匹配到一个房间，他的状态立即更新为已匹配，其他房间的搜索不会再纳入该用户。

9.2 匹配服务器的核心算法

匹配服务器的核心算法可以分为两个阶段：候选集筛选和最优组合选择。候选集筛选阶段根据硬性条件（距离范围、在线状态、人数需求）快速过滤出符合条件的用户集合。最优组合选择阶段在候选集中寻找最佳的玩家组合——这个组合应该最大化匹配质量评分，评分可以基于距离的均值和方差（近且集中优于远且分散）、偏好标签的匹配度（兴趣相似的玩家组合优于随机组合）、以及历史匹配的负反馈（避免反复匹配同一组人）。

最优组合选择是一个组合优化问题——从N个候选用户中选出K个使得评分最大化。当N和K较小时，可以穷举所有组合寻找最优解。当规模增大时，需要使用贪心算法或启发式搜索来近似求解。贪心算法的策略是每次选择评分贡献最大的用户加入组合，直到凑够人数。这种策略不保证全局最优，但在实践中效果足够好。

9.3 匹配超时与降级策略

真实匹配中可能遇到长时间找不到足够玩家的情况——比如深夜时段、偏远地区、冷门游戏。匹配服务器需要实现超时和降级策略来处理这些情况。

基础超时策略是设定最大等待时间（如三分钟），超时后允许以不足人数开局。降级策略是在等待过程中逐步放宽匹配条件——先放宽距离限制（从十公里扩大到五十公里），再放宽偏好要求（从精确匹配到部分匹配），最后放宽人数要求（从标准人数降低到最低人数）。每一步降级都应该通知用户当前放宽了哪些条件，让用户了解等待时间延长的原因。

更高级的降级策略包括AI玩家填充——当等待时间超过阈值时，系统提供AI玩家来填补空位。AI玩家的行为需要足够拟真，避免其他人类玩家意识到某个位置是AI。对于谁是卧底和你画我猜这类语言密集型游戏，AI玩家的语言生成质量是关键技术挑战。对于狼人杀这类推理密集型游戏，AI的决策逻辑需要足够复杂以提供有意义的游戏体验。

9.4 房间制匹配与快速匹配

除了当前的快速匹配模式（系统自动寻找玩家），未来应该实现房间制匹配——房主创建房间并设置游戏参数，其他玩家通过房间码或房间列表加入。房间制匹配适用于以下场景：一群朋友约好一起玩、玩家想要自定义游戏参数（如狼人杀的角色配置）、或者玩家希望选择特定的对手。

房间制匹配的数据模型需要新增Room实体——包含房间ID、房主ID、游戏类型、当前玩家列表、游戏参数配置、房间状态（等待中/进行中/已结束）等信息。房间制匹配的流程是：房主创建房间→房间出现在公开房间列表中（或生成房间码私发）→其他玩家搜索并加入→所有玩家就绪后房主开始游戏。

快速匹配和房间制匹配可以共存——GameRoom提供两个入口，快速匹配按钮和创建房间按钮。快速匹配适合不想等待、愿意与随机玩家组局的用户；房间制匹配适合有固定玩伴、想要控制游戏参数的用户。两种模式的匹配结果都进入同一个游戏页面，但入口路径不同。

9.5 匹配历史与社交扩展

匹配历史是连接多次游戏体验的纽带。当玩家完成一局游戏后，系统应该记录这次匹配的信息——与谁玩、玩什么、结果如何、体验评价。这些历史记录服务于多个功能：快速重连（再和上次的人玩）、好友推荐（添加上次匹配的玩家为好友）、以及匹配偏好学习（根据用户历史上接受和拒绝的匹配，调整未来的匹配策略）。

匹配历史的社交扩展价值尤为重要。在NearPlay的场景中，用户通过游戏建立的联系往往是脆弱的——二十分钟的游戏互动可能不足以建立持久的社交关系。但如果系统在游戏结束后提供延续这种联系的工具——如添加好友、查看对方的活动参与记录、预约下次一起玩——那么脆弱的游戏联系就有可能转化为稳固的社交关系。这正是NearPlay产品闭环的关键一环：从游戏到社交、从线上到线下的持续转化。