安全与认证面试题精选

Java 后端真实面试专题 · 安全与认证篇

真实面经里只要项目是 SaaS / 政企 / 中后台，必问 JWT、单点登录、多租户、权限、SQL 注入。每题三段： ① 标准答（讲透）→ ② 拓展（成体系带出关联点和必追问的）→ ③ 怎么接到你自己的项目。

年限标签：🟢 3年内　🔴 3年+

1. 🟢 JWT 是什么？结构和原理？

标准答：JWT（JSON Web Token）是一种无状态的令牌，由三段用点号连接：Header（算法）、Payload（用户信息、过期时间等声明）、Signature（用密钥对前两段签名）。服务端登录时签发 JWT 给客户端，客户端每次请求带上，服务端验签就知道身份，不用在服务端存会话。

拓展：

"JWT 安全吗？Payload 能放密码吗？"——Payload 只是 Base64 编码、不是加密，任何人能解开看到，所以不能放敏感信息；安全靠签名防篡改（改了验签就失败）。
"JWT 能注销吗？"——无状态导致主动失效难，常用方案：短过期 + refresh token、或用 Redis 黑名单。
对称签名（HS256）vs 非对称（RS256）。
签名校验至少要固定允许的算法、校验 iss/aud/exp/nbf 等声明，并拒绝过期或未来时间过大的 token；不能只“解码 Payload”就当认证成功。
HS256 要在所有验签服务间安全共享密钥，服务多时泄露面大；RS256/ES256 由认证中心持有私钥，业务服务只分发公钥，更适合微服务和密钥轮换。
JWT 不是加密协议，传输仍需 HTTPS；token 放在 URL 会进入历史记录和日志，通常放 Authorization: Bearer，浏览器场景还要权衡 HttpOnly Cookie 与 CSRF。

往项目引 ⭐："我项目用 JWT 做认证——登录签发 token、网关验签后把用户信息透传给各服务，服务端不存 session、天然适合分布式。敏感信息不放 Payload，注销靠 Redis 黑名单 + 短过期。"

2. 🟢 JWT 和 Session 的区别？分布式下为什么用 JWT？

标准答：

Session：状态存在服务端，靠 cookie 里的 sessionId 关联。分布式下多台服务器 session 不共享，要 session 复制或集中存（Redis）。
JWT：状态（用户信息）在 token 里、服务端不存，天然无状态，任何一台服务器验签就能识别身份，适合分布式/微服务。

拓展：

JWT 缺点：不能方便地主动失效、token 变大、刷新麻烦。
Session + Redis 集中存储也是分布式可行方案，看取舍。
移动端、前后端分离更适合 JWT。
选择不能只看“是否分布式”：Session + Redis 同样能横向扩展，且能即时注销；JWT 更适合服务间低延迟验签，但要承担 token 体积、撤销和密钥轮换成本。
Cookie 方案要设置 Secure、HttpOnly、SameSite 并配合 CSRF 防护；Header 方案要防止 XSS 窃取，前端存储位置是安全模型的一部分。
无论哪种方案，都应设置会话/令牌版本号，用户改密或封禁时使旧凭证整体失效，并记录登录设备与异常登录审计。

往项目引 ⭐："我项目是微服务 + 前后端分离，用 JWT 而不是 Session——无状态、任何服务实例都能验签识别用户，不用做 session 共享。只是注销和续期要额外设计（refresh token + 黑名单）。"

3. 🔴 单点登录（SSO）的原理？

标准答：一处登录、多个系统互通免再登。核心是共享认证中心：用户在认证中心登录拿到凭证（token/票据），访问各子系统时带上凭证、子系统去认证中心校验。CAS 流程是"重定向到认证中心登录 → 拿 ticket → 子系统用 ticket 换用户信息"。

拓展：

