人无外财不富，牛马无值班不肥

恭喜🎉

@zanjie1999 #196

可以考虑用 AI 重写一份了，没必要用 ssh、scp 这些。tunnel+分段、断点传输，两边再加上传输文件的管理功能、前端操作页面，需求能描述清楚，AI 很快就写出来，然后部署、测试稍微折腾下，估计半天一天大概就能搞定。
我这一周多让 claude 从头搞了一份网络库，支持 TCP/UDP/TLS/HTTP1.0/HTTP2.0/HTTP3.0/Websocket，让 claude 优化了很多，综合性能测试基本大于等于其他 go 的库，甚至和 c++、rust 库在不同协议上有来有回。
https://github.com/lesismal/fib

HTTP1.0/2.0/3.0/Websocket 在 github action 跑的 Benchmark：
https://github.com/lesismal/go-http1-benchmark/actions/runs/35991385639/job/107606051154
https://github.com/lesismal/go-http2-benchmark/actions/runs/35991371828/job/107606003742
https://github.com/lesismal/go-http3-benchmark/actions/runs/35991364871/job/107605978280
https://github.com/lesismal/go-websocket-benchmark/actions/runs/35973727175/job/107549159862

AI 效果很好，实现了 eventloop 后，一句话实现 HTTP1.0，一句话实现 HTTP2.0，一句话实现 HTTP3.0，一句话实现 Websocket。。。。
然后加各种 CI 的工程化、协议完整性测试、性能测试。
然后根据性能测试报告和 pprof 让 claude 优化，有的优化比较大，claude 一次要跑一个多小时，但是效果非常好，强得离谱。比如 HTTP1.0，优化前比标准库和基于标准库的方案强一点，但是跟 fasthttp 差距较大，优化后普通 Echo 测试跟 fast 差不多、测试期间系统稳定性影响各有输赢，因为背压机制优化的比较好、pipeline 测试直接吊打其他 go 库甚至 cpp/rust 的库，吞吐直接拉开距离。
AI，真的强得离谱，早点脱离手搓吧，让自己需求描述的能力交给 AI 来起飞。

@zanjie1999 我觉得，其实核心用处是 ws 的协议属性带来的稳定性。断线重连可能并不是 tunnel 这个场景的真正痛点，可能得不偿失甚至遇到边缘情况是负优化。

@lesismal #137 github.com/lesismal/pipe 也支持加密，cmd/server 、cmd/client 本身就支持密钥参数

之前没仔细看，刚又看了下，原来是这个作用。

其实我自己有写个玩，隧道和用户是不限制协议的：
https://github.com/lesismal/pipe

拓扑就是 user -> pipe client （相当于 tunnel client ）-> pipe server （相当于 tunnel server ） -> app server 。

默认带了 cmd/server 和 cmd/client 就是隧道走 websocket ，两端 TCP 。想定制协议的，import 这个包自己配置就可以了。

另外，建议 tunnel 中间去掉自动断线重连。
因为 web 类应用和长连接类应用（例如游戏、IM 、推送服务）不一样。
长连接服务如果断开了，就把两端的 user 、app server 端开就好了，因为应用的 client 端本身就应该处理断线重连逻辑、或者显示断开让用户手动重连之类的。去掉 tunnel 自己的断线重连，就不用担心他反馈的那个类似 ddos 的问题了。
tunnel 做短连接相关的隧道倒是可以考虑断线重连，但并不是必须的，比如浏览器自己就可以自动刷新或者由用户手动刷新重试。
当然，可以考虑做成配置项，让用户自己评估、根据他自己的业务类型是否真的需要配置是否自动断线重连。

@zanjie1999 好

问了下 claude ，OP 可以看一下：
https://gist.github.com/lesismal/416fc85ce25a9adc520e32964e0c52fa

> 怀孕期间，我多次和她沟通让学习，但是她每次都和我吵架，一直往后拖。到现在宝宝已经出生两个多月了，依然不学习，每次说到找工作

> 1. 我想让她上班的原因不是为了挣钱。现在我一个人的工资足够养活家人。是因为我俩都认为在家时间久了会和社会脱节。但是她这个人惰性比较重，需要催促才可以去做事（她自己清楚自己的缺点）。


Append 的解释好像 OP 初衷挺好的，但是主贴里说的可是怀孕到宝宝两个多月期间一直催人奋斗。

奉劝 OP ，做个人吧。

@xfgong

你贴没贴项目链接、star 重要不重要，是你的事。

我不需要你解释，我也没要求你解释。

