HERE Transit API v8同起终点改时间无路由报错原因及修复

该现象并非API接口故障，是HERE Transit API v8默认搜索规则与查询时段的公共交通排班特性共同导致的：

• 查询的起终点为跨城公共交通过程，查询时段（早6点左右）属于夜间停运结束、早班干线班次始发的临界窗口，该时段长途列车、城际大巴的发车间隔普遍在1小时以上，单班的时间容错空间极低。
• API在arrivalTime（指定到达时间）查询模式下，默认以设定的到达时间为基准倒推可行路径，仅搜索到达时间前后窄时间窗范围内、起点/终点步行接驳半径内的停靠班次：默认时间偏差阈值仅10分钟，默认步行接驳距离仅1000米。当你把到达时间从06:00调整到06:10时，倒推的搜索窗口刚好错过唯一能匹配行程的早班跨城班次，系统判定步行范围内无符合时间要求的经停站点，就会返回noStationsFound、noRouteFound类报错，出现10分钟时间差导致结果跳变的情况。
• 早班时段城区接驳的公交班次尚未完全开班，步行到最近的城际站点的时间计算偏差，会进一步放大时间窗匹配的敏感度，加剧结果跳变的概率。

按优先级从高到低调整请求参数即可稳定获取结果：

• 新增maxTimeDeviation参数，将默认的10分钟时间偏差放宽到30~60分钟，即传参maxTimeDeviation=60，允许API返回比指定到达时间早到/晚到1小时内的可行路径，避免刚好卡在单班临界值触发无结果报错。
• 放宽接驳搜索的默认限制：将walkSpeed从默认的1.34m/s调整为1.5_{1.7m/s（匹配赶车时的快走速度），将`maxWalkDistance`从默认的1000米调整为2000}3000米，覆盖跨城场景下距离稍远的火车站、长途客运站，避免因接驳范围设置过小漏算可行站点。
• 长距离跨城查询优先使用departureTime（指定出发时间）参数替代arrivalTime：正向出发搜索的时间窗容错性远高于倒推到达搜索，不会因10分钟级的时间偏差直接漏算全部可行路径。
• 若需获取某一时段的全量路径覆盖结果，不要逐10分钟遍历单点时间查询：将arrivalTime设为目标时段的起始时间，搭配传参showNextDepartures=true，可一次性拉取后续2小时内的所有可选班次，从根源上避免逐点查询的结果跳变问题。

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