呼叫中心 100 路并发到底要多少带宽：SIP 与 RTP 是两笔账

一个漏了三笔账的算式：100 路 × 64 kbps 不等于 6.4 Mbps

「100 路并发 × 64 kbps = 6.4 Mbps，所以拉一条 10 Mbps 就够了。」这句话在呼叫中心的容量评估会上出现过太多次，而且每次都以差不多的方式出错。64 kbps 是 G.711 的编码层码率，它不是链路上真实跑出去的比特数；一路通话在网线上是两股流而不是一股；而真正让服务器跑不动的那些东西，往往压根不在带宽账上。

按可自行代入的口径重算一遍。G.711 在 20 ms 打包周期下，每个 RTP 包承载 160 字节语音载荷，加上 RTP 头部 12 字节、UDP 头部 8 字节、IP 头部 20 字节，单包 200 字节；每秒 50 个包，单向 80 kbps；双向 160 kbps；100 路并发的媒体量级就是 16 Mbps。同样这 100 路，结论从 6.4 Mbps 变成 16 Mbps，差出 2.5 倍。换成 G.729，编码层只有 8 kbps，可 20 ms 打包时每包载荷仅 20 字节，加 40 字节头部后单包 60 字节，单向约 24 kbps，双向约 48 kbps，是编码层数字的 6 倍。编码码率越低，头部开销越难忽略。

这个算式漏掉的是三笔账。第一笔，媒体流要按「包」算而不是按「码率」算，打包周期决定了每秒包数，也决定了头部开销占比。第二笔，信令与媒体是两条独立的流，走不同的端口与路径，量级也不同，不能用一个经验系数糊在一起。第三笔，转码、录音、加密、穿透这些附加负荷消耗的是 CPU、磁盘、端口与排障时间，把它们塞进带宽预算，只会得到一个既不够用、又说不清哪里不够用的结论。

下面按这三笔账的顺序拆开，每一笔都给出可代入的变量和估算方法，不给定死的绝对值。

SIP 与 RTP 为什么必须分开算：端口、路径、量级都不同

SIP 是信令协议，负责会话的建立、修改与结束，常见走 5060（UDP/TCP）与 5061（TLS）；RTP 承载真正的语音媒体，使用动态端口区间，具体区间由软交换自身配置决定，需要在设备或配置文件里核对，不要照抄别人的默认值。RTP 通常还伴随 RTCP 控制流，端口成对出现。

两者的量级差异来自时间分布。一路通话可能持续几分钟，媒体流是全程持续的恒定流；而信令只在起止两端出现，另外还有终端周期性的注册刷新。也就是说，媒体带宽正比于「并发通话路数」，信令带宽正比于「每秒呼叫尝试数」，这是两个完全不同的自变量。一个 100 路并发、平均通话时长几分钟的平台，其每秒新建呼叫数通常远小于 100；反过来，一个跑预测式外呼的平台，并发路数不高但每秒尝试数可能很高，信令侧反而更吃紧。

信令的估算方法是：每秒呼叫尝试数 × 单呼叫信令报文数 × 报文平均长度，再加上注册刷新与失败重传的部分。单呼叫的报文数取决于是否带鉴权、是否走临时响应、是否有媒体重协商（re-INVITE），报文长度取决于是否携带多编码列表、是否启用加密、SDP 里带了多少候选。这些变量都随实际部署变化，只能按抓包或配置核对，不能拍脑袋取一个数。

更重要的是，信令与媒体出问题的表现完全不同。信令出问题表现为呼叫打不通、接通慢、注册掉线；媒体出问题表现为能接通但无声、单通、断续。排查时先分清是哪一侧，能省掉一半时间。带宽预算上也是两行，不要合并成一行。

编码层码率只是起点：G.711 64 kbps、G.729 8 kbps 这类数字的含义

G.711 约 64 kbps、G.729 约 8 kbps、G.722 约 64 kbps，这些都是编码层的载荷速率，含义是「编码器每秒产生多少比特的语音数据」，不包含下层任何协议头部，也不包含链路层开销。Opus 是可变码率编码，实际速率由目标码率、复杂度与网络反馈共同决定，配置区间较宽，取值必须以实际配置为准。

