hl-api-changelog/changelogs-v2/2026-06/24_4363_配房选酒店默认不按城市列全部跨城_管理后台.md

32 行
3.1 KiB
Markdown

此文件含有模棱两可的 Unicode 字符

此文件含有可能会与其他字符混淆的 Unicode 字符。 如果您是想特意这样的,可以安全地忽略该警告。 使用 Escape 按钮显示他们。

# 配房选酒店默认不按城市(列全部在售·跨城,池内/定制师优先;搜索框可筛;已上线测试服·可对接)
> 变更类型:✨ 行为变更(后端 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`