"JWT 怎么做 SSO？"——各系统共享密钥/公钥验签同一个 JWT 即可免登。
跨域 SSO 的难点是 cookie 不能跨域，常用 token 放统一认证域或 URL 传递。
还有基于 OAuth2 的 SSO。
更稳妥的 CAS/OIDC 流程会使用一次性 state（防 CSRF）和 nonce（防重放/混淆），子系统拿 code 在后端换票据，不把长期 token 放在 URL。
认证中心应维护全局会话和单点注销事件；只在各系统本地验 JWT 时，注销传播会有延迟，需要黑名单、短 TTL 或回调补偿。
SSO 的信任边界要写清：哪些系统是受信客户端、回调地址白名单是什么、用户属性由谁为准，不能只说“共享 token”。

往项目引 ⭐："我项目几个子系统用 SSO——统一认证中心签发 JWT，各子系统共享验签逻辑，用户登录一次、访问各系统免再登。理解'共享认证中心 + 凭证校验'这个核心就能讲清各种 SSO 方案。"

4. 🔴 Spring Security 的工作流程？

标准答：核心是过滤器链（FilterChain）。请求进来依次过一串过滤器：

认证过滤器（如 UsernamePasswordAuthenticationFilter / 自定义 JwtAuthenticationFilter）拦截登录或解析 token。
调 AuthenticationManager → UserDetailsService 加载用户、校验。
认证成功，把 Authentication 存入 SecurityContextHolder（ThreadLocal）。
后续授权过滤器做权限校验（@PreAuthorize、URL 匹配）。
未认证返回 401、无权限返回 403。

拓展：

"JWT 怎么和 Security 集成？"——自定义一个过滤器解析 token、构建 Authentication 放进 SecurityContext，实现无状态认证。
认证（你是谁）vs 授权（你能干什么）要分清。
SecurityContextHolder 默认基于 ThreadLocal，请求结束要清理；异步线程、线程池和消息消费线程不会自动继承用户上下文，必须显式传递并防止串用。
认证成功后应使用最小权限的 GrantedAuthority，并统一处理 AuthenticationException（401）与 AccessDeniedException（403）；不要把所有失败都返回 200。
JWT 过滤器要放在合适的 UsernamePasswordAuthenticationFilter 前，且对登录、刷新、健康检查等白名单路径明确放行，避免循环鉴权。

往项目引 ⭐："我项目用 Spring Security + JWT——自定义 JwtAuthenticationFilter 解析 token、填充 SecurityContext，再用 @PreAuthorize 做方法级权限。能把'过滤器链 → 认证 → 授权'这条线讲清就够了。"

5. 🔴 OAuth2 是什么？有哪几种授权模式？

标准答：OAuth2 是授权框架，让第三方在不拿到密码的情况下、被授权访问用户资源（如"用微信登录某网站"）。四种模式：

授权码模式（最安全最常用，如第三方登录）。
简化/隐式模式（前端应用，已不推荐）。
密码模式（自家应用，直接用账密换 token）。
客户端模式（服务间，没有用户）。

拓展：

授权码模式：用户授权 → 拿 code → 后端用 code + secret 换 token，code 一次性、token 不暴露给前端。
OAuth2 解决"授权"，OIDC（OpenID Connect）在它上面加了"认证"（身份）。
现代 Web/移动端优先使用“授权码 + PKCE”：客户端先生成 code_verifier，授权请求带 code_challenge，换 token 时再提交 verifier，能降低 code 被截获后的风险。
redirect_uri 必须与注册值精确匹配，授权码要短时、一次性；服务端保存 state 并校验，避免登录 CSRF 和 code 注入。
密码模式和隐式模式在 OAuth 2.1 中已不推荐；服务间调用应使用 client credentials，并给 scope 设置最小权限和过期时间。

往项目引 ⭐："我项目对接第三方登录（微信/钉钉）用授权码模式——前端拿 code、后端换 token 和用户信息。内部服务间调用用客户端模式。能区分'哪种场景用哪种模式'是关键。"

6. 🟢 双 token（access token + refresh token）怎么设计？