其中还有一个容易被忽略的差别：采样率与带宽类别。G.711 与 G.729 是窄带编码，语音采样率为 8 kHz；G.722 是宽带编码，采样率 16 kHz。窄带编码与宽带编码互通时，除了编解码算法转换，还牵涉采样率转换，这属于转码范畴的额外计算量，后面单列。

编码选择同时牵动四件事：音质、带宽、CPU 复杂度、与对端的兼容性。低码率编码省带宽，但算法复杂度更高，同等路数下 CPU 消耗通常更大，且对丢包更敏感；它还更容易破坏带内的按键音。高码率编码音质好、CPU 便宜，但带宽占用高。选型时不要只看「每路多少 kbps」这一个维度。

还有一点必须区分清楚：平台两侧可以协商到不同编码。中继侧与运营商协商到的编码，和坐席话机侧协商到的编码，是两次独立协商。很多带宽算错，正是因为拿坐席侧的编码码率去估中继侧的流量。

头部开销怎么算：打包周期 × 每秒包数 × 40 字节

语音数据从编码器出来后，要逐层封装：RTP 头部、UDP 头部、IP 头部，标准情况下合计 12 + 8 + 20 = 40 字节/包。如果链路上还有隧道封装、PPPoE、额外的 IP 选项，这 40 字节还要往上加，具体增量取决于封装方式，需按实际链路核对。

估算方法分三步。第一步算每秒包数：每秒包数 = 1000 ÷ 打包周期（毫秒），20 ms 对应 50 包/秒，30 ms 对应约 33 包/秒，40 ms 对应 25 包/秒。第二步算单包载荷字节数：载荷字节 = 编码码率（bps）× 打包周期（秒）÷ 8。第三步算单向带宽：单向带宽 = 每秒包数 ×（载荷字节 + 40）× 8，单位是 bps。

把打包周期调大，头部开销占比会下降，代价是时延上升和抗丢包能力变化。G.729 在 20 ms 下单包 60 字节，头部占三分之二；把打包周期调到 40 ms，载荷变成 40 字节、单包 80 字节、每秒 25 包，单向降到 16 kbps，但单向时延预算要多吃掉 20 ms。这笔交换值不值，取决于端到端时延还剩多少。

谈到时延预算就绕不开抖动缓冲与丢包补偿。接收侧需要一个缓冲来吸收网络抖动，缓冲越大越能扛抖动，但每一毫秒缓冲都是从端到端预算里扣的；丢包补偿（PLC）可以在少量丢包时掩盖听感损伤，但它引入的是算法处理与额外时延，而不是带宽。工程上常见的做法是：先定死端到端单向时延目标，再回头分配编解码时延、打包时延、缓冲时延与网络传输时延，哪一项超了就调哪一项。行业里常引用 ITU-T G.114 的建议作为话音时延的可接受区间参考，具体目标值请按业务体验要求确定。

另外两个容易漏的量：一是每秒包数本身就是设备指标，防火墙、网关、虚拟交换机的转发能力往往按包速率而非比特率标称，同样的带宽在 20 ms 与 40 ms 打包下包速率差一倍；二是二层开销，以太网帧头与帧间隙在物理接口上是真实占用，做接口级核算时不能只算三层。

别忘乘 2：一路通话是双向两股流

一路通话包含两个方向的 RTP 流，上行与下行各自独立，各有自己的端口对。前面算出来的单向 80 kbps（G.711，20 ms）只是其中一个方向，双向合计是 160 kbps。很多估算在这步出错，是因为下意识把「一路」当成「一股」。

乘 2 之后还要看清机房的带宽计费口径。有的按上行与下行之和计，有的按两者中较大的一侧计，有的按 95 峰值或月累计计。同一个 16 Mbps 的双向流量，在不同口径下折算出来的账单流量并不相同，选带宽前先把口径问清楚，这一步不需要任何技术判断，只是别漏问。

还有几种情况会让流数超过 2 倍：会议或三方通话需要混音，混音路数与并发流数是两个概念；质检监听、耳语、强插会在原有两股流之外再叠加一路媒体；播放等待音与 IVR 放音时，媒体是持续流，不会因为没人说话就停。做峰值规划时，这些叠加流都要计入。

