3.6 KiB
3.6 KiB
【后端已修·管理后台】投保下单「关联订单」下拉报「参数类型错误: id='list'」——后端给订单列表补了 /list 别名,前端无需再改
服务:hl-order-service-v3(OrderController) | 分支:dev-v3 | PR:#3798(已合并、已部署测试服双实例 8086/8186、网关 9443 往返实测通过) | 2026-06-13 背景:前端按上一条 changelog 把保险订单列表改成
/v3/admin/insurance/list后,「保险订单」页投保下单弹窗里的**「关联订单」下拉**仍报红条参数类型错误: id='list'(需要 Long 类型),实际失败请求是GET /v3/admin/order/list?page=1&pageSize=20。
⚠️ 关键说明
- 这是和保险列表不同的另一个调用:「关联订单」下拉搜的是业务订单,调的是
GET /v3/admin/order/list(order 模块),不是保险列表。 - 根因:order 模块的订单列表原本只挂在 RESTful 集合根
GET /v3/admin/order(没有/list),详情是GET /v3/admin/order/{id};前端按「{模块}/list」习惯调/order/list时,list落到/{id}上当 Long 解析失败 → 报id='list'。order 模块是各 admin 列表里唯一用集合根的「异类」,所以前端必踩。 - 后端已修(PR #3798):给订单列表同时挂载根 +
/list两条路径。前端那条现成的GET /v3/admin/order/list调用现在直接返回 200,无需任何前端改动,部署后刷新页面红条即消失。
⚠️ 对上一条 changelog 的修正
上一条(13_前端修复_保险订单列表调错路径...)我说「v3 全站 admin 列表统一 {模块}/list」——这对保险/合同/退款/评价/支付成立,但 order 模块当时是个例外(用集合根),所以才有这次的 /order/list 报错。本次 PR #3798 把 order 也补上了 /list,现在 {模块}/list 这个习惯对订单也成立了,前端可放心统一用 {base}/list。
路径现状(部署后)
| 用途 | 可用路径 | 说明 |
|---|---|---|
| 保险订单列表 | GET /v3/admin/insurance/list |
上条已说明 |
| 业务订单列表(关联订单下拉用) | GET /v3/admin/order/list ✅ 与 GET /v3/admin/order ✅ |
本次新增 /list 别名,两者等价 |
| 业务订单详情 | GET /v3/admin/order/{id}(id 为 Long) |
不变 |
| 订单关键词搜索 | GET /v3/admin/order/list?keyword=xxx |
keyword 匹配 团号/客户姓名/产品名/订单号 任一字段 LIKE |
实测(测试服网关 https://api.test.1814.love:9443,PR #3798 部署后)
GET /v3/admin/order/list?page=1&pageSize=20 → {"code":200,"message":"成功","data":{"records":[],"total":0,...}} ✅ 不再报 id=list
GET /v3/admin/order?page=1&pageSize=20 → {"code":200,...} ✅ 回归正常
GET /v3/admin/order/list?page=1&pageSize=20&keyword=张 → {"code":200,...} ✅ 关键词搜索可用
GET /v3/admin/order/123 → {"code":581007,"message":"订单不存在"} ✅ 数字 id 仍正确解析(详情未受影响)
注:返回
records:[] / total:0是测试库当前没有该 admin 可见的业务订单(数据条件,非接口问题);有真实订单时「关联订单」下拉即有数据。
影响面
仅 OrderController.listOrders 的 @GetMapping 由根改为 @GetMapping({"", "/list"}),单 handler 双路径;零新增方法、零行为变化、无 DDL、无 Flyway、无新增错误码,网关 /v3/admin/order/** 通配已覆盖。