@stoluoyu 试了 md 和 native 两种编辑器，都显示不出来

可以试试 Tauri ，比 Electron 小很多

@zisen 直播这块没有了解过，不太清楚

如果有录直播+上传的需求，也可以康康这个 https://github.com/ForgQi/biliup

@walpurgis

可以问一下这个图是怎么作出来的吗，有啥工具还是自己画的，感觉很好看😂

这和二八定律有什么关系，楼主意思是真理掌握在 20%的人手里吗

@mitu9527 算了算了，不说了。如果你能明白 Basic username:password = OpaqueToken = sessionId = 等于你说的 jwt 里存用户 id，都是一种用户标识，都需要再次查询才能获取用户信息，你就知道你这种方案只是重新发明了一遍服务端会话，本质上是一种东西。

@mitu9527 你说的这种方式不可避免的要用到”any stored context on the server“，否则怎么验证用户的参数是否合法，他发过来一个管理员角色，你这种方式能在”cannot take advantage of any stored context on the server“的情况下验证他是不是管理员吗，但是 Jwt 可以做到

“大家公认的 Authentication: Basic username:password 这种是 RESTful 的”
=========

而且你能讲出来这种话我也不知道说什么好了。请你看一下你发出来原文好吗"and cannot take advantage of any stored context on the server." 你是不是不理解什么叫 any stored context on the server.

@mitu9527 感觉你可能没有实践过任何一种认证方式。你说的用法才是典型的有状态，依赖于用户标识查询用户然后验证参数(除非你选择不验证，否则必须得查询)。jwt 是为了资源服务器能在本地离线验证用户设计的，所以不需要保存或者同步会话的操作，只需要解析 jwt 就能获取到用户信息，这种服务器才可以随时且独立的伸缩，你说的那种情况随着资源服务器的伸缩，数据库、缓存或者认证服务器都需要同步伸缩，否则就会遇到单点问题。

@mitu9527 我看了你说的后一种情况，我感觉你是没理解这里说的无状态是什么意思。你后面讲的这种情况就是 OpaqueToken 或者 sessionId 的用法，这才是这个上下文里面说的有状态的情况。如果别人发一个用户标识来，你为了验证参数是否合法，不可避免的要和数据库、缓存或者认证服务器交互查询出来用户信息，而 jwt 就是为了减少这部分的查询设计的，可以在服务端离线验证减少不必要的查询。

@mitu9527 如果服务端不保存这个状态，那如果用户换了设备呢，或者重新登录。客户端的数据此时都没了，难道让用户重新再选一遍，这个时候不应该由服务器返回历史数据吗

@mitu9527 楼主你这里描述的不是一种业务实现吗，和是不是服务端生成的没有关系。你讲的这个例子是让用户自己选择角色，那按你讲的翻过来的情况，由服务端生成，服务端怎么生成呢，服务器又不可能提前预知用户要选什么角色