另外提醒一句：如果坐席分布在异地，或者媒体需要经过集中式的语音网关，那么流量在拓扑上的位置会变。两股流不一定都经过同一条链路，规划时要按链路分别画出流量，而不是按平台总并发乘一个总数。

静音抑制能省平均，但不能省峰值

静音抑制（VAD）与舒适噪声（CNG）的作用是：说话方不发声时不再发送完整语音包，只以很低的速率发送舒适噪声描述，让对端听起来不像断线。开启后，一路通话的平均带宽确实会降下来。工程估算时常用一个活动因子去折算平均值，取值多在 0.5 到 0.7 之间，具体数字要以实际通话录音统计为准，不要直接套用别人的业务模型。

但峰值规划绝不能用活动因子打折。原因是带宽是共享资源，瞬时叠加不看平均值：同一时刻有多少路在同时发声，是一个统计波动问题，坐席集中放音、集中外呼、集中播报时，活动比例会瞬间接近 1。而且 VAD 并非在所有场景下都生效，环境噪声大、播放音乐、等待音、IVR 语音这些时段，语音包是持续发送的。

建议的口径是分开两套数字：峰值规划用「不启用 VAD + 双向 + 含 40 字节头部」算出来的值，作为链路与设备能力的下限；平均成本估算再乘活动因子，用于容量与费用的粗略判断。两套数字都算，写清楚各自用途，混用才是问题。

转码吃的是 CPU 不是带宽：直通与转码的分界线

这是整篇最容易被算错的一笔。媒体流经软交换时有两种状态：两端协商到同一编码时，媒体包基本只做转发与桥接，不需要解码再编码，这就是直通（pass-through）；两端编码不一致时，平台必须把一侧的码流解码、必要时做采样率转换、再按另一侧编码重新编码，这就是转码（transcoding）。

直通时 CPU 的主要工作是包转发、RTP 头部处理、抖动缓冲管理与混音（如果有）；转码时每一路每一秒都要跑完整的编解码流程，这是软交换上最典型的 CPU 消耗项。二者在 CPU 上的差距是数量级性质的，而不是百分比性质的。所以评估服务器能力时，真正要数的是「需要转码的并发路数」，不是「总并发路数」。

哪些情况会触发转码？中继侧与运营商协商为 G.711，坐席侧软电话用 G.729 或 Opus，中间就要转；窄带与宽带互通时除了算法转换还要做 8 kHz 与 16 kHz 之间的采样率转换；会议、三方、监听耳语这类混音场景，混音本身也需要在 PCM 域做运算，等价于落回转码路径。还有一种常被忽略的：放音文件编码与链路编码不一致，播放等待音或 IVR 语音时也会触发转码，导致「没人说话的时候 CPU 反而高」。

转码与带宽的关系要说清楚。转码本身不新增带宽，链路上的比特数由该链路协商到的编码决定；但如果两侧编码码率不同，出向与入向的带宽本来就不相等，这时要按方向分别算，不能取一个值乘 2。换句话说，编码不一致带来的后果是「两个方向带宽不对称」加「CPU 上多一份持续开销」，两笔分别记。

减少转码路数的思路比堆 CPU 更划算：在协商阶段把编码顺序排好，让两端尽量直接协商到同一编码；让终端直接支持中继侧编码，避免在平台内做二次转换；把放音素材预先转成目标编码并按需准备多套；混音场景控制规模。做完这些，需要转码的路数往往能降下来一大截。这笔账真正贵的地方不在带宽，也不在总路数，而在那部分被迫转码的并发。

录音吃的是磁盘与 IOPS：单轨与双轨的差别

录音的做法是从媒体流上分流一份副本落盘，本质是一次持续写入。如果录音写在本机磁盘或内网存储上，它消耗的完全是磁盘容量与写入能力，不构成公网带宽；只有把录音实时传到远端集中存储时，才会在链路上产生一份额外的上行流量，这一份要单独算，不要和通话媒体混在一起。

录音的资源账有三项。容量：并发录音路数 × 编码码率 × 录音时长 × 轨道系数，轨道系数在单轨（两个方向各存一路）与合成轨（两路混成一路）之间差约 2 倍。落盘格式也很关键，直接写未压缩的 PCM 与写成压缩格式，容量差异很大，常见做法是录制时写中间格式、事后批量转压归档，这样就把一部分 CPU 与 I/O 压力挪到了闲时。