标准答：

access token：短期有效（如 30 分钟），每次请求带它，泄露了危害也小。
refresh token：长期有效（如 7 天），只用来在 access token 过期时换新的 access token，不参与日常请求。 access 过期 → 用 refresh 换新 access → refresh 也过期才要重新登录。

拓展：

"为什么要双 token？"——平衡安全和体验：access 短期降低泄露风险、refresh 长期避免频繁登录。
refresh token 要安全存储、可吊销（存 Redis，注销时删）。
前端要处理"access 过期自动用 refresh 续期并重试请求"（拦截器 + 请求队列）。
refresh 轮换时应“一次使用即失效”，保存 refresh 的哈希、设备和版本号；检测到旧 refresh 再次使用时，可撤销该设备整条 token 链，降低重放影响。
刷新接口要限流，避免多个并发请求同时刷新产生 token 竞态；客户端应使用单飞/请求队列，只让一次刷新成功后重放等待请求。
access、refresh 的存储位置要分开考虑：refresh 更适合 HttpOnly Secure Cookie 或服务端存储，日志、异常和埋点中不得打印完整 token。

往项目引 ⭐："我项目用双 token——access 30 分钟、refresh 7 天，前端 Axios 拦截器在收到 401 时自动用 refresh 换新 token 并重试原请求，用户无感知。refresh 存 Redis，注销时删掉实现吊销。"

7. 🔴 多租户 SaaS 的数据怎么隔离？租户 id 怎么透传？

标准答：三种隔离——独立库（物理隔离）、独立 Schema、共享表 + tenant_id（成本最低、最常用）。共享表方案的关键：

请求进来从 token 解析出租户 id，存 ThreadLocal。
用 MyBatis 拦截器自动给所有 SQL 拼上 where tenant_id = ?，业务代码无感知。

拓展：

"连表查询怎么拼租户条件？"——拦截器要解析 SQL、给每张涉及的租户表都加条件（用 SQL 解析库如 JSqlParser）。
"怎么防止串数据？"——所有租户表必须带 tenant_id、拦截器强制加条件、关键查询加测试覆盖。
跨租户的统计走单独的、显式带租户维度的查询。
隔离级别要按风险选：共享表成本低但最依赖代码和数据库约束；独立库/Schema 便于备份和合规，却会增加连接、迁移和运维成本。高敏租户可采用混合策略。
tenant_id 不能只靠 ThreadLocal：异步任务、定时任务、MQ 消费要在消息体或任务参数里显式携带，并在入口校验租户是否仍有效。
数据库层可用 RLS/视图/存储过程做第二道防线；上线前用跨租户集成测试、审计查询和“无租户上下文即拒绝”策略验证不会漏条件。

往项目引 ⭐："我项目是 SaaS，用 MyBatis 拦截器 + JSqlParser 自动给 SQL 拼租户条件，租户 id 从 token 解析存 ThreadLocal，业务层完全无感知——从根上防越权查到别家数据。连表时拦截器给每张租户表都加条件。"

8. 🔴 请求头里的租户 id 被篡改了怎么办？

标准答：绝不能信任客户端传的租户 id。正确做法是租户 id 从服务端校验过的凭证里取——把租户 id 编码进 JWT 的 Payload，JWT 有签名防篡改，改了验签就失败。服务端解析 JWT 拿租户 id，而不是读请求头的明文。

拓展：

这是"永远不信任客户端输入"的安全原则。
同理，用户 id、权限也都从校验过的 token 里取，不读前端传的。
即使请求头里的值与 JWT 一致，也要校验该用户对租户的成员关系、租户状态和当前操作权限；签名只能证明“由可信方签发”，不能证明业务授权。
网关透传用户信息时应使用内部不可伪造的头或重新签发服务 token，并在服务边界删除外部同名头，避免客户端伪造覆盖。
任务、批处理和管理员跨租户操作要走显式的系统身份与审计流程，不能用一个“万能 tenant_id”绕过隔离。

