@shanghai1943
我们用户数还没到负载那部分。。可能给不了什么有效建议，一台服务器正常也能撑个几万连接数了。
我可能没看仔细你的问题，热加载对于跨不同服务器，好像是没什么特别的帮助，socket 都断开了。
这种案例，以前网游服务器集群挺多的，可以考虑参考一下。

@shanghai1943 我们的 ws 模块是插件化接入到 web 服务器，所以热加载比较容易。
你们 nginx 热加载应该也是可以的，可能后端没吃透这块。
为了用户体验考虑，强行踢下线感觉肯定不好。如果后端实在太菜，你们前端可以加个状态恢复功能，在无感知情况下让用户重连。（正常 websocket 断开和踢用户下线走两个不同的初始化路由）

@shanghai1943 我们的服务器都是热加载更新的，只要机房不掉电，用户 ws 就不会断线，完全不存在你说的这种情况。

传统的 Cookie 挺好用的，然而我另辟蹊径，用的是 localStorage 存用户的 session 。
是为了兼容一些特殊的场景，我代码里面很多服务器推送，WSS 之类的，没发 HTTP 请求，也就没实时更新 cookie.

随便看了一题，十分钟内让我写一个完整的 render()模板渲染函数。
果然面试造火箭，进去后拧螺丝钉。

我也和楼主一样，转了一圈，什么都学了一点。回头还是感觉 C++最好，技术栈深不见底，能和摸鱼的同事拉开足够的技术差距。
C++就是一点，学习曲线比较离谱，只有坚持。等渡过最痛苦的磨合期后，会稍微好一点点。
至于钱，只要你有技术。招聘里 VUE 人人都能写一点点，可 C++绝对不是这一回事。有差距，就有钱。

是程序员思维的话，随手 5~10 分钟写一段代码，算一下 hash 就可以解决的问题。

简单看了一下 JD，有下面这些参数。
d: 03s0029nq3BQS9000001000g102001000h000001000j101001000e000001000g101000000h000001006l101000000b103001000h1040010...
c: c5b7bb1712a347d9a84998dc7b42dd24
w: 0
appId: 1604ebb2287
scene: login
product: bind-suspend
e: WBNPEK7FHYVGCTYUDSB4O5MO5LOZG5MALJQWPH6C6BGZPESVXB2J66SXYEFX26QQ654RBABHHR4CNA23UUERNDXTRM
s: 693759515443421745

第一个 D 参数特别的长，我也不知道为什么官方不用 16 进制，非要用一大堆 0 和 1 来表示，也许是这样看起来很酷。
具体参数吗，就是那些 nonce, 把密码散列化，非对称魔改算法。最后再加个 JS 签名验证防止非法篡改。都是百变不离其中。

就是防止中间人嗅探密码吧，https 传输的证书也不是完全可信的。密码不加密的话，万一本地被注入了第三方根证书，那不就验证通过，直接看到密码了。

我简单看了一下，微信官方 JS 是封装成了一个对象，利用 Long polling 服务器推送，来通知浏览器用户已经扫码。
Long polling 就好比客户端发送一个巨大的文件，服务器返回被卡住了，需要很长时间后才会返回结果，但又没有真实的数据进行传输。

同觉得 iPhone 不香。我不是纯粹的用户，我是开发者，喜欢折腾系统，安装自己写的 APP 。
除非只写 iOS 程序，否则平时用用，首选安卓系统。

这点预算可以买索尼了。

V 站果然前端同学居多，没用后端思维考虑问题。
我手机上那个装了一个 SSHD，然后 PC SSH 过去，直接调用命令行来操作手机剪贴板。这样的好处，是手机全后台操作，APP 都不用切一下。

我机顶盒是 armv7，可现在 google play 里强制要 v8 arm64，安装最新 apk 都没办法，好烦。

参考 websocket 协议，必须有包长度。
tcp/ip 强制把流切成一个个小包，是物理层需要。而你 IP 包的发送，必然会存在发送失败，导致过一会儿客户端重发的情况存在。
网络没有 100%的可靠性。所以你程序要健壮，就别假收到的 TCP 包是完整的，能直接处理，多做协议设计才是正途。