# 历史多车长时间窗审计

## 结果

本轮把多车长时间窗从“提交后才知道系统怎么查”改成提交前可预期、提交后可核验的查询流程：

- 新增近 7 天、近 30 天快捷范围；桌面保持单行，移动端改为 3 × 2 网格，不需要横向滚动寻找选项。
- 5 辆 × 30 天会在提交前明确显示 30 天、6 小时/桶、桌面 50 条/页或移动端 20 条/页、后台 CSV，以及逐车预计趋势桶上限。
- 折叠筛选后仍保留当前查询执行策略；趋势结果继续显示真实 `6 小时粒度 · 54 原始点`，便于核对计划和执行是否一致。
- 明细、趋势和导出统一采用最长 31 天边界；超过范围在前端阻止提交，API 返回 `HISTORY_TIME_RANGE_TOO_LARGE`。
- 后端多车明细与趋势改为并行查询，并按用户输入车辆顺序合并回执，缩短等待时间且不破坏核对顺序。

## 验证步骤

1. **Healthy — 桌面预判与执行一致**
   - 1440 × 980：5 辆、30 天、位置数据。
   - 六个快捷范围完整可见；查询计划显示 6 小时/桶和后台 CSV。
   - 折叠条件并展开趋势后，真实结果显示 `6 小时粒度 · 54 原始点`。

2. **Healthy — 移动端无需横向找快捷项**
   - 390 × 844：六个快捷范围以 3 × 2 网格一次呈现。
   - 应用后策略栏仍固定呈现时间跨度、趋势粒度、分页和导出方式。

3. **Healthy — 大范围保护一致**
   - 精确 31 天的明细与趋势请求成功。
   - 32/33 天在前端显示阻断说明，API 返回 400 和稳定错误码。

4. **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 更新。尚未完成真实屏幕阅读器语音输出、整页仅键盘手工巡检和专业对比度仪器复测；这些仍属于发布前人工验收边界。