第二项是写入 I/O。录音是持续的小块写入，路数多的时候累积成稳定的写吞吐；同时会产生海量文件，文件数量本身会拖慢备份、索引与元数据操作。评估存储时既要看持续写带宽，也要看随机写能力与文件系统在小文件规模下的表现，不能只看容量够不够。

第三项是可靠性。录音写入抖动一般不会立刻让通话断掉，但会造成录音缺失或文件损坏，在需要质检与留存的场景里，这属于事故级后果。写缓存策略、磁盘健康监控、落盘完成确认、归档校验，这些都要在上线前定好。把这些算进「带宽够不够」的讨论里，是典型的账记错科目。

加密带来的成本落在哪：SRTP/TLS 分别是带宽还是 CPU

信令侧加密常用 SIP over TLS（端口 5061），媒体侧加密用 SRTP。密钥协商发生在信令阶段，具体机制不同：有的把密钥材料放在 SDP 里随信令交换，有的走 DTLS 握手。无论哪种，加密都会给信令阶段增加报文内容与往返次数，这部分计入信令带宽与建链时延，不计入媒体。

SRTP 对每个媒体包增加认证标签，可能还有填充，因此每包的字节数会上涨。带宽增量的算法很简单：每秒包数 × 每包新增字节数 × 8。由于新增的是每包固定字节，它的绝对值不大，不会改变「每路几十 kbps」这个量级判断，但它在低码率短打包周期的组合下占比会明显一些，因为同样的语音被切成了更多包。

真正需要留意的是 CPU。每个包都要做加解密与完整性校验，所以加密的 CPU 成本正比于每秒包数，而不是正比于比特率。这意味着一个「低码率 + 短打包周期」的配置，虽然带宽很小，加密的包数却一点不少，CPU 上的开销可能比「高码率 + 长打包周期」更高。评估时要把这两个变量放在一起看。

还有一个运维侧的事实：加密之后，抓包排查时看不到明文媒体，DTMF 事件与编码器问题的定位方式要相应调整，需要在部署阶段就把诊断手段准备好，而不是等出问题才发现看不懂包。

NAT 与端口范围：单向无声这个症状的成因

RTP 使用动态端口区间，区间范围由软交换配置决定，需要在配置文件中核对实际值，并在防火墙与安全组上完整放行，注意 RTCP 端口通常紧随 RTP 端口成对出现，别只放行一半。端口区间放行的粒度建议按实际配置的最小可用区间设置，不要图省事全开，也不要开得太窄导致部分呼叫拿不到端口。

单向无声是最典型的穿透失败症状：信令一切正常，呼叫能建立，主叫或被叫有一方完全听不到声音。成因通常是 SDP 里携带的地址端口对对端不可达，或者可达但没有正确映射回去。排查顺序建议固定下来：先看 SDP 里写的地址与端口是不是公网可达的地址；再看边界设备是否放行了整个 RTP 端口区间；然后确认映射是否在会话期间保持稳定，端口复用与映射老化会导致通话中途出问题；最后检查是否有应用层网关在改写 SDP，改写不当同样会造成地址错配。

这一项和带宽毫无关系。带宽再充裕，端口不通就是无声；反过来，端口通了但每秒包数超出网关转发能力，表现则是断续或抖动，而不是完全无声。把这两种现象区分开，就能快速判断该查端口还是该查性能。

顺带把包速率这个指标单独拎出来：100 路 G.711 在 20 ms 打包下，双向每秒约 10000 个包。这个数字要拿去和防火墙、网关、虚拟化层的转发能力做对照，因为很多设备的标称能力是按包速率给的，带宽远远没到上限时包速率可能已经先到顶。

DTMF 三种方式不匹配会怎样

按键信号的传递有三种方式。带内方式把双音多频信号当作普通音频放在语音里传输；RFC 2833/4733 方式把按键作为 RTP 事件载荷单独发送，需要在 SDP 里协商对应的电话事件载荷类型；SIP INFO 方式把按键信息放在信令通道里带外传递。三种方式没有优劣之分，关键是两端要落在同一种上。