往项目引 ⭐："我项目租户 id 编进 JWT、靠签名防篡改，服务端从解析后的 token 取租户 id，不读请求头明文——所以不存在'改请求头串租户'的问题。这题考的就是'不信任客户端输入'的安全意识。"

9. 🟢 怎么用 AOP 做统一鉴权 / 自动鉴权注解？

标准答：自定义注解（如 @RequiresPermission("order:create")）打在方法上，用 AOP 切面在方法执行前拦截：从上下文取当前用户的权限、和注解要求的权限比对，没权限就抛异常拦掉。

拓展：

也可以用 Spring Security 的 @PreAuthorize，原理类似（基于 AOP）。
注解 + AOP 的好处是声明式、不侵入业务、统一管理。
要注意 AOP 自调用失效问题。
权限判断应采用“默认拒绝”：缺少上下文、注解为空、权限服务超时都不能当作放行；可缓存权限集合，但要有角色变更的失效机制。
切面只解决方法级授权，数据权限仍要在查询条件/Repository 层落实；否则用户有“读订单”权限仍可能读到别人的订单。
注解参数要避免直接拼 SQL 或表达式注入，审计记录应包含资源 id、决策结果和策略版本，便于追溯。

往项目引 ⭐："我项目用自定义 @RequiresPermission 注解 + AOP 做接口鉴权——切面里取当前用户权限和注解比对，无权限直接拦。业务方法上加个注解就行、不用每个方法写鉴权代码。"

10. 🔴 SQL 注入是什么？怎么判断和防范？

标准答：SQL 注入是把恶意 SQL 片段拼进输入参数、改变原 SQL 语义（如 ' or '1'='1）窃取或破坏数据。防范：

用预编译（PreparedStatement / MyBatis 的 #{}），参数作为值传入、不参与 SQL 解析——这是根本手段。
避免用 ${} 拼接；不得不用（动态表名/排序）就做白名单校验。
输入校验、最小权限数据库账号。

拓展：

"怎么判断有没有注入点？"——对参数构造特殊字符（引号、or、注释 --）看 SQL 是否异常，安全扫描工具（如 sqlmap）会做这事。
注入只是 OWASP Top10 之一，还有 XSS、CSRF 等。
预编译只能保护“值参数”，动态表名、列名、排序方向仍必须用枚举/白名单映射；不要用正则试图替代 SQL 语义校验。
数据库账号遵循最小权限，应用账号不应具备 DROP、GRANT 等管理权限；错误响应不要回显 SQL、堆栈或数据库版本。
安全测试应覆盖布尔盲注、时间盲注、二阶注入和批量接口；修复后用回归用例确认 ORM、报表脚本和管理后台没有旁路。

往项目引 ⭐："我项目查询全用 MyBatis #{} 预编译防注入；只有动态排序字段必须用 ${}，我做了字段白名单校验。理解'预编译让参数不参与 SQL 解析'才知道为什么 #{} 能防注入。"

11. 🟢 XSS 和 CSRF 是什么？怎么防？

标准答：

XSS（跨站脚本）：攻击者注入恶意脚本到页面，别的用户访问时执行（盗 cookie 等）。防：对用户输入/输出做转义、设置 CSP、HttpOnly cookie。
CSRF（跨站请求伪造）：诱导已登录用户在不知情下发出请求。防：CSRF token、校验 Referer、SameSite cookie。

拓展：

XSS 是"注入脚本"，CSRF 是"冒用身份发请求"。
前后端分离 + JWT（不依赖 cookie）能减轻 CSRF。
XSS 要按上下文编码（HTML、属性、JavaScript、URL 规则不同），富文本应使用经过审核的白名单 sanitizer；CSP 是纵深防御，不能替代转义。
CSRF 防护的 token 必须与用户会话绑定并校验来源；SameSite=Lax/Strict 是辅助措施，跨站业务和老浏览器要有兼容方案。
即使使用 Authorization header，也要防 XSS 窃取 token；CORS 只限制浏览器读取响应，不是 CSRF 或鉴权机制。

