1. 在本项目中如何判断 refreshToken 是否过期？
参考答案：
在本项目中，如果实现了 refreshToken，一般会在生成 refreshToken 时设置 exp（过期时间）字段。
- 判断 refreshToken 是否过期，主要依赖于后端在校验 refreshToken 时，使用 JWT 的
verify方法。 - 例如在
utils/JWT.js中，JWT.verify(refreshToken, secret)，如果 token 已过期，会抛出异常。 - 中间件或接口（如
AuthMiddleware.js或专门的刷新接口）会捕获该异常，返回 401 或 403 状态码，提示前端 refreshToken 已失效。
2. refreshToken 过期后，前端和后端应该如何处理？
参考答案：
- 当 refreshToken 过期时，后端会拒绝刷新 accessToken 的请求，返回 401/403 错误。
- 前端收到该错误后，应清除本地存储的 token，并跳转到登录页（如
web-admin/src/views/Login.vue），提示用户重新登录。 - 这样可以防止用户在 refreshToken 失效后继续访问受保护资源，保证安全性。
3. 项目中 refreshToken 和 accessToken 的区别是什么？各自的有效期如何设置？
参考答案：
- accessToken 用于访问受保护的 API，通常有效期较短（如 15 分钟~2小时），以减少被盗用风险。
- refreshToken 用于获取新的 accessToken，有效期较长（如 7天、30天），只在刷新 accessToken 时使用。
- 在本项目中，accessToken 的生成和校验在
utils/JWT.js和AuthMiddleware.js实现，refreshToken 若有实现，也会在JWT.sign时设置更长的expiresIn。 - 例如：
JWT.sign(payload, secret, { expiresIn: '7d' })生成 refreshToken。
4. 项目中如何安全地存储和传递 refreshToken？
参考答案：
- refreshToken 建议存储在 httpOnly 的 cookie 中，防止 XSS 攻击（本项目如为 SPA，可能存储在 localStorage，但需注意安全风险）。
- 前端请求刷新 accessToken 时，将 refreshToken 作为 cookie 自动发送，或放在请求体中。
- 后端接口（如
/api/refresh-token，可在controllers/admin/UserController.js或类似文件实现）校验 refreshToken 并返回新的 accessToken。 - 项目中可在
web-admin/src/utils/request.ts里实现自动刷新逻辑。
5. refreshToken 机制在本项目中的安全注意事项有哪些？
参考答案：
- 设置合理的过期时间，防止 refreshToken 长期有效被盗用。
- 存储安全，优先使用 httpOnly cookie，避免 XSS。
- 刷新频率限制，防止接口被刷爆（可结合
middleware/BruteForceProtection.js实现防爆破）。 - 登出时清除 refreshToken，前端登出时应清除本地 refreshToken，后端可将其加入黑名单。
- 单设备登录，如需支持，refreshToken 可与用户设备绑定，后端校验时比对设备信息。
