@daijinming 可是反过来说，服务器端不能控制 jwt 前台存储时的生命周期啊。

这样写代码的话容易菊花不保啊。

无状态 JWT：JWT 中存储所有认证授权信息，服务端不存储任何相关数据。
有状态 JWT：JWT 中存储认证授权信息的 ID，具体数据存储在服务端。
Session / Cookie：传统的 Session / Cookie 存储方式，有几种实现形式：
签名的 Cookie 中直接存储 Session 信息，服务端不存储 Session 信息（与无状态 JWT 类似）
签名的 Cookie 中存储 Session ID，服务端存储 Session 信息（与有状态 JWT 类似）

你打算新造一个词吗？说说你的 session 的内涵和外延。说说你的会话的内涵和外延。

英语 session===汉语的会话

想起来那个笑话了，沙漠里的三个人，一个人的希望是金钱富贵，一个人的希望是美女享乐，第三人的希望是让那两个人来陪他。

我不管我自己过得好不好，但是我就希望大家和我一样或者比我差。

如果你是神，你的理想是让别人过得更好一些。。
理想是美好的，现实是残酷的。
更何况人心险恶。

肯定第一种，因为你的 key 是 String 嘛。

这都不走留着过清明节呢

可以说你的领导十之八九是知情的。
要么是想送你去吃吃苦回来好卖力，要么是往火坑推。
另外你在原项目大概是替补队员吧。
你先要求调回去。并表示好好干。如果不行。那就忍或滚。

应该是没有问题，但是实际上还是应该做，去除控制字符，并且分词然后查询

你的这种情况。用户 ID 是唯一的吗。当一个用户被删除了以后还可以创建同名用户吗？
如果不可以，那么就不可以表现的删干净了的样子。否则会导致人家死活创建不了用户，还不知道为什么。
假如可以。那新创建用户是不是一进去就继承了老用户的数据，怎么隔离？
这是其一。

其二，用户 ID 有索引，基本上查询是只读取索引区，根据索引区找到对应数据的地址，然后找到数据，接下来处理其他的非索引条件，SQL 预处理会这样干的。这样已经很快了。因为根据索引，你这里能找的数据量很小，可能就一两条数据，所以加不加删除判断对 SQL 文的快慢基本没有影响！

综上，你主要要看业务。业务逻辑必须自洽。

也有可能是你只看见你想看见的东西。
做程序员有门槛，做生意有门槛吗？

不管你去哪里，第一是要老大赏识你。不要说钱给得多就行，刚毕业半年你还是安心走稳技术路线。技术提高了还怕什么，此处不留爷，自有留爷处。
第二不要犹豫，千万不要骑墙。不要两头倒。不管你去了哪边公司，将来公司不行了，那你再找下家公司好了。

然后根据你的描述，如果 CTO 能把所有人带走，很大程度上也说明了人心所向。

autohotkey 我是这么干的。