@
ligogid 你这个拉踩有点不公平吧，拿 Surge 的正式营销文案，去打 egern 作者的个人频道的微博式碎碎念😅
而且你的论述反映在技术上的问题更大（我特意又去 egern 的电报频道看了下你的喷点）：
1. Egern 作者说“tunstack 替换 lwIP”“下载场景提升”“CPU 占用下降”，本质是独立开发者在频道里汇报优化进度。结果你拿“纯 C 、zero-copy 、PPS 、userspace TCP stack”这种发布会级工程话术去压它，技术上下文的语境就不同。
2. Egern 作者也不是“只会看 CPU”，他做的是用户态网络栈替换，他也是自研的 tunstack 。这已经说明了 CPU 降低和下载提升，不是简单 App 层优化。你暗示他只会“宣传 CPU 低”，属于是故意降格理解。
3. “CPU 占用低”本来就是 iOS 代理 App 的重要指标。CPU 直接关系到发热/能耗/后台稳定性/高并发表现。
4. 你转述的 surge 所谓的 zero copy 、少拷贝，最终也会反映为 CPU 降低。用 zero copy 打压别人只讲 CPU ，听起来高级，但技术逻辑完全莫名其妙。
5. 比较关键的一点，你转述的 Surge 营销原文说的是 Surge Mac 6 ，不是 surge iOS 。
Mac 端的纯 C zero copy ，PPS 等，其实也不能直接拿来压 egern 这种 iOS-first 。
Surge Mac 同时支持 Intel 和 苹果 Silicon ，而 Egern 本身就是只支持苹果 Silicon/iOS App 形态，不兼容 Intel ，所以两者产品线和平台负担天然性的不同。surge iOS 目前依然是 v5 ，你说的那些 zero copy 等工程化设计没有包括在当前的 iOS 版本，这点也是需要特别澄清的。
=====
接下来，我要来论证另一件事，那就是 surge 团队技术力缺陷了。
Surge 的强项也许在客户端工程上，但这不等于它有协议审判权，但是 surge 团队喜欢锐评+错误理解其他协议，自大傲慢显露无疑。
2026 年截至 5 月下旬，刘亚晨和几个粉丝头子，同另一个大嘴巴也就是 xray core 的作者 RPRX 和他粉丝爆发的键盘论战，已经把互相的成色水平展露出来了。
几个事实：
1. Surge 相关方在 shadowTLS 上暴露过明显的协议理解问题。他们把 shadowTLS 说成「完全独立脱离于 SSL 的混淆实现」和「与 SSL 库无关，所以可以随意构造 sessionID 」，但 shadowTLS v3 原作者文档实际强调的是「无需 Hack TLS 库」，并不是「无需 TLS client 」。
shadowTLS v3 仍需要构造 ClientHello 生成带签名语义的自定义 sessionID 。自定义的 sessionID 和真实 TLS 行为不是无关实现细节，而是 shadowtls 抗探测模型的一部分。
大聪明 Surge 团队一边把 shadowTLS 简化成「随便构造 TLS 外观」的混淆壳，一边反过来指责 RPRX 不懂协议实现细节，只能说术业有专攻，不出来走两步还真的藏拙了😁
2. Surge 团队对 vless/reality 、shadowTLS 、anyTLS 的标准并不一致。批评 vless 和 reality 时说它碰 TLS 细节、复杂、不优雅；但面对 shadowTLS 或 anyTLS ，又会按自己产品喜好解释成“实现简洁、边界清楚、易维护”（其中对 shadowTLS 的理解还是错的）。
这更像维护成本、生态立场和私人恩怨混合影响技术选型，而不是纯粹中立的协议判断。
3. 另一个讽刺的现实情况：surge 经过和 xray 方的恩怨局互喷后，精挑细选地加入了 anyTLS 而不是 vless 。而截至 2026 年 5 月 23 日也就是今天，因为一个多月前大量机场的 ss 中转爆雷，一些机场也跟风采用了 anyTLS 中转或直连，结果没几天就又出现了针对 anyTLS 的大面积双杀（中转和直连 anyTLS 都被杀）。直接打脸了“Surge 团队精挑细选支持的协议”，笑嘻。
Surge 也许在客户端工程上有一定实力，但它的团队在协议理解和选型上实际上非常的情绪化和业余。然后他家还喜欢用一些看起来硬核的词汇踩竞品，其实都是在唬小白而已。
Surge 背后是一家注册在中国大陆北京的公司，现今已经是 2026 年，在有很多竞品且差距不明显的情况下，新用户如果没有特殊理由的话，完全没有必要再选择 surge😮💨
9
Select Language