缺陷标题

搜索“无线耳机”首屏/分页响应明显过慢且偶发 504（ES 前置通配符触发全表扫描、分页仍执行聚合、重复请求未合并）

问题描述

在统一搜索场景中，输入关键词“无线耳机”并设置类目与价格区间后，首屏结果呈现耗时显著超标，分页切换同样缓慢，期间用户端骨架屏长时间停留，偶发 504 超时。APM 显示 search-service CPU 持续高位（>90%），Elasticsearch 查询包含前置通配符“耳机”导致全表扫描，且分页请求仍执行聚合，造成响应链路整体放大。前端在用户连续点击搜索或分页时，重复请求未被合并，进一步加剧服务压力。

复现步骤

1. 登录后台；
2. 打开搜索页，输入关键词：“无线耳机”，筛选：类目=数码，价格=199~999，排序=综合；
3. 点击搜索，记录首屏列表渲染完成时间；
4. 进行分页切换（下一页/上一页），记录分页响应耗时；
5. 观察用户端骨架屏展示与消失时机；
6. 并行重复点击搜索或快速切换分页，观察是否产生重复请求与其合并情况。

环境与前提：

• Win11 23H2 + Chrome 121，网络 100 Mbps 稳定；
• 数据规模：ES 索引约 1,020,341 条，6 分片 2 副本；
• 版本：Elasticsearch 8.13.4；search-service v1.18.3（Java 17，2C4G）；Kong 3.5；PostgreSQL 14.7；Redis 6.2；K8s 1.27 + Istio 1.20；构建号 2025.12.09-rc1。

预期结果

• 首屏 p95 < 800 ms，分页切换 < 500 ms；
• 骨架屏在 300 ms 内展示，并在数据返回后迅速过渡为实际列表；
• 查询应避免全表扫描；分页不应重复执行耗时聚合；
• 连续点击产生的重复请求应去重/合并，避免放大后端压力。

实际结果

• 网关统计：首屏 p95 ≈ 6.8 s，p99 ≈ 9.2 s，偶发 504；
• APM：search-service CPU > 90%，链路中搜索处理与序列化耗时显著；
• ES：查询包含前置通配符“耳机”，触发全表扫描；分页请求仍执行聚合操作；慢查询 > 7 s；
• 前端：performance.timing domComplete ≈ 7.4 s；骨架屏长时间停留；
• 并发场景：用户多次点击触发重复请求，未做合并/去重，进一步拉长队列与耗时。

影响分析

• 业务影响：高峰期搜索 QPS 降至 ~35，队列积压，转化率下降；Web 与小程序端统一搜索能力受影响；
• 性能与稳定性：慢查询与高 CPU 导致响应雪崩风险，偶发 504 影响可用性和用户体验；
• 范围：涉及所有使用“无线耳机”及类似需要模糊匹配的关键词搜索的用户请求，尤其在高峰时段更明显；
• 风险传播：ES 全表扫描 + 不必要聚合 + 重复请求放大，形成叠加效应，可能扩散至其他搜索关键词与类目。

严重程度

• 严重程度：P1（高）
• 依据：核心功能性能严重不达标（p95>6s，偶发 504），高峰期可用性与转化受影响，范围广、风险高，需优先处理。

附件信息

• 证据与观测：
  • traceId：ab91...（完整 ID 见附件）
  • 网关统计：p95 6.8 s、p99 9.2 s
  • APM 火焰图：search-service CPU > 90%，热点集中在搜索处理/序列化与下游调用等待
  • ES 慢查询：> 7 s，explain 显示前置通配符触发全表扫描，分页仍带聚合
  • 前端指标：performance.timing domComplete ≈ 7.4 s
  • 附件清单：HAR、APM 火焰图、ES 慢查询日志与 explain 输出
• 测试环境：
  • ES：8.13.4，索引约 1,020,341 条，6 分片 2 副本
  • 服务：search-service v1.18.3（Java 17，2C4G），Kong 3.5，PostgreSQL 14.7，Redis 6.2
  • 平台：K8s 1.27 + Istio 1.20；构建 2025.12.09-rc1
  • 客户端：Win11 23H2 + Chrome 121；网络 100 Mbps 稳定

