应将免签接口与需签名接口分离，通过@noauth注解标记方法或类，并在过滤器或路由处理器中反射检查该注解以跳过签名校验，同时避免仅依赖路径匹配、确保注解作用于真实目标方法，并保留限流等基础防护。
在单页面应用（SPA）的后端 API 架构中，将“免签接口”（如登录、注册、获取验证码、健康检查、公开配置等）与需签名鉴权的业务接口明确分离，是保障安全又兼顾可用性的关键。利用注解配合集中过滤器实现动态隔离，既避免硬编码路径白名单，又支持按需灵活扩展。
定义免签接口专用注解
创建一个轻量级、运行时保留的注解，用于标记无需签名验证的方法或控制器类：
- 使用
@Retention(RetentionPolicy.RUNTIME)，确保可通过反射读取 - 支持方法级和类级标注，方便批量豁免（如整个
LoginController） - 不带参数即可，语义清晰：有此注解 = 跳过签名校验
示例代码：
@Target({ElementType.METHOD, ElementType.TYPE})<br>@Retention(RetentionPolicy.RUNTIME)<br>@Documented<br>public @interface NoAuth { }在统一过滤器中识别并跳过校验
在全局请求过滤器（如 Spring 的 OncePerRequestFilter 或自定义 HandlerInterceptor）中，根据请求匹配到的目标处理器，反射检查是否带有 @NoAuth 注解：
- 对
HandlerMethod：先获取其Method对象，调用isAnnotationPresent(NoAuth.class) - 若方法未标注，再检查其所属类（
method.getDeclaringClass()）是否标注 - 任一命中即直接
chain.doFilter(request, response)放行，不执行后续签名解析与校验逻辑
与动态路由机制协同工作（如 /api/** 场景）
当后端采用基于注解的动态路由（如 @ApiMethod + ApiHandlerMapping）时，免签逻辑需前置到路由解析之后、业务调用之前：
- 在
ApiHandler.handleRequest()开头，完成 URI 解析（如提取模块名user、方法名login）后，立即查 Spring 容器中对应 Service 的目标方法 - 通过
service.getClass().getDeclaredMethod(methodName, ...)获取Method实例 - 检查该
Method是否含@NoAuth，是则跳过签名验证，直通业务执行 - 这样既复用已有路由结构，又保持免签判定逻辑与业务服务绑定，而非依赖路径字符串匹配
补充建议：避免常见陷阱
实际落地时需注意几个易忽略点：
-
不要仅依赖 URL 路径判断：比如把所有
/api/auth/**都放行——一旦某条路径被误配或重定向，可能意外绕过鉴权 - 注解必须作用于最终执行方法：若使用 AOP 代理或内部委托调用，要确保反射能拿到真实目标方法，而非代理对象
- 免签不等于无防护：仍应保留基础防护，如限流（针对短信发送）、IP 黑名单、参数格式校验（防止 JSON 注入），这些与签名鉴权正交且可叠加
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
