当然，并不是说完全否定这种模式，如果有这种不太严谨的业务场景，那用用倒也无妨。

本质上来说，其实就是分了两种状态。
在日常状态下，将 client side session 的 session data 作为 server side session 的 session id 使用。

在 Redis 挂掉等奇怪的状态下，退化为完全使用 client side session 机制。

@xiadada
所谓 “一定不挂”，其实对应的是 “ session 管理未必生效” ，这是非常不严谨的。

如果你做了 session 管理功能，就不应该让它处于一种不确定是否能用的状态。

从这个角度来看，如果 Redis 挂了，那理应将整个 session 认证部分停掉，而不是 “带伤上阵” 。

对于一个已经稳定运行的系统，维护者需要听到的是 需根解损 。

需要性
为什么要对现有系统做修改？
目前的系统是否满足使用？
现有系统是否已经引发了某些问题？

根属性
这些问题是否是未修改的点引发的？

解决力
进行修改是否能解决以上问题？

损益比
进行修改需要投入哪些成本？
进行修改是否会引入其它风险？
为了这些问题，是否值得投入这些成本？

我猜测楼主的思路是：
使用 JWT 做基础的鉴权，同时使用 Redis 做补充管理（例如通过黑名单的方式提前吊销某 token ）

但这样其实抛弃了 JWT 或者说 Client side session 的不少优势：
Redis 的引入导致需要依赖服务端。
服务端的引入导致需要专门处理 session 共享。

以及，如果想实现完整的生命周期管理，黑名单未必够用，可能需要引入白名单，此时这个方案实际上已经变成了 Server side session 了。

唔… 提问一下，自己做这件事和靠 nginx 来做这件事，会有哪些差异呢？

避免被误解，补充一下，上面那句话是说回帖的某些朋友…… 不是在说楼主。

现在体会到为什么中学要学一些基本的经济常识了……

已经使用妙触板 4.5 年，感觉良好。

macOS 场景下我目前完全不使用鼠标。

疑似关键词：
发（呵呵）车 特朗（呵呵）普

电池是个问题，之前挂 GoPro 出门，要带四五块电池才够用就很烦

我还蛮喜欢爬虫类的事儿的，与人斗其乐无穷~

emmmm 介绍两个产品给楼主：

https://sonderdesign.com/

https://www.nemeio.com/

@Immortal
我觉得楼主这里提到 HDMI 还是挺合适的。

HDMI 正好属于 『大家都觉得它是热插拔的，但其实未必是』。

楼主其实就是想验证一下 type-c 是否也是这样。

@phpfpm #22
对，我说的 1 的数量其实就是 bit count
不过大部分环境下都有对 bit count 方法做了优化的原生方法，刚才忘了说了……

上次搞这个事儿大概是 4 年前了，所以忘了好多细节 =。=

从楼主的描述来看，我觉得你需要先确认下你想要提取的东西是否真的是个网址，万一是原生页面呢？

以及，X-Y Problem 预警 ：
https://coolshell.cn/articles/10804.html