我是 php/java 转 go 用着感觉很爽
php 能实现的 go 都能实现,php 不能实现的很多 go 也能实现
最基础的一点,go 直接解决了 php 的性能和常驻问题两个大问题,我个人非常在乎性能问题,当同样的接口转 go 后相应从几十毫秒下降到 1-3 毫秒,成就感无法替代,虽然也用过 phalcon swoole 等框架,但是说实话非常蹩脚,而且生态太脆弱了,实在难以继续
还有个问题就是写 php 多了会越发觉得 php 底层的随心所欲, 历史坑太多

我个人觉得 cli 运行的 php 才是真正的 php,如果 php 从诞生开始就专注于丰富 cli 生态(例如 webman 这样的框架早点出来受到认可大家都陆续丰富其生态), 说不定现在局面会好很多, 不过现在想这些也晚了

仅从安全性上来看,用随机生成的 token 的 hash 值校验,确保其他人看到源码也无法利用的话,我觉得是没有安全风险的 只是流程不合规

@5sheep 对这里其实有一点吹牛，只是找到了对方的对应区而已然后部署到同一个区，估计只经过了一两个交换机转发，ping 值只有 0.x 毫秒 四舍五入约等于本网了

@zhulixin 好思路 下次我也试试

抢购其实没程序员想的那么简单,很多时候是经验问题而不是纯粹的技术问题
以前帮人抢购场馆,同一 token 下将并发控制到了极限-刚好不被拦截的地步,为了尽量低延迟将程序部署到腾讯云同机房同网段遍历到了内网地址直接发请求,记得当时单请求响应已经到了 2-5 毫秒级别,我以为稳了,结果还是抢不赢别人
后面复盘,怀疑对方已经将请求优化到了微秒级别,简单来说,假设平台放号是 1700000000.000000 这个时间点, 竞争对手有可能在选择 1699999999.999594 这个时间点发出请求,到达服务器的时候就能刚好抢到一张,而我的请求.000000 才开始发出,已经严重落后了,后面我又进行了小范围的提前请求,也没有成功,这种情况的话就需要长期的测试积累了,通过估算精确到一个极致才能保证领先,因为嫌麻烦就放弃了

当然还有个可能平台直接内定了,这种情况更加不是技术能搞定的..

估计音视频流是分开处理的吧,远程桌面本身就不是用来远程娱乐用的,实时性方面肯定无法保障
可以试试一些专注于游戏领域的远程方案,例如 parsec 之类,之前和朋友同城玩游戏延迟挺低接近本地

确实经验还不够,这种 bug 在正常水平开发者手里应该活不过 2 小时,像这类平台类参数错误第一反应不是应该对比同参数签名的结果值是否一致么,逐一排除干扰因素一下就找到问题了

只有试试 root 然后强制修改系统设置

@cici20jerry 群..发? 你自己给自己邮箱发邮件 跟群发有什么关系

@haleyJen 其实咸鱼不存在售后不靠谱的问题

因为压根没售后 🤪

server 酱就是,除了这个还有各种酱
不过我还是喜欢邮件推送,最稳

@liangguge696 用的这个 https://github.com/yeyupiaoling/PPASR 免费模型已经足够媲美一般的商用服务 够用了

自己。。做？应该是自建服务吧，建议再沟通下，如果是指自建我觉得没什么大问题，现在人脸检测模型也比较成熟了，部署不难，自己部署的话真多多种复杂场景训练也更方便
感谢 ai 内卷时代普通团队也有很多选择，我们有个小服务音频识别文字用的阿里云，每天 20 元，费用也不多但是不想忍受这种低水平服务还被收费遂内网自己安了个，效果基本一致，日花费 5 毛电费，虽然省的不多但是心里舒坦了

@totoro625 条条大路通罗马 我也只是提供一个更新思路 毕竟签发这块 acme 已经很完善了

https 不用担心,ssl 的可靠性还是很高的,对方最多能获取到你域名,消息无法解密

如果你是全等查询,那 md5 作为索引是正确的,速度几乎不受多少影响 即使是亿级表也在 1-10 毫秒级

很不错 适合临时用用很方便

别的不说,看到你有个想法很快就实现了,执行力先赞一个,我现在最缺这个