不匹配的表现是按键丢失、被识别成别的数字、或者时好时坏。低码率编码是常见的诱因：G.729 这类为语音优化的编码器会损伤带内按键音的波形，导致带内方式不可靠，此时应改用事件方式。事件方式本身也有坑，SDP 里协商的电话事件载荷类型号两端若不一致，或者一端在重协商后丢掉了这一项，按键同样会失效。

排查时按这条线走：抓包确认是否真的产生了按键事件包，再看 SDP 协商结果里有没有对应的载荷类型、编号是否一致，最后核对接收侧期望的是哪种方式。这类问题与带宽完全无关，加大带宽不会有任何改善，靠升级链路去解决按键问题属于典型的误诊。

典型场景一：80 至 120 路带录音的客服中心

以下为典型部署思路，并非特指某一真实客户。假设一个客服中心峰值 100 路并发，中继侧与坐席侧均协商为 G.711，两侧一致因此媒体直通，打包周期 20 ms，全部通话录音并保留以供质检，坐席集中在一个办公区。

媒体部分按前文方法代入：单向 80 kbps，双向 160 kbps，100 路即 16 Mbps 量级，这是不含静音抑制、不含额外封装的峰值口径；若做平均成本估算，再乘一个以实测统计得到的活动因子。每秒包数双向约 10000 个，需要拿去核对网关与虚拟化层的转发能力。如果链路上还有隧道封装，每个包还要再加对应字节数重新折算。

信令部分单算：按每秒呼叫尝试数 × 单呼叫报文数 × 报文长度估算，并叠加注册刷新与失败重传。这个量级通常明显低于媒体，但在集中呼入、集中放号的时段会形成尖峰，规划时按尖峰而非平均值。

资源侧的三笔要分别记：录音按 100 路 × 编码码率 × 时长 × 轨道系数估容量，同时估持续写吞吐与文件数量；转码路数按实际不一致的通话数估，此场景假设两端一致则为 0，CPU 主要留给包转发与可能的混音；加密若开启，按每秒包数估 CPU，按每包新增字节估带宽。结论上，公网带宽按 16 Mbps 峰值加余量准备，磁盘与 CPU 各自按上面的变量单算。

典型场景二：外呼系统与运营商中继对接

以下为典型部署思路，并非特指某一真实客户。外呼系统的流量形状与呼入客服中心很不一样：通话时长短、呼叫尝试次数远大于接通次数、并发路数不高但建立速率很高。因此它的瓶颈常常不在带宽，而在每秒呼叫尝试数与转码路数上。

与运营商中继对接时，中继侧的编码通常由运营商侧决定，需要与对方确认协商结果；如果坐席侧使用了不同编码，那么每一路接通的通话都会落进转码路径，转码路数直接等于并发通话数。这个场景里，把坐席侧编码对齐到中继侧编码，往往比扩容服务器更有效。

信令侧要按尝试数而不是接通数估算。预测式外呼会产生大量未接通、被拒、忙线的呼叫，失败重拨还会再放大一次，这些全部消耗信令带宽与 CPU，却不产生任何媒体流量。因此外呼平台的容量清单里，「每秒呼叫尝试数」必须作为独立变量写进去，并明确失败率与重拨策略。

带宽侧仍然按接通后的并发通话数估算，方法不变：单向含头部带宽 × 2 × 并发接通数。这里要注意一个容易混淆的点：并发路数在呼入场景由话务量决定，在外呼场景由外呼策略与接通率共同决定，规划时得先定策略再算路数，顺序反过来会低估。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

容量清单：按什么顺序算

把三笔账拆开之后，估算就有了固定顺序，每一步只引入一个新变量，算错也容易定位。顺序本身比公式重要，因为大部分配置失准不是算错，而是漏算或者顺序颠倒导致的重复计算。

第一步，确定编码与打包周期，同时确认这是哪一侧的编码，中继侧与坐席侧分别记。第二步，算单向含头部带宽，用「每秒包数 ×（载荷字节 + 40）× 8」，若有隧道封装再加相应字节。第三步，乘方向数得到每路双向带宽，两侧编码不同时按方向分别算而不是乘 2。第四步，乘并发路数得到媒体带宽峰值，同时算出每秒包数，拿去和网关、虚拟化层的转发能力对照。

