3.1 KiB
3.1 KiB
配房选酒店默认不按城市（列全部在售·跨城,池内/定制师优先;搜索框可筛；已上线测试服·可对接）
变更类型：✨ 行为变更（后端 order + resource 一并改,已部署测试服并 API 实测） 端类型：管理后台（配房·「选择酒店」弹窗） 日期：2026-06-24 ｜ 工单：#4363 ｜ PR：#4364 ｜ 服务：hl-order-service-v3 + hl-resource-service 关联：承接 #4346（本单做全）。更正本目录早前「配房选择酒店候选列表后端返全集」那篇——彼时后端实为按行程城市过滤（非纯前端 bug,我先前定性有误,致歉）,现已改为默认不按城市。
⚠️ 关键说明
- 行为变更：配房「选择酒店」
GET /v3/admin/hotel-candidates默认不再按行程城市过滤,改为列全部在售酒店（带标签的池内 / 定制师推荐由后端排最前）。 - 用户在搜索框输入城市 / 关键词时才按城市 / 关键词筛（
city/keyword入参,行为不变）。 - 接口无 total / 分页字段,
candidates是完整数组（默认上限 30,排序后截断）。前端全量顺序渲染 candidates,勿按标签过滤。
1. 入参 / 出参（契约不变,仅默认行为变）
GET /v3/admin/hotel-candidates：
orderId（必传）/dayNumber（推算 stayDate,不再用于推算城市）/city（选填,搜索框指定才按城市筛）/keyword（选填,跨城 / 省关键词搜）/limit（默认 30,上限 50）。- 出参
data.candidates[]字段同前（hotelName / protoPrice / isPoolMatch / isConsultantRecommended / tags / ...）;排序：定制师点名 > 池内 > 普通。
2. 测试服实测（order 2069593503129636865 第 1 晚）
| 调用 | data.city | 候选城市 | 条数 |
|---|---|---|---|
| 默认（不传 city） | null | 兴安盟 + 呼伦贝尔市（跨城） | 10（全部在售,池内海拉尔海棠排第 1） |
传 city=海拉尔 |
海拉尔 | 呼伦贝尔市 | 1（按城市筛） |
改前同一调用只返呼伦贝尔市 10 条（锁行程城市）;改后跨城返全部在售（含兴安盟阿尔山成悦酒店）。
3. 前端动作
- ⚠️ 默认别传
city（实测抓包发现的关键 bug）：当前配房「选择酒店」弹窗自动把行程城市（如「海拉尔区、满洲里市」）塞进city入参,后端就按城市前缀匹配——而「海拉尔区、满洲里市」是多地名拼接串,库内酒店 city 是「呼伦贝尔市」,前缀匹配不到 → 城市查 0 条,只剩定制师指定（preferredHotelId）的 1 条。默认请勿传 city（去掉自动带的行程城市标签）,只在用户搜索框输入城市时才传 city,这样才返全部跨城（实测不传 city 返 10 条跨城）。 - 全量顺序渲染
candidates（后端已排好序,带标签的在最前）,弹窗「共 N 条」=candidates.length（实测前端「共 8 条」与实际 candidates 条数对不上,请改用数组长度）,勿按标签过滤。 - 搜索框：输入城市 → 传
city;跨城 / 关键词 → 传keyword。