——

修复建议与验证方案（建议）

• 服务端/ES 查询优化
  • 禁止前置通配符（leading wildcard）；后端对关键词规范化（移除*），采用 analyzer（如 edge_ngram/search_as_you_type）或 match/match_phrase + ngram 索引方案实现前缀/模糊检索，避免全表扫描。
  • 将筛选条件（类目、价格区间）置于 filter context（bool.filter），减少评分与扫描范围；确保使用倒排索引可命中过滤。
  • 分页不重复执行聚合：首屏返回聚合（facets）即可，翻页仅返回列表；深分页采用 search_after 替代 from/size。
  • 为热点查询启用结果缓存（ES query cache + 应用层缓存/Redis），设置合理 TTL 与 key 规范化。
• 网关与应用层限流/合并
  • 前端去抖/节流（输入 300–500 ms 去抖）；同 queryKey 的并发请求在服务端合并（singleflight/请求折叠）；Kong 层按用户/会话限流与连接复用。
  • 对相同查询参数启用幂等与缓存（ETag/Cache-Control, stale-while-revalidate）。
• 资源与保护
  • 临时扩容 search-service（CPU/副本数）与 ES 读线程池；为高峰期设置熔断/降级策略（超时快速失败、返回上次缓存结果）。
  • 将 ES 慢查询阈值下调至 1s 并开启详细慢日志，便于复核。
• 前端体验
  • 骨架屏在 300 ms 内展示；首屏采用“结果先行、聚合延迟加载”策略；避免在列表渲染前等待全部聚合完成。
  • 对重复点击禁用按钮或合并请求，显式加载态与超时兜底提示。
• 验证方案（通过/回归标准）
  • 数据规模不变条件下压测（并发 ≥ 100，RPS ≥ 峰值 1.2×）：
    • 首屏 p95 < 800 ms，p99 < 1200 ms；分页 p95 < 500 ms；无 504；
    • ES 慢查询 < 1 s（无全表扫描），search-service CPU 平峰 < 70%；
    • 队列无异常积压，错误率 < 0.1%。
  • 功能一致性：搜索结果与排序一致（不因改 analyzer 影响业务正确性）；分页正确且不再伴随聚合。
  • 并发与抗抖：相同 queryKey 并发仅一次后端命中（其余合并/命中缓存）；前端重复点击无请求风暴。
  • 端到端：Web/小程序均满足同等 SLO；骨架屏在 300 ms 内出现并在数据返回后及时收敛。
  • 观测：APM、ES 慢日志、网关指标与前端 RUM 均达到上述门槛并连续观测 24–48 小时稳定。

缺陷标题

Safari 16 下 input[type=file] 选择文件后不触发 change 事件，event.target.files 为空，上传流程无法启动

问题描述

• 在 Safari 16（iOS 16.6 / macOS 13.4，Safari 16.5）中，页面的 input[type=file] 选择 HEIC/MP4 文件后未触发 onChange，导致无法读取 files 列表并启动上传；同流程在 Chrome/Edge 正常。
• 受影响元素包含 accept 与 capture 组合使用，且作为 React 18 受控组件嵌套在页面交互区域中；Safari 下该 input 会被重置，未产生 change 事件。
• 现象：进度条停留在 0%，开发者工具 Network 无任何请求，控制台出现 TypeError。
• 适用范围：用户头像与通用附件上传入口，均依赖相同上传组件与分片上传服务。

复现步骤

1. 设备与浏览器：
   • iPhone 14（iOS 16.6）Safari 16.5
   • MacBook Pro（macOS 13.4）Safari 16.5
2. 访问：https://app.example.test/profile
3. 点击“上传头像/附件”，系统调用原生文件选择器
4. 选择以下任一文件：
   • 图片：HEIC，约 4MB
   • 视频：MP4，约 10MB
