其实 sessionId 就是一种 token，只是通过 token 获取 session 数据 的操作由 web 框架做，而且一般将 sessionId 保存在 cookie 里，session 数据保存在 web server 里
因为 session 保存在 web server 里，当有多个实例时，需要同步各节点的 session，或者把 session 保存在数据库里（比如 spring-session ）
因为 sessoinId 保存在 cookie 里，所以当客户端不支持 cookie 机制时，这套东西就没法用了
也因为 sessionId 保存在 cookie 里，所以可以使用浏览器自己的安全机制，比如 http-only，same-site 等
还是因为 cookie，所以对于前端是透明的，不需要自己管理，发请求默认带着（可能有跨域问题）

> 如果一个前端页面包含多个请求，每个请求都需要鉴权数据库压力不是很大么
相当于每次请求多一次查询，必然走索引，压力不大

> 解决是不是可以用 redis 集群做信息缓存，但是这样和传统 session 操作方式不是类似么
用 redis 可以提高性能，还自带过期时间机制，emm，本来就是 token 拿 session，就是一样的，区别是谁做怎么做

> 所以说 token 和传统 session 优势是什么，token 概念上是无状态，但是不可能真的把用户所有信息都存上呀
可以在浏览器之外的环境使用，而且因为全部自己实现，一些操作更方便（比如检测 token 状态，废掉某些 token ），用 JWT 可以在 token 里带数据，但也会带来额外的复杂性，需要自行评估使用

mater 2s 蓝牙，打魔兽打炉石打 cs 都没啥问题
5g wifi，同时连着 k380 键盘 和 蓝牙小音响 和 xbox 手柄，都没问题

java 农，表示啥时候 go 也有个全家桶的框架再去玩

体积小，功能少，占用资源低

@SekiBetu #22 所以成为低效程序员了啊

ideavim 路过。。。
感觉自己的听力水平不支持这个视频。。。

@kop1989 何必呢，忽略主题就完事了

不懂 go 的 java 农表示：
项目简单的话，把所有逻辑放一个文件里也没事
项目复杂的话，分层可以降低理解难度，更容易维护
这套路哪来的我不知道，但是我觉得还挺合理的
有的时候一个不复杂的功能我也会老老实实分层，有时候一个很复杂的查询我会直接塞进 controller，具体情况具体分析吧

看看 mysql 慢查，看看有没有相关的查询（可能没有）
可能是应用和数据库之间的网络出了什么问题
或者应用的连接池配置有问题
或者是有其他的慢查询拖住了连接池导致后续请求要排队
可能的点很多很多，慢慢查吧。。。

说明还有折腾的精力
隐藏 dock 栏，spotlight 搜索开应用，图标啥样已经无所谓了

> 我想请问下，像 http 这种其实本质就是重新规划 tcp 数据报中有效数据载体部分空间是吗？

不是，HTTP 只管把数据交给 TCP，或者拿 TCP 收到的数据，至于 TCP 到底怎么收发数据，HTTP 管不着

吃瓜围观的时候感觉紧张刺激
自己要背锅，客户一遍一遍催，领导一轮一轮骂的时候就完全不一样了

不是对重复文件的优化，是实现了“写时复制”机制优化了复制操作

不需要，日常用软毛刷干掉灰尘，用软布蘸水擦干净即可

大学里刷题环境那么好，多刷一刷锻炼锻炼脑袋挺好的
不刷题其实也没太多正事能干了是不是。。。

beetlsql 的这个机制应该是用 serializedlambda 实现的，但是目测 kotlin 的实现方式是匿名内部类，于是无解，换 java 写吧

参考这里： https://discuss.kotlinlang.org/t/how-to-create-a-serializedlambda/8502/4

直接把 excel 所有内容读出来做一个字符串保存然后搜索怎么样？

需要了解如何实现低代码开发的业务流程，然后才是技术实现