socket.io 相当于是 websocket 上层的包装，里面封装了心跳，协议降级（浏览器不支持 websocket 就变 polling ）
还有各种「应用级」的封装，比如 namespace, room 什么的，方便广播和管理。
另外还有利用 Redis 来连通多个节点的服务器，相当于 a 客户端连 A 服务器，b 客户端连 B 服务器，但是 a 和 b 之间依然可以经过 Redis 中转之后通讯。

总之用 Socket.IO 好处多多，而且 Socket.IO 也有各个语言 /平台版本的客户端，尽量用起来吧

纯 websocket 相当于就是一个 socket，只要是个 websocket 的客户端就能用

既然都叫他「黑苹果」了，体验能好么……

应该是 KeepAlive 把线程占了，BaseHTTPServer 默认单线程，可以开多线程模式的

口头 offer 肯定是不够的，正常至少要有个正式邮件通知
但也不是说这家公司一定在忽悠你，可能那个 hr 是老板的亲戚，也没做过真正的人事，只不过帮忙而已

你觉得这家公司好，你直接去报道好了，但保守起见不要拒掉其他 offer，要留一个后路
但个人认为，这家公司好的可能性不是太高，毕竟 offer 都是口头的。

只喝过金罐红牛和黑罐魔爪
个人感觉魔爪要刺激很多，晚上上高速前喝一罐顶好几个小时
回头再喝红牛就觉得没啥感觉了

Chrome 那也不叫明文，也是密文。
正常保存密码其实严格来说叫保存 hash 摘要，不叫加密保存。加密的数据一般总是有解密需求的。
浏览器保存密码肯定要解密为原文再发给网站，不可能发摘要给网站的，只要密码策略 OK，一般是没问题的。
至于网站自身肯定是首选保存密码摘要，除非有非常特殊的需求……

我觉得是能够「熟练规避各个云厂家坑」的运维

要是灭霸老家真是土卫六，还真一下子就没有 BOSS 的感觉了

应该是并发问题导致的
我也同意楼上说的不需要分 db，加业务前缀即可

如果一定要分 db，其实没必要每次 select，还不如按照不同业务数据建不同的 redisClient

一般服务器代码不会打包，不是所有 js 代码都需要打包的

前端代码打包主要是因为代码最终需要被浏览器下载到用户本地然后运行，
打包可以压缩代码，减少代码下载量，减少浏览器发送请求下载文件次数，一定程度上混淆代码不让别人很容易地看出代码逻辑

服务器都是自己掌管了，就没这个必要了
况且有些单机小项目，甚至有直接上服务器在线改代码的操作，不打包会方便一点

@lps 正解
都用 Node 了，websocket 肯定用 socket.io ，官方文档有明确介绍分布式部署时如何处理

详细可以参考：socket.io/docs/using-multiple-nodes 「 Using Node.JS Cluster 」章节

我觉得前后端各自都有展示层，并不冲突。
后端的展示层就是返回数据格式，同样一套数据可以输出 HTML、JSON、XML，包括结构细节都可以不同。
前端的展示层就直接是 UI 了，同样一套数据可以显示成表格、图表等等。

具体实现上要看业务，
如果你的一个后端接口对应前端的一个页面，那谁做都一样，或者说这根本无所谓前后端分不分离。
如果你的一个后端接口可以提供给前端各个模块使用，作为后端是有必要提供一些基本的输出选项的（比如数据格式、排序），当然前提是后端系统本身得自洽有意义

说到底还是一个职责划分的问题，出现这样的情况严格来说并不是前端或者后端的问题，是系统设计有问题，接口定义、指责和边界没有经验或者根本没想过。

这几辆车区别还是挺大的，看你需求和对车的看法
- 车只是代步工具，我不想多花钱 /精力在车上 -> 雷凌
- 要玩车 -> 思域
- 要个性并且不排斥自主品牌 -> 领克