现在 session 是主流还是 jwt + refresh token 是主流？

zhouhuab · 2026-04-04T06:04:33Z

徘徊了好几年，看了好多文章，也问了 chatgpt ，现在想看看生产中用到都是啥？

Session

jwt

token

35 replies • 2026-09-17 00:30:03 +08:00

crysislinux

Apr 4 via Android

1

中大厂肯定是后端 session

w568w

Apr 4

2

我没搞懂这两种方案有什么区别吗？ jwt + refresh token 不只是 session 的一种实现方式么。

gitrebase

Apr 4

3

refresh token 感觉更多用在开放平台 API 的认证/授权上，如果只是正常的用户登录流程，就用 session 就好，但感觉两者之间也没什么技术复杂度的差别，熟悉哪个用哪个就好

bwijn

Apr 4

4

claude 是主流

blushyes

Apr 4

5

@w568w 一个是有状态一个是无状态。

diudiuu

Apr 4

6

自己控制上两个结合

yungo8

Apr 4 via Android

1

7

这种最佳实践的只能大佬们回答了，说实话，有多少人是做过手机中那些常用 app 保持登录状态，最多也就是对接登录点一下。本人搞的登录，不好意思，就一个 token 走天下，没有 refresh token ，过期了麻烦用户再登录🐶

way2explore2

Apr 4

8

看需求了，APP 多 JWT + Fresh
Web 多用 Session

craftsmanship

Apr 4 via Android

9

@yungo8 保持登录状态这个我觉得可以请 @Livid 来讲一下 V 站的设计作为参考

w568w

Apr 4

10

@blushyes 我理解现在很多 JWT 的实践其实是综合的，JWT 本身不会携带全部状态信息（可能只有个 id ），实际的鉴权和状态提取还是在服务端完成的。

毕竟无状态就不可 revoke ，这个风险太大了

liuxu

Apr 4

11

oauth2

onedge

Apr 4

12

@yungo8 简单粗暴

onedge

Apr 4

13

@way2explore2 web 现在也是 jwt+refresh

poly1911

Apr 4

14

jwt

jadeborner

Apr 4 via Android

15

当然是 session,我经常把 cookie 导出到另一台机器用，省得再登陆一次

streamrx

Apr 4 via iPhone

16

单个客户端种类就 session

imnpc

Apr 4

17

前后端分离 JWT+ token 不分离 session

fovecifer

Apr 4

18

我觉得你把概念搞混了，我觉得应该是中心化的管理方案和去中心化的管理方案

leegradyllljjjj

Apr 4

19

两种都用了是什么水平

Rache1

Apr 4

20

看过这么多任务机器人、代挂脚本之类的东西，就能看出来，第一方的话大厂们都还在用 Cookie 那一套，如无必要，勿增实体

Bingchunmoli

Apr 4

21

混合 jwt+session 算什么，还有看见很多大肠的 token 不是标准的 jwt 是用了自己私有算法还是什么其他的，jwt 确实太长了

ZeroDu

Apr 4

22

用最简单的方案，生成的 uuid 然后存到 redis

netnr

Apr 4

23

同时支持 Cookie 和 JWT

zed1018

Apr 4

1

24

@w568w #10 JWT 设计思路本身也是不支持 revoke ，要 revoke 就得加黑名单，然后分布式服务各自要集中查询黑名单，那还不如一开始就不要用 JWT 。所以一般我理解的用 JWT 就不考虑 revoke ，而是把单个 token 时间给的足够短，然后 revoke refresh token 。

Oktfolio

Apr 4

25

大厂都还是 cookie + 随机字符串（ sessionid ）

giter

Apr 4

26

@Oktfolio 这么多年前就开发了的产品，使用 Cookie 或 Session 都正常。后面开发的项目基本都是双 Token 机制

BadAngel

Apr 4

27

今后不应该是阅后即焚吗

way2explore2

Apr 5

28

@zed1018 正解，

sunwangme

Apr 5

29

我自己现在更偏向按场景分，不会把 jwt + refresh token 当默认答案。

如果是传统 Web 、内部系统、或者 BFF 比较重的场景，我通常还是 session / cookie + 服务端 session id 。原因很简单：可控，能随时 revoke ，权限变更、强退、风控这些处理起来都顺手。

如果是多端客户端、开放 API 、跨域比较多，才更容易上 access token + refresh token 。但我实际落地时也很少做成“纯无状态 jwt”，最后还是会在服务端保留一层会话或版本校验，不然撤销登录和风控会很别扭。

所以我理解现在不是谁成了绝对主流，而是：
Web / 第一方业务：session 依然很常见
多端 / 开放场景：token 双令牌更多
生产里更常见的其实是混合用，优先选自己最容易控风险的方案。

yungo8

Apr 5

1

30

@craftsmanship 主张的网页端我没看出来。但是给第三方 app 提供的接口，手动创建的 token 是固定 180 天有效期的，具体见文档 https://www.v2ex.com/help/personal-access-token

v2Geeker

Apr 5

31

OIDC

uni

Apr 5

32

3 楼正解，api 用 jwt ，用户登录流程用 session 。我现在做的小程序，给小程序用的 api 用 jwt ，小程序的 web 后台用的 session

c3de3f21

Apr 6

33

真的有无状态应用吗，但凡上个 redis 都不算无状态吧

flytsuki

Apr 7

34

jwt 生成 token,redis 控制有效期

mmdsun

Sep 17 via iPhone

35

任何直接返回 web 前端 jwt 的都是严重的错误。jwt 只能对内，外部用分布式 session 方案。比如 spring session 注销多账号登录控制都可以搞定。

标答是：在网关层 TokenRelay 中继那种 gateway BFF 模式。你可以参考这个例子演示是 Oauth 2.0+ gateway bff 模式的 jwt

https://github.com/spring-attic/spring-authorization-server/blob/8db4a7db233799f53d03d9a7cec79a567af1ac1e/samples/backend-for-spa-client/src/main/resources/application.yml#L44