往项目引 ⭐："我项目对富文本输入做转义防 XSS、cookie 设 HttpOnly；因为用 JWT 放在 header 而非 cookie，CSRF 风险也低。能区分这两个常考的 Web 安全点就够。"

12. 🟢 用户密码应该怎么存储？

标准答：绝不能明文存，也不能简单 MD5（能被彩虹表破解）。正确做法：加盐（salt）+ 慢哈希，用 BCrypt / PBKDF2 / Argon2——每个用户随机盐、哈希慢（抗暴力破解），验证时对比哈希。

拓展：

"为什么加盐？"——防止相同密码哈希值相同、防彩虹表。
BCrypt 自带盐、可调计算强度，是常用选择。
传输层还要 HTTPS 防中间人。
哈希参数要可升级：保存算法版本和 cost，登录成功后可把旧 cost 的密码重新哈希；不要自行设计“加密后再 MD5”的算法。
登录校验要做恒定时间比较、失败次数/设备/IP 限制和告警，防止在线爆破；忘记密码流程使用一次性短时 token，而不是把原密码发回。
密码数据库泄露后仍要假设离线爆破，密钥、盐和哈希结果不能写入日志或埋点。

往项目引 ⭐："我项目用 Spring Security 的 BCryptPasswordEncoder 存密码——自带随机盐、慢哈希，数据库泄露了也很难反推原密码。绝不会明文或裸 MD5。"

13. 🔴 RBAC 权限模型怎么设计？

标准答：RBAC（基于角色的访问控制）核心五张表——用户、角色、权限（菜单/按钮/接口）、用户-角色、角色-权限。用户绑角色、角色绑权限，鉴权时查用户 → 角色 → 权限集合，判断有没有要求的权限。

拓展：

好处：权限和用户解耦，改角色权限就影响一批人，便于管理。
进阶：数据权限（能看哪些数据，如只看本部门）、字段权限。
还有 ABAC（基于属性）等更细的模型。
权限模型至少要有资源、动作、作用域三维（如 order:read:own），避免只按菜单控制而漏掉接口和数据层。
角色继承、拒绝策略和管理员自授权要有明确规则；高危权限可要求二次认证并记录审批人。
权限缓存必须有版本或事件失效，服务启动时也要考虑缓存未命中时的 fail-closed 行为。

往项目引 ⭐："我项目权限用标准 RBAC 五张表——用户绑角色、角色绑菜单和接口权限，前端按权限渲染菜单、后端用注解 + AOP 校验接口权限。还做了数据权限（按部门过滤数据）。"

14. 🟢 服务之间调用怎么做鉴权？

标准答：内部服务调用也要鉴权，避免被绕过。常见：

网关统一鉴权：外部请求在网关校验 token，内部服务信任网关透传的用户信息。
服务间用内部 token / OAuth2 客户端模式：服务自己的身份凭证。
内网隔离 + 白名单。

拓展：

"Feign 调用怎么传递用户信息？"——用拦截器把当前用户 token/信息加到请求头透传下去。
不能假设"内网就安全"，零信任趋势下内部也要鉴权。
用户 token 透传和服务身份要分开：服务用 mTLS/OAuth2 client credentials 证明“谁在调用”，用户上下文只作为业务授权输入，不能由调用方自行伪造。
透传链路应限制 header 大小、清理外部可控的身份头，并设置超时、重试和熔断，避免鉴权服务故障拖垮业务。
关键服务可再次验签和校验 scope，不要把网关的 200/放行结果当作唯一安全边界。

往项目引 ⭐："我项目外部请求在网关统一验 JWT，内部服务间用 Feign 拦截器透传用户上下文，关键服务再校验。这样既不重复登录、又不会因为信任内网而被绕过。"

15. 🟢 接口怎么防刷、防重放攻击？

