所以 ws 一直在发送进度？发送完之后再发送一个 html ？这个实现没啥问题，问题在前端要区分这 2 种消息。其实如果前端都能知道资源（ HTML ）就绪了，直接重定向到资源不就是了吗

打游戏可以。写代码视距太大了。眼球到处动

网页端？因为还有网页全屏。

反向代理是用户无感知的，Nginx 帮你完成请求。
你让 Nginx 返回 301 是可以，但 301 是给浏览器看的，你只能重定向到不同地址，否则明显 too many redirect

业务不行，性能来凑。预算不行，打回重做

chrome 是可以多用户互相隔离的。每个用户还能登录一个同步账户，浏览历史，书签等个人数据归这个账户。同时，每个用户还能登录多个谷歌账户，可以互相切换。

所以，人话就是
你的设备有多个自然人使用就应该设置多个 chrome 用户，无论是否登录或者同步。这样隔离了用户，浏览器插件都独立。

每个用户应该使用一个谷歌账号登录浏览器保持同步。同时可以登录多个 gmail，使用 sso 或者相关服务的时候可以自由切换身份。

楼主清理的是 chrome 用户，自然是清理了全部

接触不良？供电不足？

Google photo 有损画质其实没那么差
垃圾佬对磁带机非常感兴趣，存电影，照片

进指令缓存是程序，进数据缓存是数据。
就算是程序，也是先存后执行。但这段指令“数据”是程序

你把各种 token 用点.分割开，把第二部分用 base64 解码。里面就有过期时间

命令行快的前提是你记得命令，不记得参数可以现查。不记得命令不见得快多少。相比而言 GUI 门槛低多了，图形界面就是先进。

谷歌：恩？这年头还有人不登录谷歌账号，不同步密码？

github 不是私有仓库都免费了吗？
大文件可以用那个 resilio sync

jwt 本身的问题可以通过协议解决。saml, openid connect 等有回调域检测，cros 控制等加强安全性。
对于业务来说，jwt 声明了我是谁以及一些公开信息。放隐私信息是开发者的锅。当然 jwt 也用于角色权限控制，但防篡改机制已经足够安全，客户端不验签，不向鉴权服务器查询状态才是问题。

jwt 的好处是可以通过 refresh token 刷新，由客户端自行判断。在特定场景还能实现离线使用。

隐私真不是问题，能获取 token 都是能过验证的，密码，数字证书都 行。你自己提供的信息谈何泄漏？

瞎操心。厂家早就帮你想好了。行业标准早就制定好了