多用户参考 google 的实现吧。

需要根据具体业务来确定，单页前后端分离应用如果 api 设计够好()的确可以做到完全由前端搞定。

比较推荐的还是 url 里面携带当前用户 id 用来解决新标签页打开链接丢失当前用户的问题。

算算车位和住户比例。

只感觉到硬盘涨价了...

@envylee #2 chrome 密码是加密保存的，但是是直接使用的 windows 加密方案。
也就是当前 windows 帐号下的程序都可以解密密码，其他用户就无法解密。

使用他人商标需要授权吧？

@OrangeM21 #1 +1 可以实时显示 console 输出。

看起来是单机就能撑住？
那么 docker compose + jwilder/nginx-proxy 解决。

@hirasawayui #33 放到碗里加热水，然后微波炉加热。

自己下载同一游戏，开启抓包程序后运行游戏，将抓到的 ip 封禁。
再次重试一遍，防止存在备用 ip。

或者用 netstat -anb 查看游戏建立的连接，屏蔽对应 ip。

没办法吧，

虽然浏览器有指纹识别方式(字体、canvas 等等)，但是并不可靠。

@glouhao #11 经常换的普通公网 ip ？
应该不行，我印象中 dns ns 缓存时间是 24 小时...

如果不存在负载，那么保持这份乐观挺好。
但是现在是在借债为生，那么真心建议去看下心理医生调整下心里。

推送问题不是常识吗？

苹果系统本身有统一的推送机制，android 也有系统级别的统一推送机制。

但是国内墙的问题使得这个机制无法工作，然后各个应用就使用各种手段常驻后台维持自己的长连接推送。各个程序都在台运行会造成严重的耗电问题，厂家为了解决这个问题各种杀后台进程，进程被杀后程序自己的推送机制当然挂了。

几年前曾经实现过 android 推送，算是明白 app 和厂家之间的相爱相杀。

android 锁屏一段时间后，cpu 会关闭，这时候即使 app 没被杀死也无法工作。虽然 app 可以强制 cpu 不关闭，但是耗电会很高，除了极少数特殊用途 app，其他 app 敢这么干是等着被卸载。
那么只能选择定时唤醒 cpu 去维持自己的推送通道，不过 google android api 文档上面写的很清楚的定时器 api 实际工作并不是那么可靠。
厂家为了解决各个 app 为了维持自己的推送通道不断唤醒 cpu 造成耗电加剧问题，当检测到 app 执行太多的唤醒操作后就不会在唤醒 app 了，app 无法唤醒会造成长连接被关闭当然会造成推送失败。

即使手机提供了白名单等功能，实际测试看起来也是无效，当执行太多唤醒时 app 会进入黑名单，定时器完全不工作了。

当时围绕着能够唤醒关闭 cpu 的各个功能查了一遍，最终找到了一个网络唤醒 cpu 的方式。即服务器发包，基带收到数据后会唤醒 cpu，android 系统会将数据传输给 app，这样就避开了定时器不允许运行太多的问题。
但是如果这个长连接因为各种意外断开，那么 app 就无法被服务器数据唤醒了，只能等到下次屏幕开启等广播或超长定时器唤醒后重建长连接了，这就是推送延迟。

@mewpoi #2 不知道 iphone 的，android 的分两个，一个是外包的碎屏险，协议上面强调了可以是第三方维修，实际几次都是原厂售后维修；另一个是京东自营的碎屏险，强调了绝对是原厂售后维修。

分母

额，
没人细看吗？

大概查了下，google 认为目前 webRequest 串行执行各个扩展的会影响速度，所以新版本扩展禁止了 webRequest 的修改请求功能。

这样做会使得目前使用 webRequest 进行广告拦截的扩展无法工作，所以 google 增加了 chrome.declarativeNetRequest 广告拦截专用的接口。这个接口兼容于目前的 A ​​ dblock Plus 的过滤规则，但是对于其他更复杂的拦截规则不支持。

实际最受影响的是其他类型的扩展，例如一些扩展会修改请求的 useragent、cookie 等，这些扩展以后会无法工作了。

@Tumblr #7 那是接错了，单开五孔的开关内部开关和插座是独立的，互不干扰。

看怎么算人数了，如果用过的就算，那么 js 应该会是最多的。
后端最少也写过几个网页吧。