标准答：

防刷：限流（按 IP/用户/手机号）、验证码、滑动验证。
防重放：请求带时间戳 + 一次性 nonce + 签名，服务端校验签名、时间窗口、nonce 是否用过（Redis 记录），重复请求被拦。

拓展：

重放攻击是把抓到的合法请求再发一遍，nonce + 时间戳能防。
关键接口（支付、下单）尤其要防。
签名串要固定字段顺序和编码，使用 HMAC/非对称签名并做恒定时间比较；时间窗口通常只允许几分钟，服务器时钟要做 NTP 校准。
nonce 要按用户/设备/接口隔离并设置 TTL，校验与写入必须原子（如 Redis SET NX EX）；幂等键仍需数据库唯一约束兜底。
限流应分层：边缘 WAF/IP、网关用户维度、业务资源维度；验证码是提高攻击成本，不能替代服务端授权。

往项目引 ⭐："我项目敏感接口加了签名 + 时间戳 + nonce 防重放——nonce 存 Redis 设过期，用过的直接拦；登录、短信接口再加限流和验证码防刷。"

16. 🟢 HTTPS 的原理？为什么安全？

标准答：HTTPS = HTTP + TLS。通过非对称加密协商出一个对称密钥，之后用对称密钥加密通信。握手时服务端用CA 证书证明身份（防中间人），客户端验证证书后协商密钥。既加密（防窃听）又验证身份（防冒充）。

拓展：

"为什么不全程非对称？"——非对称慢，只用来安全地交换对称密钥，后续用对称加密（快）。
证书链、CA 信任是防中间人的关键。
TLS 1.3 通常通过 ECDHE 协商临时会话密钥，提供前向保密；证书只证明公钥归属，不负责业务鉴权。
服务端应关闭过时协议和弱套件、配置 HSTS，并在证书轮换前监控过期时间；内部服务可采用 mTLS 双向认证。
HTTPS 不能防止应用层 SQL 注入、越权或 XSS，只保护传输过程；终止 TLS 的网关到后端链路也要评估是否需要再次加密。

往项目引 ⭐："我项目对外接口全走 HTTPS，敏感数据传输加密、靠证书防中间人。理解'非对称协商密钥 + 对称加密通信'就能讲清 HTTPS 为什么既安全又不慢。"

17. 🔴 什么是越权？水平越权和垂直越权？

标准答：

水平越权：A 用户访问到了 B 用户的数据（同级别，如改 URL 里的 id 看别人订单）。
垂直越权：低权限用户访问了高权限功能（如普通用户调管理员接口）。防范：每次操作都校验"当前用户是否有权访问这条数据/这个功能"，不只看登录态。

拓展：

水平越权要做数据归属校验（这条订单是不是你的）。
垂直越权要做功能权限校验（RBAC）。
多租户串数据本质也是水平越权。
资源 id 不能当作授权凭证：即使使用不可枚举的 UUID，也必须在 SQL 的 where 中同时带用户/租户条件，避免“先查出再判断”的竞态和旁路。
删除、导出、批量接口尤其容易漏校验；要覆盖 GraphQL、文件下载、缓存 key 和异步任务等非典型入口。
安全测试应分别准备普通用户、同角色其他用户和管理员三套身份，验证 401、403 与空结果的行为不会泄露资源是否存在。

往项目引 ⭐："我项目查订单详情时除了校验登录，还校验'这个订单是不是当前用户/租户的'，防水平越权；接口用 RBAC 注解防垂直越权。越权是很实际的安全漏洞，能说出两种区别和防法很加分。"

18. 🟢 敏感数据（手机号、身份证）怎么保护？

标准答：

存储加密：敏感字段加密存（如 AES），或脱敏存。
展示脱敏：返回前端时打码（138****5678）。
传输加密：HTTPS。
权限控制 + 审计：谁能看、看了记日志。

拓展：

