历史多车长时间窗审计
结果
本轮把多车长时间窗从“提交后才知道系统怎么查”改成提交前可预期、提交后可核验的查询流程：
- 新增近 7 天、近 30 天快捷范围；桌面保持单行，移动端改为 3 × 2 网格，不需要横向滚动寻找选项。
- 5 辆 × 30 天会在提交前明确显示 30 天、6 小时/桶、桌面 50 条/页或移动端 20 条/页、后台 CSV，以及逐车预计趋势桶上限。
- 折叠筛选后仍保留当前查询执行策略；趋势结果继续显示真实
6 小时粒度 · 54 原始点，便于核对计划和执行是否一致。 - 明细、趋势和导出统一采用最长 31 天边界；超过范围在前端阻止提交，API 返回
HISTORY_TIME_RANGE_TOO_LARGE。 - 后端多车明细与趋势改为并行查询，并按用户输入车辆顺序合并回执，缩短等待时间且不破坏核对顺序。
验证步骤
-
Healthy — 桌面预判与执行一致
- 1440 × 980：5 辆、30 天、位置数据。
- 六个快捷范围完整可见；查询计划显示 6 小时/桶和后台 CSV。
- 折叠条件并展开趋势后，真实结果显示
6 小时粒度 · 54 原始点。
-
Healthy — 移动端无需横向找快捷项
- 390 × 844：六个快捷范围以 3 × 2 网格一次呈现。
- 应用后策略栏仍固定呈现时间跨度、趋势粒度、分页和导出方式。
-
Healthy — 大范围保护一致
- 精确 31 天的明细与趋势请求成功。
- 32/33 天在前端显示阻断说明，API 返回 400 和稳定错误码。
-
Healthy with known vendor warning — 自动化回归
- Web：78 个测试文件、502 项测试通过。
- Go：
go test ./...通过。 - Web、Open Portal 与 Go 二进制生产构建通过。
- 页面控制台未发现本功能运行时异常；仍存在 Semi UI 在 React StrictMode 下的
findDOMNode依赖警告。
证据
before-desktop.png：桌面改造前，长窗执行规则不可见。after-desktop.png：桌面改造后，快捷范围和执行计划前置。after-desktop-trend.png：折叠筛选后的当前策略与真实 6 小时趋势。before-mobile.png：移动端改造前。after-mobile.png：移动端 3 × 2 快捷范围及查询计划。after-mobile-applied.png：移动端应用后的持续策略提示。after-mobile-limit.png：33 天范围的阻断状态。comparison-desktop.png：桌面前后对照。
无障碍边界
已通过语义快照确认快捷范围为命名分组、按钮保留 aria-pressed，当前执行策略使用可命名 region，应用后的策略通过 live region 更新。尚未完成真实屏幕阅读器语音输出、整页仅键盘手工巡检和专业对比度仪器复测；这些仍属于发布前人工验收边界。