第五步，单算信令带宽，自变量换成每秒呼叫尝试数，并叠加注册刷新与失败重传。第六步，数清楚需要转码的并发路数（含采样率转换、混音、放音素材编码不一致），按这个数估 CPU，其余按直通处理。第七步，估录音：容量按路数乘码率乘时长乘轨道系数，另估持续写吞吐与文件数量，若录音要传到远端存储则再单列一份上行流量。第八步，加密按每秒包数估 CPU、按每包新增字节估带宽增量。

第九步，核对端口与穿透：确认 RTP 动态端口区间实际配置值，完整地放行到防火墙与安全组，含 RTCP 成对端口，并确认 SDP 地址可达与映射稳定。第十步，加余量。余量给多少取决于业务波动与扩容周期，工程上常按 20% 至 30% 留，波动大或扩容周期长的场景取上限，这一步没有标准答案，只有业务约束。

还有两条经验值得写在清单最后：一条是监控要按三笔账分别设指标，媒体看带宽与包速率、信令看尝试数与失败率、资源看转码路数与录音写入，混在一起看就失去了拆分的意义；另一条是上线前用真实话务模型压一遍，把估算值和实测值对上，再回头修正变量，比事后加机器便宜得多。

呼叫中心的带宽与资源账，上线前最该算清楚的几项

第一项，媒体的口径。别再拿编码层码率当链路上限，把打包周期、40 字节头部、双向两股流这三件事代进去算一遍，得到一个明确写着口径的数字，比如「G.711、20 ms、双向、含头部」。口径不写的带宽数字没有意义。

第二项，信令的自变量。信令带宽正比于每秒呼叫尝试数而不是并发路数，外呼场景尤其如此。把尝试数、失败率、重拨策略这三个值问清楚，才能算出信令侧的量级，也才能判断建链时延会不会成为体验瓶颈。

第三项，转码路数。这是 CPU 账的主项，也是唯一一个能通过编码规划大幅削减的项。做法是让中继侧与坐席侧协商到同一编码、放音素材预先转好、混音规模受控，把需要转码的路数压下去，服务器选型就会宽松很多。

第四项，录音的磁盘账。容量、持续写吞吐、文件数量三件事一起看，单轨与合成轨的容量差约 2 倍，落盘格式决定量级。录音是合规资产，写入可靠性要按事故后果来设计，而不是顺带配置。

第五项，端口与穿透。RTP 动态端口区间的实际配置值、完整放行、SDP 地址可达、映射稳定，这四件事核完，单向无声这类问题基本就能排除。它不消耗带宽，但能让前面所有带宽计算白费。

最后一项是余量与验证。留多少余量取决于业务波动与扩容周期；估算完成后用真实话务模型压测，把变量校准回来。这三笔账拆开算的价值，不在于算得更精，而在于出问题时能立刻知道该看哪一行。

呼叫中心这篇的技术口径与来源，以及哪些需要你自己验证

可以放心引用的部分是公开标准的定义性内容：SIP 承担会话建立与结束的信令，常用 5060 与 5061 端口；RTP 承载语音媒体并使用动态端口区间；RTP、UDP、IP 的标准头部长度分别为 12、8、20 字节；G.711 约 64 kbps、G.729 约 8 kbps、G.722 约 64 kbps 这些是编码层码率；话音时延的可接受区间可参考 ITU-T G.114 的建议。

需要你自己代入的是所有与部署相关的变量：实际协商到的编码与打包周期、RTP 动态端口区间的配置值、每秒呼叫尝试数与失败重传率、录音的轨道策略与落盘格式、加密开关与算法、链路上是否存在隧道封装、机房的带宽计费口径。这些值在不同平台上差别很大，本文只给方法不给定值。

需要你实测校准的是几类经验参数：通话活动因子（用于平均值估算，不能用于峰值规划）、单位路数的转码资源消耗、录音写入的实际吞吐与文件规模、网关与虚拟化层在目标包速率下的转发表现。这些量与硬件、内核、配置强相关，别人给的数字参考价值有限。

本文没有给出、也不应当给出的内容：具体机型的资源占用绝对值、每分钟录音的确切容量、任何实测跑分或客户案例。涉及服务器机型、机房带宽与商务报价的部分，以官网实时信息或咨询确认为准，本文不提供具体数值，也不对未核验的配置作任何推荐。把这些变量代进上面的清单，得出的结果才对你自己的平台有意义。