加密要管好密钥（KMS）。
可搜索的加密字段要存一个哈希索引列来支持等值查询。
AES-GCM 等带认证的模式同时提供机密性和完整性；每条记录使用唯一 nonce/IV，密钥通过 KMS 分级托管并支持轮换，不能硬编码在仓库或配置日志里。
展示脱敏应在序列化/权限层统一处理，导出、日志、异常、缓存和搜索索引都要列入数据流盘点；哈希索引要加密或加盲化，避免被反查。
访问敏感字段要有最小权限、审批和审计，备份、消息队列和测试数据也必须遵守同样的脱敏策略。

往项目引 ⭐："我项目用户手机号、身份证加密存储、列表展示脱敏打码、查询用哈希列匹配，敏感操作记审计日志——符合等保和隐私合规要求。"

19. 🟢 你项目的登录认证整体是怎么做的？

标准答：串起来讲——登录校验账密（BCrypt）→ 签发双 token（access + refresh）→ 客户端带 access 请求 → 网关验签、解析用户和租户 id 透传 → 服务端从上下文取身份 → RBAC 鉴权 → access 过期用 refresh 续期 → 注销删 Redis 里的 token。

拓展：

这是一道"串场题"，把前面的点连成完整链路。
能讲清"认证 + 授权 + 多租户 + 续期 + 注销"整条线就很完整。
讲述时按“入口、凭证、上下文、授权、失效、审计、故障兜底”七步展开，并给出一次正常请求和一次失败请求的状态码。
登录成功后不要只返回 token：还要设置设备会话、刷新轮换、异常登录告警和注销传播；认证中心不可用时要明确是 fail-closed 还是有限时缓存。
每个环节都要能说出观测指标（登录失败率、token 刷新失败率、401/403 比例、权限缓存命中率），这样回答才从概念落到生产。

往项目引 ⭐："我项目认证链路是：BCrypt 校验密码 → 签 JWT 双 token（含用户和租户 id）→ 网关验签透传 → RBAC 鉴权 → refresh 续期 → 注销删 Redis。一条线把登录、鉴权、多租户、续期、注销都覆盖了，面试官一听就知道你做过完整的。"

20. 🟢 怎么防止接口被重复提交（结合安全）？

标准答：和幂等一类——前端置灰 + 后端 token 机制（进页面发一次性 token、提交校验并删除）+ 唯一索引/状态机兜底。用 Redis 存 token、Lua 原子校验删除。

拓展：

防重复提交是用户体验 + 数据一致问题，也和防重放相关。
关键是"服务端判定唯一一次"，不能只靠前端。
幂等 token 应与用户、接口、业务参数绑定并设置合理 TTL；校验、消费和删除要在同一原子操作中完成，避免并发双成功。
数据库唯一索引、状态机和业务幂等键是最终兜底，Redis 失效时仍不能产生两笔订单；重试响应应返回同一业务结果，而不是重复执行。
对支付、扣库存等不可逆操作，要区分“请求重复”与“上一次处理超时”，通过查询幂等记录返回处理中/已完成状态。

往项目引 ⭐："我项目下单防重复提交用 Redis token + Lua 原子校验删除，加订单号唯一索引兜底，前端再置灰按钮——三重保险，重复点击只成功一笔。"

你能答到第几层？

三段都能答、还能往项目引：安全认证这块你稳了，SaaS/政企岗尤其吃这个。
标准答 + 拓展能成体系答：知识够，差把它接到项目的认证链路上。
标准答都磕巴：安全有主线（认证 JWT/SSO → 授权 RBAC → 多租户 → 常见漏洞防范），跟着学一遍 + 一个有登录鉴权的项目就懂。

这是面试专题的「安全与认证篇」，网站上还有并发、MySQL、Redis、Spring、微服务、消息队列、JVM、项目场景等系统整理。 🌐 更多真实面试专题与资料：smallredtech.com 💬 想系统学 / 简历与辅导咨询，加微信：Ahongbb666（备注「面试题」）