文章目录1 同时支持浏览器和脚本使用2 方式一(装饰器)2.1 核心功能与流程解析2.1.1 统一认证装饰器(auth_required)2.1.2 浏览器登录流程(OAuth2)2.1.3 脚本/Token认证流程(JWT本地验签)2.2 整体代码3 方式二(分开路由)3.1 核心功能与流程解析3.1.1 网页认证路线(Session-based)3.1.2 API认证路线(Token-based)3.2 整体代码4 请求代码4.1 基于requests4.2 基于authlib分别使用装饰器和分开路由两种方式，让服务同时支持浏览器和脚本调用。然后分别用requests和authlib，实现了两种向API请求访问令牌(Access Token)并调用受保护资源的方式。1 同时支持浏览器和脚本使用现实中很多应用就是既给浏览器用、又给脚本调。比如一个管理后台，运营人员用浏览器操作，同时定时脚本用token批量拉数据。同一个/other接口支持两种认证方式，这个需求很常见。2 方式一(装饰器)这段代码实现了一个非常实用的“混合认证模式”。它巧妙地在一个Flask应用中同时兼容了两种完全不同的客户端场景：(1)浏览器用户：通过传统的OAuth2重定向流程进行登录，使用 Session/Cookie维持状态。(2)脚本/程序：通过HTTP Header中的Bearer Token进行认证，服务端进行无状态的本地JWT验签。这种设计非常适合构建既有人机交互界面（网页），又有机器交互接口(API)的通用后端服务。不管用户是浏览器登录的还是拿token调的，g.user里都有name，视图函数不需要关心来源。新增接口只要加一个@auth_required就行，不用重复写认证逻辑。2.1 核心功能与流程解析2.1.1 统一认证装饰器(auth_required)这是整个脚本的核心，它像一个智能网关，根据请求的特征自动选择认证方式：1、优先级A(浏览器Sessi