部署CDN时，带宽需求由实际文件大小、并发人数和缓存命中决定，不是选一个“10Gbps”数字就能解决的。大带宽也不会自动提高动态接口或数据库的性能。
先粗算吞吐而不是凭感觉采购
若有1000个用户同时以平均2Mbps速度下载，网络平均需求就接近2Gbps；再考虑TLS、协议开销、突发峰值及不同节点的负载分配。视频点播应按平均码率、并发观看与预估缓存命中算账；交互式网页还需要看首字节时延。
边缘出口与源站出口要分开
命中边缘缓存的请求不必每次回源；缓存键设置错误、短TTL和频繁变更的资源可能带来意料外的回源峰值。检查缓存规则、Range请求、日志、热链防护、源站响应头和回源带宽，避免仅扩大CDN端口而使源站被冲垮。
用真实样本确定扩容阈值
从边缘请求量、P95响应、命中率、丢包和结算流量逐项记录，准备突发流量报警与源站限流。比较服务商报价时要对齐相同的计费模式、地区、HTTPS请求、WAF与日志成本。
用一个公式估算源站出站需求
假设 CDN 每天向用户交付 500GB 静态资源，按请求字节加权的缓存命中率为 90%，则在忽略动态回源及额外传输开销的简化模型里，源站每天需承担约 500GB × (1－90%)＝50GB 的回源数据。这里强调“字节命中率”而非仅请求次数命中率；若没命中的恰好是大文件，源站压力可能远超按请求个数计算的结果。
带宽峰值不能只用平均流量换算
50GB/天平摊后看似不多，但实际用户可能在几分钟内集中刷新或下载，CDN 缓存失效后也可能出现回源尖峰。容量规划应分别统计 P95 与峰值回源速率、并发连接数、单对象大小、突发清缓存后源站能承受的 QPS 与带宽，而非只按整月流量除以天数。
缓存命中率优化的先后顺序
先区分真正可公开缓存的静态资源与需要鉴权的私有数据，再设置适当 TTL、带版本号的资源 URL、规范化查询参数和压缩策略。确认缓存键不会把不同用户的响应混淆之后，再进行热点预热和分区规则调整；如误缓存私人信息，应立即清理缓存、撤销相关规则并评估泄露范围。
大带宽不能脱离缓存与源站计算
以一个静态下载平台为例：总分发需求500GB/日、缓存命中率90%时，理想化回源内容约50GB/日；如果缓存键设置错误导致命中率降到30%，回源可能升至350GB/日。这里忽略动态请求和额外协议开销，仅用于量级估算，不能作为真实结算值。峰值并发还会导致短时回源突发，因此需要同时配置源站连接数、回源限速、长尾文件优化和缓存预热。
监控面板应该分开显示四个量
把“用户侧CDN出站流量”“CDN回源流量”“源站网络端口使用率”“源站磁盘I/O”分开观察。如果CDN缓存命中良好，页面仍很慢，可能是API未缓存或源站计算慢；若边缘带宽已打满但源站空闲，增加源站服务器配置不会改善瓶颈。使用同一时区对齐这些指标才能找到真正的限制环节。
缓存键的错误也会造成“源站带宽不够”
如果动态查询参数被不恰当地纳入缓存键，同一资源可能形成大量边缘副本，实际命中率比预计低得多；反过来，忽略用户身份参数也可能把个人化结果错误地返回给其他人。上线前先按业务实际URL定义缓存键、过期、清理与回源权限，观察缓存状态和源站连接数后再决定是否增加专线或端口带宽。
