PotatoChat 在公开资料中没有给出单次多人通话的固定上限；现实中的最大可支持人数会随通话类型（纯音频或含视频）、房间架构（P2P、SFU、MCU）、服务器与带宽配置等条件变化。想要精确数字，请以官方文档或客服说明为准。
一句话说明（先把结论放前面）
简单来说，如果官方没有明确标注，你遇到的上限通常由架构和资源决定：纯音频场景可以支持更多人，视频场景要看每个用户订阅的视频流数量和后端的转发能力。
为什么会有“上限”？先把原理说清楚
要弄明白 PotatoChat 能支持多少人，先得了解两个关键点：通话的架构类型和每个参与者的资源消耗。用费曼的方法，我把它拆成最小的基础单元来讲——像在解释给没有背景的朋友听。
通话架构决定扩展方式（最重要）
- P2P（点对点）：每个用户直接与其他所有用户建立连接。优点是延迟低、后端压力小；缺点是参与人数一多，网络和CPU开销呈平方级增长，通常只适合小组通话（一般单个房间少于10人）。
- SFU（选择性转发单元）：服务器负责接收每个用户的媒体流，然后转发给需要的订阅者。服务器不做合成，负担相对中等。适合几十人甚至上百人的场景，前提是带宽和服务器足够。
- MCU（多点控制单元）：服务器将多个流混合后再下发，客户端负担小，但服务器CPU和带宽需求很高。适合高质量但参与人数有限的场景，通常不用于上百人的实时视频会议。
每路媒体流的成本（为什么视频比音频更“贵”）
把一个通话看成很多“小管道”，每个视频流消耗带宽、编解码CPU和渲染资源。举个比喻：音频像是短信，视频像是十张照片接连发，显然后者占用更多资源。所以，纯音频房间能容纳的人远多于高清视频房间。
现实中常见的“人数范围”是什么——给出可参考的区间
因为没有官方数字，给出一个合理的参考区间更有用：
- 小型互动视频会议：P2P 或 MCU 架构下，通常 2–10 人是常态。
- 中型协作或课堂：采用 SFU，可以稳定支持 20–100 人，视每人的视频分辨率和是否要显示所有人的视频而定。
- 大型发布或直播式会议：如果是“少数人发言、其他人观看”的模式，使用 SFU 或流媒体转发，音频观众可上千甚至更多；若每人都要同时发视频并实时可见，通常受限于数百人的范围内。
如何验证 PotatoChat 的真实上限（可操作的步骤）
别急着猜，按步骤来检验最靠谱：
- 查官方文档与更新日志：先看官网、开发者文档或 SDK 文档里有没有“最大并发”、“房间上限”之类的字段。
- 在应用内查设置：有些产品会在房间创建或订阅设置里约束最大成员或最大同时开启视频流数。
- 询问客服/技术支持：这是最直接的方式，尤其在企业版或付费版里，上限可能随购买方案变化。
- 做压力测试：按步骤逐步加入机器人或真实用户，记录掉线率、延迟、卡顿与CPU、带宽的使用峰值。
- 查看日志与质量统计：通过 WebRTC stats、服务器监控、或 SDK 提供的指标，观察丢包、抖动、编码帧率等关键数据点。
做压力测试时的具体指标和阈值（实验方法）
- 加入速率：每秒加入 1–5 个用户，避免瞬间洪峰。
- 监测延迟（RTT）和往返时间，延迟突然上升说明接近瓶颈。
- 观察丢包率，超过 2–5% 会显著影响通话质量。
- CPU 与网络带宽：服务器端与代表性客户端同时监控，找出瓶颈在哪侧。
若官方未说明，上限通常由哪些具体因素决定？（用表格整理更直观）
| 影响因素 | 为什么重要 |
| 通话架构（P2P/SFU/MCU） | 决定服务器负载分布与客户端开销，从根本上影响可扩展性。 |
| 视频分辨率与帧率 | 高分辨率和高帧率需要更多带宽与CPU，能显著降低可同时在线的视频数。 |
| 带宽与网络质量 | 带宽不足或抖动大时，系统会降码率或丢帧，影响可接纳人数。 |
| 服务器规格与部署方式 | 分布式部署和弹性伸缩能提升并发承载能力，单台服务器则会很快成为瓶颈。 |
| 客户端设备性能 | 低端手机同时解码多个视频流时容易卡顿，影响整体体验。 |
实际应用中的常见策略（如果你是产品经理或技术人员）
我会建议从产品层面来做设计：谁需要“被看见”？谁只是听众？把这个问题拆开，能显著提高可支持人数。
- 分角色显示：把“发言者”和“观众”区分开，只有发言者上传高质量视频，观众使用低码率或仅音频。
- 动态订阅：客户端只订阅当前需要显示的视频流，而不是订阅房间内所有人的流。
- 低码率模式：当并发增大时，可以自动切换到低分辨率/低帧率。
- 云端转码或CDN分发：用于大规模观看场景，把实时视频转为推流+CDN分发，观众数量弹性大。
如果你需要给业务下定论：我会怎么实际操作（步骤清单）
- 先从官方渠道确认是否有明确上限或分级方案。
- 根据目标场景（小组讨论/课堂/直播）决定是否需要 SFU 或 CDN 支撑。
- 设计测试方案并在真实网络条件下运行压力测试，记录关键指标。
- 若测试中发现瓶颈，优先考虑降级订阅策略或在后端增加资源（实例或带宽）。
- 把用户体验放在首位：与其追求一个看上去很大的“人数上限”，不如保证在目标人数下稳定流畅。
一些常见问答（边想边写的那种即时感）
问：“如果我只开音频，可以支持多少人？”
答：纯音频模式对带宽和CPU友好，使用 SFU 或广播式架构时，可轻松扩展到几百甚至上千听众，但要注意信令与房间管理的并发处理。
问：“是否能通过买更贵的套餐增加上限？”
答：很多团队产品是这样定价的：基础版支持较少并发，企业版或按需扩展可提升上限。具体要看 PotatoChat 的商务条款。
最后，给你一个快速核查清单（方便拿去问客服或技术人员）
- 官方是否有“房间最大人数”或“并发用户”字段？
- 默认情况下是 P2P、SFU 还是 MCU？
- 是否支持动态订阅与带宽自适应？
- 是否有针对大规模观众的直播/CDN 支持？
- 是否提供压力测试工具或测试环境？
好吧，说到底，如果你现在最想知道的是一个确切数字：请先看 PotatoChat 的官方文档或联系他们的技术支持，这是最可靠的来源；与此同时，上面的测试方法和优化策略可以帮你把不确定性降到最低，让你的业务运行得更稳。