@LxExExl 网上的终究比不上现场的

@SSang 那就不纠结，只给 AccessToken ，JWT 格式，只存 GUID 或用户 ID ，以年为单位。等啥时候想存更多了，将这种存少了的 Token 直接返回需要重新登录就行了。

你可以躺，躺到被辞。

@SSang 存那么长时间我就不带用户信息了，直接用 GUID+有效期，你可以使用 JWT 让它可以自验证包括有效期，直接用 GUID 也无妨反正后端要验证 RefreshToken 。AccessToken 倒是可以使用 JWT 带上你想要的信息，但如果 API 每次都先去缓存里读一下用户信息的话，那么 JWT 中放不放倒是没太大意义了。

我是在 JWT 放了最基本信息了比如用户 Id/Email/类型，反正也只是比只存 GUID 大了一点点，我后台可以暂时每次都去验证一下（在缓存中也很快），等后面压力大了可以随时关闭不验证也是可以的。

生成两个 Token ，一个叫 RefreshToken 长期的，你可以在后台记录这个 Id 。一个是 AccessToken 短期的用于 API 请求，用 Freshtoken 去生成 AccessToken ，比如只给 48 小时。用 Refreshtoken 生成 AccessToken 时你可以检查这个 RefreshToken 是否注销了。这样频繁的请求用的是 AccessToken ，有效期短，可自验证。RefreshToken 使用频率低，可严格验证（比如退出后就在后端标记已注销，这样就无法再生成 AccessToken ）。

现在好多 API 对接都是这么设计的。

看来 OP 没写过 Angular ？自从 AngularJS 升级到 Angular 后项目就都转 TS 了。

或者 OP 直接参考 OSS 的大文件上传 API ，大致就是先建立分片上传任务，建立时传文件大小、摘要、分片大小、分片数量。然后前端开始像上传普通文件一样上传各分片（并标明分片 Index ），远程可保存分片为文件，最后一个分片上传完后触发远程合并，同时检验合并后的摘要是否匹配，不匹配就异常处理，简单弄就整个重新上传。复杂点儿分片也弄摘要。同时定期清理未完成的分片（比如前端放弃上传了而没有通知）。

最后一步合并的时候对比本地和远程的文件摘要，确保上传无误。建议一开始就上传摘要。

OP 你到底是想找 UI ，还是找画 UI 的平台，还是找人画。

平台我推荐 Figma

可能会不小心记录不可描述，然后用户开始抵触。

@soyojoearth 如果带有 Webhook 或 Push 功能的 Email 服务，那么就差不多成了实时聊天了。

好像有人说有之前有一个基于 Email 协议的聊天工具，OP 可以找找看有没有什么灵感。

你都不考虑访问速度了，那么肯定是 Github 了

我也就刚买电视的时候注意过 HDR ，下载过 4K 电影（ 30G 左右）。

现在我已经无视它了。1080P 尺寸和清晰度刚刚好，不管有没有 HDR 。

转眼疫.情都三年了

风控就风控，还整个多人举报。。。