经过一段时间的摸爬滚打，慢慢摸索出一套比较好的解决方案（就目前来说）
只能个人自用，多人公用会出现各种奇怪的问题，并且程序里加了锁只能一个接一个对话
（已找到方法解决这个问题，目前支持多人用不同的 accessToken 共用一个代理，但是如果是相同 accessToken 的话，还是会提示 Only one message at a time. Please allow any other responses to complete before sending another message, or wait one minute.，更新了视频在最下方）
java-chatgpt-api 这边换成了 Playwright，开发测试会方便点，当然也是第一次用，好多 API 还用不明白，总之感觉挺强大的，如果前端玩得好，使用起来能更加得心应手
Java 版本的话，又 JVM、又 Spring、又 Playwright，跑起来非常占用内存，跑着跑着内存就占用 1G+ （可能泄漏了），适合本地部署
go-chatgpt-api 的话则还是依赖外置代理 chatgpt-proxy-server，因为测试过 playwright-go，Firefox 版本太低跑不起来，而 Chromium 能跑，但是过不了验证
Go 版本内存占用仅需十几兆，外置代理几百兆，加起来比 Java 能少一半，适合最低配 1 核 1G 服务器（当然也适合本地）
其中官网里的一旦对话超过 max_tokens，就会自动截断，需要发继续才能回复，这里被我魔改成了后台自动发继续请求，前端只需回车，全部内容一次性返回（可能有 bug）
Java 那边依赖 Playwright 特性做了个处理验证码失败自动截图的功能方便排查，Go 这边则没有
其他的功能差不多相同，核心处理基本一样，具体实现方式可能有点差别
闭源代理见仁见智，涉及到 apiKey 或者 accessToken 安全
我这边的实现还是一种不是非常稳定的方式，不一定能完美解决验证码问题，也不一定正常使用无 bug
但是勉强能用，如果不行了，重启一下服务，大概率又复活，有问题我也会尝试修复
说句题外话，我说全部代码开源，有人质疑我提供的 docker 镜像把自己的闭源的二进制 go-chatgpt-api 文件打了进去，害怕有后门
我想说，其实你可以自己打包
我这个是代码提交后 github actions 自动打包推送到 docker 仓库的
换句话说，开源的代理关心 token 安全，反手把自己的 token 往其他人搭建好的闭源代理里送。我不理解
饭圈文化渗透到技术圈
如何使用、调试，全在视频里了