Controller层PathVariable取纯id还是从SEO友好路径段中解析id？

结论 #

方案二更合理，建议选择后端统一提取ID的实现方式。

前端拆分提取ID的优缺点 #

• 优点：
  • 后端无需调整原有接口的参数接收逻辑，短期改造成本低
  • 省去后端字符串拆分、类型转换步骤，接口无额外性能损耗
• 缺点：
  • 多端适配成本高：如果涉及PC、H5、小程序等多个前端端调用接口，每一端都需要单独实现ID提取逻辑，重复开发且容易出现实现不一致的问题
  • 迭代维护成本高：后续如果URL的slug规则调整（比如新增后缀、修改分隔符规则等），所有前端端都需要同步改造，漏改就会引发线上故障
  • 第三方兼容差：如果有爬虫、合作方需要直接调用接口，还需要额外对接ID提取规则，使用门槛高

后端拆分提取ID的优缺点 #

• 优点：
  • 逻辑统一收敛：所有调用方只需要传递完整路径段即可，不需要关心ID提取规则，多端适配成本为0
  • 维护成本低：后续URL规则调整只需要后端一处修改，不会影响上游调用方
  • 容错性强：可在后端统一增加格式校验、异常捕获逻辑，拆分/转译失败时统一返回规范的参数错误提示，避免无效请求打到业务层
  • 对第三方调用友好：不需要额外说明ID提取规则，直接传完整路径段即可调用
• 缺点：
  • 有极微小的字符串处理性能损耗，对接口整体性能的影响几乎可以忽略
  • 需要调整原有接口的参数类型，有少量改造工作量

优化建议 #

如果项目用的是Spring Boot框架，可以直接用路径正则匹配，不需要手动拆分字符串，实现更安全：

@GetMapping("/get/{slug:[a-zA-Z0-9-]+}-{id:\\d+}")
public ResponseEntity<?> getProductDetail(@PathVariable Long id) {
    Product product = productService.getProductDetail(id);
    return new ResponseEntity<>(product, HttpStatus.OK);
}

直接通过路径规则把末尾的数字映射为id参数，既保留了后端统一处理规则的优势，又省去了手动拆分的逻辑。

内容的提问来源于stack exchange，提问作者Burak Yilmaz