5. 观察控制台与网络面板：
   • Console：监听 change 回调日志与错误输出
   • Network：是否产生初始化或分片上传请求
6. 对比验证（可选）：在相同网络与账号下使用 Chrome/Edge 执行上述步骤

补充环境与配置

• 前端：Web v3.12.5（React 18）
• 上传服务：upload-service v2.4.1（分片大小 5MB）
• 反向代理/CDN：Nginx 1.24，自建 CDN
• 网络：同局域网 Wi‑Fi，RTT≈20ms
• 浏览器：无插件干扰

触发前提（基于现象与排查）

• input[type=file] 使用 accept（image/* 或 video/*）与 capture 组合
• 该 input 作为受控/半受控组件嵌套在交互容器内（Safari 下可能触发节点重建/重置）

预期结果

• 选择文件后立即触发 onChange，event.target.files 含已选文件
• 生成本地预览并启动分片上传，请求链路可见，服务端返回 200
• 进度条按实际分片发送推进

实际结果

• 未触发 onChange；event.target.files 为空或未定义
• 控制台报错（示例）：
  • TypeError: undefined is not an object（evaluating 'e.target.files[0]'）
• 未产生任何上传相关网络请求，进度条停在 0%

影响分析

• 业务影响：Safari 用户无法上传头像/附件，影响资料完善与工单提交流程；合规类场景（需提交证明）无法完成，存在合规风险
• 覆盖范围：Safari 用户约占日活 22%，为稳定复现问题（在上述设备与版本）
• 功能影响：上传核心路径阻断（P1 级别），涉及多入口复用的统一上传组件
• 技术侧风险：
  • 与 Safari 16 对 input[type=file] 在 accept/capture 组合及受控渲染场景下的兼容性相关；元素可能被 Safari 重置，导致未触发 change 且 files 置空
  • React 组件在文件选择后发生重渲染/重置，会使原生 input 状态丢失，Safari 行为更敏感

严重程度

高（阻断，P1）

• 上传核心功能在 Safari 用户侧不可用，影响显著且无用户自助可行替代路径

附件信息

• 证据材料：
  • 控制台截图（包含 TypeError 栈信息、change 监听日志缺失）
  • Network 面板录屏（选择文件后无请求）
  • 设备端录屏（iOS/macOS Safari 16.5）
  • Safari 与 Chrome/Edge 行为对比截图
• 已验证的临时绕过：
  • 去除 capture 与 accept 的组合（仅保留 accept 或移除 capture）后可触发 change
  • 改用事件委托/原生 addEventListener 绑定至持久化的 input 节点，且避免组件重渲染导致的 input 重置
• 受影响与对照版本：
  • 受影响：Safari 16.5（iOS 16.6 / macOS 13.4）
  • 正常：Chrome/Edge（同环境）
• 建议的修复与验证方案：
  • 修复建议
    • 前端规避
      1. 对 Safari 16.x 条件降级：移除 capture 属性或调整 accept/capture 组合；必要时区分移动端与桌面端策略
      2. 保证 input[type=file] DOM 节点稳定：避免在文件选择流程中对其进行条件渲染、key 变更或受控重置；改为非受控 ref + 原生事件监听
      3. 选择后先校验 files 是否存在再进入后续逻辑，增加空值保护
    • 渐进增强 4) 为 Safari 检测到的异常路径提供回退上传控件（不使用 capture），确保基本可用
    • 中长期 5) 关注 WebKit 对 capture/accept 与 file input 事件的兼容性修复进展，后续移除条件分支
  • 回归验证
    • 在 iOS 16.6 / macOS 13.4 Safari 16.5 上验证头像与附件两处入口
    • 文件类型与体积覆盖：HEIC（4MB）、JPG（<1MB）、MP4（10MB、>20MB）
    • 验证三项：onChange 触发、files 有效、Network 产生初始化与分片请求，服务端 200
    • 交叉浏览器回归：Chrome/Edge 不受影响
    • 验证组件重渲染下的稳定性（重复选择、切换路由、打开/关闭弹窗场景）