对自己项目自以为是的语气，对别人回复不回复也要命令式的语气。

我就是看行文语气让人别扭不舒服，所以回复。
回复不回复是别人的自由，你也管不着——但是我不会要求你不要管别人回复不回复，因为这样表达也是你的自由。
如果我不再回复，也不是因为你要求不回复，而是不想浪费时间在你这，仅此而已。

行文语气，CubePlex 好像是个什么很牛很好很强的知名项目，但是我都没听过，好东西多、听都没听过属于正常属于我自己孤陋寡闻，所以花时间去看了下，结果，star 不多、非知名项目，我可是凭着支持的心态花了时间去看你的。推广也请在意一下用户感受可以吗？

都不开局自我介绍下，上来就煞有介事地 xxx 怎么怎么了。

想问一句：你谁啊？

> 不需要他的 seo ，你说的什么好玩的项目我不感兴趣，也不是你做的

@xfgong 可能我说的委婉，让你误会了。那我直接点讲清楚一些。

1. 你的这个帖子其实本质是 seo ，我不反感 seo 。你说你们前阵子开源了企业级智能体平台，我觉得你可以直接先发个帖子介绍你的开源，包括功能、优点之类的，比这种借题发挥的效果更好，我非常支持、乐意给 star ，如果确实很好，我也非常愿意分享给其他人。甚至我到你们仓库去看了，想研究下是不是好东西要不要试试看，但是没发现亮点，你主贴也不做更多介绍，这种 seo 就让人不大喜欢了，所以 #6 就不客气了、但是仍然保持了一些委婉。
2. “也不是你做的” —— 我也没说我放的那个链接是我做的啊，所以，搞不懂你是什么逻辑。和你主贴 seo 的逻辑类似，该重点说的内容你不说，盯着无关紧要的。本来看到这种，即使不喜欢，也就关闭页面、不打算评论，因为 py 我没兴趣，golang 的我可能看看、只要还行就给 star 。我放那个出来的意思是别人做的东西挺好、star 也很多了，这种我就愿意去花更多时间研究。你们 README 内容不够丰富、star 也少、而且你上来的口吻就好像是你们做的已经很牛逼了、是被 csdn 搞坏了似的。但是你项目的优点、强项在哪里啊？你倒是主贴或者 README 里细说一下啊！王婆卖瓜自卖自夸，自己张嘴就来是吗？因为你这种语气的正文，所以才不客气来评论的。
3. 提个建议，都 viber coding 了，做 agent 开发，就没必要用 python 了，性能差，工程型也差。

很重要：别用垃圾语言了，尤其是臃肿、性能差、投毒的那些。

本来 star 就不多，能被别人或者 csdn 自动去发 csdn 是免费给你 seo 了，没必要无奈。

现在这方面的东西太多，cubeplex 没看出有什么竞争力。多看看其他好玩的项目吧：
https://github.com/chaitanyagiri/munder-difflin

@theguagua

刚数了下，上面说错、不是 87 ，好像是 84 。。。应该就是#45 那个，三模，不是 mini ，现在好像才 1k 左右。mini 好像更贵？但是 mini 那个键位布局，就有点像 OP 说的问题 1 了、backspace 右侧一排，那种我也不习惯。

我最不爽的就是支架那个质感，因为经常要前后左右稍微调整下位置，那个支架就不友好、不丝滑、顶着、还容易塌。

最初用的时候，蓝牙好像不太稳定，要插 usb 的话怎么都占一个拓展坞的口，而且日常也就是同一个桌子上挪位置，所以干脆日常插线了。

键的手感确实舒服，不玩游戏，比机械舒服得多。

@aitaii #45 是真的爱 NIZ 这个颜值，希望它细节质感越做越好

NIZ 的 87 颜值和键程手感我都很喜欢，就是 @aitaii #45 发的那个，我个人也推荐。缺点是支架开合偏硬、支撑后的角度稳定度不如其他好键盘丝滑结实，而且支架本身也看着不结实，我都要小心翼翼开合、生怕开合时候它自己弹性把自己弹噶了。

Filco 的 87 我有一款黑的，青轴，键位布局和 NIZ 那个 87 基本一样，这俩都是比较规矩的布局，比如 '[' 、‘]’ 这两个是左右挨着而不是上下，backspace 、右 shift 也都不是 OP 描述的那样问题的。缺点是，上年纪了，青轴敲不动了，下次如果再买机械，要考虑茶轴了。

推荐 NIZ 。

@isbase #48 这个问题我不专业，我不乱回复