用户认证需统一接口路径与响应格式，sublime 集成 jwt 可实现 web 与移动端的统一认证。1. 接口设计：统一使用 /api/auth/login 路径，返回 json 格式，包含 code、message 和 data，并在 header 中添加 authorization 字段便于移动端读取 token；2. jwt 生成：使用 hs256/rs256 算法，设置合理过期时间，将用户信息写入 payload，中间件自动解析 token 并验证有效性；3. 兼容处理：移动端用 sharedpreferences/keychain 存储 token，web 端用 localstorage 或 cookie，并配置 cors 策略；4. 刷新与退出：使用 refresh\_token 换取 access\_token，退出机制通过 token 黑名单实现，移动端建议自动刷新逻辑以提升体验。
用户认证是现代应用开发中不可或缺的一环，尤其是在同时支持Web和移动端的场景下。Sublime 作为后端框架之一，配合 JWT（JSON Web Token）可以实现一套统一、安全且高效的认证机制。本文重点讲的是如何在 Sublime 框架中集成 JWT，并设计出适配 Web 和移动端的统一接口。
接口设计：统一路径与响应格式
无论来自移动端还是 Web 端，用户请求认证时应使用相同的接口路径，例如
/api/auth/login。这样做的好处是可以减少前后端对接成本，也能更好地复用鉴权逻辑。
- 响应格式建议统一为 JSON，包含状态码、提示信息和数据体：
{
"code": 200,
"message": "登录成功",
"data": {
"token": "xxxxx.xxxxx.xxxxx"
}
}- 登录接口需支持账号密码验证，也可扩展第三方登录方式（如微信、Google 等），但核心流程仍围绕 JWT 的生成与返回。
此外，为了方便移动端处理 token，建议在响应头中也添加
Authorization字段，值为
Bearer，便于客户端直接读取使用。
JWT 生成与解析：安全性与灵活性并重
Sublime 中可通过中间件或插件方式引入 JWT 支持。常用做法是在用户登录成功后生成一个带有过期时间的 token，然后返回给客户端。
生成 token 时要注意以下几点：
- 使用强签名算法，如 HS256 或 RS256；
- 设置合理的过期时间（通常为几小时到一天）；
- 将用户 ID 或用户名等关键信息写入 payload，避免频繁查询数据库；
- 可加入签发者（iss）、受众（aud）等字段增强控制能力。
解析方面，可以在每个需要认证的接口前加一个 JWT 验证中间件。它会自动从 header 中提取 token 并验证其有效性。如果无效，则返回 401 错误。
移动端与 Web 的兼容性处理
虽然接口统一了，但在实际使用中，移动端和 Web 端对 token 的处理方式略有不同：
- 移动端：一般采用本地存储（如 Android 的 SharedPreferences、iOS 的 Keychain）保存 token，在每次请求时将其放入 header。
- Web 端：可使用 localStorage 或 cookie 存储 token。如果是 SPA 架构，推荐使用 localStorage；如果是 SSR 项目，cookie 更合适，还可以设置 HttpOnly 提高安全性。
跨域问题也需要特别注意。确保服务端设置了合适的 CORS 策略，允许来自 Web 和移动端域名的访问，并正确传递
Authorization头。
刷新 token 与退出机制
JWT 是无状态的，因此刷新 token 和退出登录需要额外处理：
- 刷新 token：可以再颁发一个 refresh_token，有效期更长，用于换取新的 access_token。这个 refresh_token 应该存储在数据库中，并支持吊销。
- 退出登录：由于无法像 session 一样主动销毁，只能通过将 token 加入黑名单并在每次请求时检查是否失效来实现。
建议在移动端设置 token 自动刷新逻辑，比如检测到 401 响应后自动调用刷新接口，提升用户体验。
基本上就这些。整个流程不复杂，但细节上容易忽略，比如 token 安全传输、黑名单管理、错误码定义等，都需要提前规划好。
