面经策

Spring 中的 @PathVariable 注解的作用是什么？ ​

  • 标签：后端、Spring

🏛 业务架构师 ​

@PathVariable 的作用是把 URL 路径中的占位符变量绑定到方法参数上，用于 RESTful 风格的资源定位：

java
@GetMapping("/orders/{orderId}")
public OrderVO detail(@PathVariable Long orderId) { ... }
// GET /orders/12345 → orderId = 12345

支持多变量、正则约束（/{id:\\d+}）。

架构师视角，这个注解背后是 RESTful 资源化设计的业务表达：URL 描述"资源是什么"（/orders/12345），HTTP 方法表达"对资源做什么"（GET 查、POST 建、PUT 改、DELETE 删），参数从"资源身份"（路径）和"查询条件"（@RequestParam）中各归其位。这套语义统一后，API 的可预测性大幅提升——调用方不用文档也能猜出接口形状，跨团队联调成本显著下降。

两个实战规范：

  1. 路径参数只放"资源标识"：ID、编码这类稳定的身份信息；过滤、排序、分页一律走查询参数。不要把业务状态塞进路径（/orders/cancelled/123 是坏味道，状态是可变的，身份才该进路径）；
  2. 类型显式声明（Long orderId）并校验，配合全局异常处理把 MethodArgumentTypeMismatchException 转成 400——格式错误的请求快速失败，不给下游埋雷。

一句话：@PathVariable 是小注解，但它承载的资源化 API 设计是公司级接口治理的地基。

🏗 系统架构师 ​

作用：把 URI 模板变量绑定到方法参数（/orders/{id} → 参数 id），支持正则约束（{id:\d+}）。

REST 设计视角：PathVariable 承载资源标识——URL 即资源地址，「GET /orders/123」是「订单 123 的表示」。它与 @RequestParam（过滤、分页参数）各司其职：标识进路径，参数进查询串，这是面向资源 API 的基本纪律。

我的工程纪律：

  1. 路径里不放敏感数据——URL 会进访问日志、浏览器历史、APM 追踪，手机号、token 进路径等于泄露；我处理过全链路日志铺满明文手机号的教训；
  2. 路径是缓存键的一部分：/orders/123 天然可被 CDN/网关按 URI 缓存，把本该是查询参数的东西塞进路径会碎片化命中率；
  3. 层级不超过两层（如 /users/{uid}/orders/{oid}），过深的路径层级是资源建模混乱的信号。

💻 全栈开发专家 ​

从 URI 模板变量取值绑定参数，RESTful 接口的基础：

java
@GetMapping("/orders/{orderId}/items/{itemId}")
public ItemVO item(@PathVariable Long orderId,
                   @PathVariable("itemId") Long id) {   // 名字不一致时显式指定
    ...
}

细节与坑：

  1. 参数名省略依赖 -parameters 编译参数（Boot 3 的插件默认开，老项目手动升 Java 17 时容易丢，报 Name for argument not specified）
  2. 支持正则约束：@GetMapping("/files/{name:.+}") 防后缀被截断（a.txt 取成 a 的经典坑）；{id:\\d+} 限纯数字
  3. 类型转换失败抛 MethodArgumentTypeMismatchException 返回 400，全局异常处理器统一转"参数格式错误"
  4. URL 编码：中文/特殊字符要 encode，网关和服务双重解码容易出问题，约定链路上只解一次

对比记忆：@PathVariable 取路径段，@RequestParam 取 query 参数（?page=1），@RequestBody 取请求体。设计 REST 接口的惯例：资源 ID 进路径、过滤分页进 query，这两句话答题时顺带说出，体现接口设计的肌肉记忆。