先把三个方案的本质说清楚：
CDN解决的是"内容离用户远"。它在各地布缓存节点，把静态资源（图片、视频、安装包、热更文件）推到离用户最近的边缘节点，用户就近取。本质是分发缓存。
CN2解决的是"跨境链路差"。电信CN2 GIA/GT 是从中国出境走的优质骨干网，绕开普通163公网的拥堵节点，回程和去程都更稳定。本质是线路优化。
组合方案 是把流量按性质拆开：静态资源走CDN，动态请求（API、登录、支付、WebSocket、数据库）走专线或云加速。
横评之前先记住这个区别，否则很容易得出"我买了CDN为什么网站还是慢"这种错误结论——因为慢的那段请求根本不走CDN。
一、五个测试维度和方法
测试方法上，用多地拨测节点模拟不同地区用户（华北、华东、华南、东南亚、北美），分别对三类方案做基线测试和晚高峰复测。下面给的是经验区间，不是某个特定厂商的精确数字，选型时以你自己的业务拨测为准。
二、单独 CDN：静态分发的最佳选择，但别指望它解决一切
表现
静态资源场景（图片、视频、安装包、热更）：延迟和命中率都是最好的。
国内用户访问一个放在美西的图片，直连源站 RTT 普遍在 180–220ms，晚高峰更差。走 CDN 后，边缘节点命中，RTT 降到 20–50ms，下载速度直接受带宽而非跨境链路限制。
命中率是CDN的命门。 静态资源缓存命中率做到 95% 以上，CDN的价值才真正发挥。命中率上不去的常见原因：URL 带随机参数、源站返回 no-cache、资源路径不带版本号导致每次发版全量回源。
短板
CDN 对动态请求基本无能为力。API 调用、登录、支付、搜索这类请求每次都不同，CDN不会缓存，全部回源。这种场景下 CDN 只起了"转发"作用，等于给跨境链路加了一跳，延迟反而可能略升。
长连接（WebSocket、gRPC streaming、实时音视频）也不适合走普通 CDN。 普通 CDN 节点有连接超时，长连接会被中间节点切断。
适合谁
- 主要做内容分发：视频站、安装包下载、静态资源站
- 海外用户为主，源站在国内或就近区域
- 预算有限，先把最明显的"加载慢"问题解决
不适合谁
- 业务接口占比高，比如 SaaS 后台、电商下单、游戏实时对战
- 需要稳定低延迟的交互类业务
三、单独 CN2：动态业务的稳定器，但贵
表现
CN2 GIA 在跨境动态请求上的稳定性明显优于普通公网。 普通 163 线路晚高峰 RTT 抖动可以从 150ms 跳到 400ms+，丢包率偶尔冲到 5% 以上。CN2 GIA 晚高峰 RTT 波动通常在 ±20ms 以内，丢包率长期低于 0.5%。
对于 API 业务，这个差别是体感级的：用户点一个按钮，普通公网可能要转两秒，CN2 线路转 300ms，前端体验差别非常明显。
SSH 运维、数据库主从同步、Git 拉取这类对丢包敏感的场景，CN2 几乎是必选项。 丢包 1% 时 MySQL 主从延迟可能翻几倍，因为重传机制会放大 TCP 层的损耗。
短板
贵。 CN2 按带宽月租计费，1Mbps 一个月的成本是普通公网的几倍到十几倍。按业务峰值配带宽，90% 的时间带宽空闲，成本浪费严重。
节点覆盖有限。 即使是 CN2 优质线路，节点也主要在国内几大城市，海外就近接入能力不如 CDN。东南亚、拉美的用户体验提升不如国内用户明显。
不适合大文件分发。 一个 500MB 的安装包，走 CN2 专线，按你配的带宽跑，高峰期可能比 CDN 慢十倍以上——因为 CDN 用的是边缘节点的大带宽，CN2 是你自己买的那几 Mbps。
适合谁
- API、登录、支付、实时音视频这类动态业务
- 跨境运维、数据库同步、CI/CD 拉取
- 对稳定性要求高，愿意为体验付费
- 业务量不大，带宽需求可控
不适合谁
- 主要做下载、视频、静态资源分发
- 带宽需求大，按峰值配专线成本扛不住
四、组合方案：成本和体验的平衡点
组合方案的核心思路是按流量性质拆域名，把不同请求导到不同链路：
static.example.com → CDN 边缘节点（缓存静态资源）
api.example.com → CN2 / 云加速专线（动态 API）
download.example.com → CDN（大文件分片分发）
ws.example.com → 长连接加速（WebSocket/实时）
实际效果
我们在做过的几个跨境业务里，组合方案基本都是综合得分最高的：
- 静态资源走 CDN：下载速度提升 5–10 倍，源站带宽压力下降 80% 以上；
- API 走 CN2/云加速：动态接口 RTT 稳定在 80–150ms（国内到东南亚），晚高峰抖动小于 30ms；
- 总成本：因为 CDN 按流量计费、CN2 按小带宽月租，组合下来通常比"全走 CN2"便宜 40%–60%，比"全走公网 CDN"在动态体验上提升一个量级。
组合方案真正的难点不在选型，在配置
拆分域名要彻底。很多团队只拆了主站，结果 API 还挂在同一个域名下，或者图片请求走了 API 域名、API 请求走了 CDN 域名。这种"半组合"等于没组合。
缓存策略要分域名配。CDN 域名的 Cache-Control 要设长，API 域名必须禁缓存（否则登录态会串号）。最常见的翻车就是 API 被 CDN 缓存了，用户 A 登录看到用户 B 的数据。
源站隔离要做。两个域名回源到不同的源站入口或不同端口，安全策略也要分开配。CDN 域名回源白名单和 CN2 回源白名单不能混。
适合谁
- 业务同时有静态分发和动态交互（电商、SaaS、游戏、跨境独立站）
- 已经做到一定体量，开始关注成本优化
- 有基本的运维能力能配合拆域名
五、三类方案对比表 
六、按业务选型，快速定位决策：
- 业务 90% 是静态资源（视频站、下载站、内容站）→ 单独 CDN，把命中率和回源策略调好
- 业务 90% 是动态交互（SaaS、后台、API 服务）→ 单独 CN2/云加速，重点看晚高峰稳定性
- 两类都有，业务上了一定体量 → 组合方案，按域名拆分，静态 CDN + 动态专线
- 预算非常紧，先解决最明显的痛点 → 优先 CDN（因为"加载慢"是用户第一感知），后续再补动态链路
跨境网络优化是要选择"最匹配你业务流量结构的方案"。
搞清楚你的流量里，静态和动态各占多少？这个比例决定了组合方案的成本分配。
别一开始就上最复杂的组合。先把现有业务的请求分类做清楚，看日志、看 Chrome DevTools 的 Network 面板，静态和动态的比例一目了然。再根据比例倒推选型，比看任何横评都靠谱。
