非均匀时间序列按固定间隔对齐抽取：从朴素遍历到生产级实现

1. 从一个真实的数据处理需求说起

前阵子帮一个做物联网设备数据分析的朋友处理一批传感器上报数据，需求听起来很简单：设备每隔一段时间上报一次温度、湿度、电压这些指标，但因为网络抖动、设备休眠、断电重启等原因，上报时间点并不是严格等间隔的。现在需要从这些"不连续"的时间点里，找出某个指定时间段内，按照固定时间间隔（比如每5分钟、每15分钟）能对齐上的数据。

这个需求乍一听像是"降采样"或者"重采样"，但真正动手写的时候会发现坑不少。它不是简单的filter一下时间范围就完事，也不是无脑按索引切片。核心难点在于：原始数据的时间戳是散落的、不均匀的，而目标是要在某个时间窗口内，按照一个固定的步长，把"恰好落在这些步长刻度上"的数据挑出来。

这类问题在实际工作中出现的频率远比想象中高。做金融行情的，需要从逐笔成交里抽取每分钟的K线快照；做运维监控的，需要从零散的日志时间戳里对齐出每5分钟的采样点；做运动手环数据处理的，需要从心率上报记录里提取每30秒的稳定读数。它们的本质都是同一个问题：在非均匀时间序列中，按固定间隔抽取对齐数据。

这篇文章就把这个问题的完整解法拆开讲透。从最朴素的思路到能扛住生产环境数据的健壮实现，从时间戳的精度陷阱到跨时区、跨夏令时的处理，我会把踩过的坑和验证过的方案都摆出来。不管你是刚接触时间序列处理的新手，还是已经写过几版重采样逻辑的老手，应该都能从里面找到能直接抄作业的代码和思路。

先明确一下本文要解决的问题边界：输入是一个数组，每个元素带有时间戳字段（可能是毫秒数、秒数、ISO字符串或Date对象），时间戳整体递增但间隔不均匀；另外给定一个查询时间段[start, end]和一个固定间隔interval（如5分钟）；输出是落在该时间段内、且时间戳能对齐到间隔刻度上的数据点集合。下面所有的讨论都围绕这个边界展开。

2. 核心思路拆解：为什么不能直接按索引切片

2.1 时间序列的"不连续"到底意味着什么

很多人第一反应是：既然数据是按时间排序的，那我找到起始位置和结束位置，然后每隔N条取一条不就行了？这个思路在数据严格等间隔时是成立的，但一旦间隔不均匀，就会出大问题。

举个具体的例子。假设原始数据是这样的时间戳（单位：分钟）：0、3、5、8、10、12、15、20。如果我想每5分钟取一个点，按索引每隔一条取，会得到 0、5、10、15，看起来好像对了。但如果数据变成 0、1、2、3、4、5、6、7、8、9、10，同样每5分钟取一个点，按索引取就会得到 0、2、4、6、8、10，完全错位。因为索引间隔和数据的时间间隔之间没有任何必然联系。

所以第一个要建立的认知是：时间序列的抽取必须基于时间戳本身来计算，而不是基于数组下标。下标只是存储位置，时间戳才是数据的真实坐标。这一点想通了，后面的方案就顺了。

2.2 对齐刻度的本质：取模运算

既然要按固定间隔对齐，那核心数学操作就是取模。假设间隔是interval毫秒，一个时间戳t能对齐到刻度上，当且仅当t % interval === 0（在某个基准下）。但这里有个关键细节：对齐的基准是什么？

如果直接用 Unix 时间戳（1970-01-01 00:00:00 UTC 起的毫秒数）对interval取模，那么对齐的刻度是全局统一的。比如间隔是5分钟（300000毫秒），那么所有t % 300000 === 0的时间戳，对应的都是 UTC 时间下能被5分钟整除的时刻，也就是每小时的 00、05、10、15... 分。这个基准在大多数场景下是合理的，因为它和人们习惯的"整点、整五分"是对齐的。

但有些场景下，用户希望的对齐基准是查询时间段的起点。比如查询从 10:03:22 开始，希望每5分钟取一个点，那么刻度就是 10:03:22、10:08:22、10:13:22... 这时候就不能用全局取模，而要用(t - start) % interval === 0。这两种基准的选择取决于业务语义，后面会详细对比。

2.3 为什么浮点数和精度是隐形杀手

JavaScript 里时间戳通常是毫秒整数，看起来取模很安全。但实际数据里经常混入秒级时间戳、ISO字符串、甚至带小数的时间。一旦出现浮点数，%运算的结果就可能出现0.0000001这种鬼东西，导致本该对齐的点被判定为不对齐。

我遇到过最坑的一次是后端返回的时间戳是秒级浮点数，比如1699999999.123，前端乘以1000转毫秒后变成1699999999123.0000001，取模结果不是0，整批数据全被过滤掉了。排查了半天才发现是浮点精度问题。所以后面讲实现时，我会强调先把所有时间统一规整成整数毫秒，再做取模。

2.4 方案选型的三个维度

在动手之前，先想清楚三个问题，它们决定了你该用哪种实现：

大多数真实场景下，数据不会恰好落在刻度上，总会有几毫秒到几秒的偏差。所以"精确相等"往往不实用，需要引入容差。而容差多大合适，又取决于数据的采集频率和业务对精度的要求。这些取舍我会在下一章结合代码展开。

3. 核心实现：从朴素遍历到生产级方案

3.1 第一步：统一时间格式，消灭精度隐患

不管后面用什么算法，第一步永远是数据清洗。我习惯写一个normalizeTimestamp函数，把各种形态的时间统一成整数毫秒。

function normalizeTimestamp(value) { if (value instanceof Date) { return value.getTime(); } if (typeof value === 'number') { // 判断是秒级还是毫秒级：小于 1e12 认为是秒级 if (value < 1e12) { return Math.round(value * 1000); } return Math.round(value); } if (typeof value === 'string') { const parsed = Date.parse(value); if (Number.isNaN(parsed)) { throw new Error(`无法解析的时间格式: ${value}`); } return parsed; } throw new Error(`不支持的时间类型: ${typeof value}`); }

这里有几个经验点值得说。第一，Math.round而不是Math.floor，因为浮点误差可能让1699999999123.0000001向下取整变成1699999999123没问题，但如果是1699999999122.9999999，向下取整就变成1699999999122，差了一毫秒。四舍五入更稳。

第二，判断秒级还是毫秒级用1e12这个阈值。1e12毫秒大约是 2001 年，1e12秒则是公元 33658 年，所以任何小于1e12的数字基本可以断定是秒级时间戳。这个经验值在绝大多数业务场景下都适用。

第三，字符串解析优先用Date.parse，但它对格式有要求。像"2024-01-01 10:00:00"这种带空格的格式，在部分环境下解析会失败，最好先替换成 ISO 格式"2024-01-01T10:00:00"。我一般会加一层兜底：

const normalized = value.includes(' ') && !value.includes('T') ? value.replace(' ', 'T') : value; const parsed = Date.parse(normalized);

3.2 第二步：确定对齐基准与容差

统一格式之后，就要决定对齐策略。我把它抽象成一个配置对象：

const config = { interval: 5 * 60 * 1000, // 5分钟 tolerance: 1000, // 容差1秒 baseTime: null, // null表示用全局UTC刻度，否则用指定基准 };

baseTime为null时，对齐判断是t % interval落在[0, tolerance]或[interval - tolerance, interval]范围内。为什么两端都要判断？因为数据可能略微早于刻度，也可能略微晚于刻度。比如刻度是 10:05:00，数据是 10:04:59.500，它离刻度只差500毫秒，应该算对齐；数据是 10:05:00.300，也应该算对齐。

function isAligned(t, interval, tolerance, baseTime) { const base = baseTime === null ? 0 : baseTime; const offset = ((t - base) % interval + interval) % interval; return offset <= tolerance || offset >= interval - tolerance; }

注意这里用了((x % n) + n) % n这个技巧来处理负数取模。JavaScript 的%对负数返回负值，比如-100 % 300000是-100，直接比较会出错。加上n再取模就能规整到[0, n)区间。这个细节很多人会忽略，但在处理早于基准时间的数据时是必须的。

3.3 第三步：朴素遍历方案（适合小数据）

数据量不大（几千条以内）时，最直接的做法就是遍历一遍，逐个判断是否在时间段内且对齐。

function pickAlignedPoints(data, start, end, config) { const { interval, tolerance, baseTime } = config; const result = []; for (const item of data) { const t = normalizeTimestamp(item.timestamp); if (t < start || t > end) continue; if (isAligned(t, interval, tolerance, baseTime)) { result.push({ ...item, _normalizedTime: t }); } } return result; }

这个方案的好处是逻辑清晰、不容易出错，而且天然处理了乱序数据（虽然我们假设数据有序，但万一有乱序也不会漏）。缺点是 O(n) 全量遍历，数据量大时性能吃紧。

我实测过，在 10 万条数据上跑这个函数，Chrome 下大约 15-20 毫秒，其实也不算慢。真正的问题在于如果这个操作要频繁调用（比如用户拖动时间轴实时筛选），累积起来就卡了。所以数据量大且调用频繁时，需要优化。

3.4 第四步：二分查找 + 游标推进（适合大数据）

优化的核心思路是：既然数据有序，就没必要从头遍历。先用二分找到start的位置，然后从那里开始，每次直接跳到下一个对齐刻度附近，而不是逐条检查。

function binarySearchStart(data, target) { let lo = 0, hi = data.length - 1, ans = data.length; while (lo <= hi) { const mid = (lo + hi) >> 1; const t = normalizeTimestamp(data[mid].timestamp); if (t >= target) { ans = mid; hi = mid - 1; } else { lo = mid + 1; } } return ans; }

找到起点后，理论上可以按刻度步进：从第一个对齐刻度开始，每次加interval，然后在数据里找最接近该刻度的点。但这里有个陷阱——如果某个刻度附近根本没有数据（设备断线了），你不能死等，得跳到下一个刻度。所以实际实现是"双指针"式的：一个指针在数据上走，一个刻度在时间轴上走，谁落后谁前进。

function pickAlignedFast(data, start, end, config) { const { interval, tolerance, baseTime } = config; const base = baseTime === null ? 0 : baseTime; const result = []; let idx = binarySearchStart(data, start - tolerance); // 计算第一个大于等于 start 的对齐刻度 let tick = Math.ceil((start - base) / interval) * interval + base; while (idx < data.length && tick <= end + tolerance) { const t = normalizeTimestamp(data[idx].timestamp); if (t < tick - tolerance) { idx++; } else if (t > tick + tolerance) { tick += interval; } else { result.push({ ...data[idx], _normalizedTime: t, _tick: tick }); idx++; tick += interval; } } return result; }

这个方案的时间复杂度是 O(log n + k)，k 是结果数量，比全量遍历的 O(n) 快得多。在 100 万条数据上，二分方案大约 2-3 毫秒就能出结果，而全量遍历要 150 毫秒以上。差距在实时交互场景下非常明显。

不过要注意，这个方案假设数据严格按时间递增。如果数据有重复时间戳或者轻微乱序，双指针可能会跳过一些点。生产环境里我一般会先做一次排序和去重，或者用容差窗口放宽匹配范围来兜底。

3.5 两种方案的对比与选择

我的建议是：如果数据量在几千条以内，或者调用不频繁，直接用朴素遍历，代码简单不易错。只有当数据量上万且需要频繁调用时，才上二分方案。过早优化是万恶之源，这句话在数据处理里同样适用。

4. 实操中的关键细节与避坑指南

4.1 时间戳精度：秒级与毫秒级的混用灾难

前面提过浮点精度问题，这里再展开说一个更隐蔽的坑：同一批数据里混用秒级和毫秒级时间戳。有些老设备上报的是秒级，新设备上报的是毫秒级，如果清洗逻辑没做好，就会出现"新设备的数据全部被判定为未来时间"的诡异现象。

因为秒级时间戳1699999999被当成毫秒处理后，对应的是 1970 年，而毫秒级1699999999123对应的是 2023 年。两者相差 50 多年，时间段筛选直接全军覆没。

我的处理方式是：在normalizeTimestamp里用阈值判断，同时加一个数据校验步骤，统计清洗后时间戳的最小值和最大值，如果跨度超过合理范围（比如超过 100 年），就报警提示可能混用了单位。

function validateTimeRange(data) { const times = data.map(d => normalizeTimestamp(d.timestamp)); const min = Math.min(...times); const max = Math.max(...times); const spanYears = (max - min) / (365 * 24 * 3600 * 1000); if (spanYears > 100) { console.warn(`时间跨度异常: ${spanYears.toFixed(1)} 年，请检查时间戳单位是否混用`); } }

4.2 时区问题：UTC 对齐还是本地时间对齐

用t % interval做全局对齐时，对齐的是 UTC 刻度。对于间隔能整除一天的场景（比如 1 分钟、5 分钟、15 分钟、30 分钟、1 小时），UTC 刻度和本地时间刻度是对齐的，因为时区偏移通常是整小时或半小时。但对于像"每天 8 点"这种需求，就必须考虑时区。

更麻烦的是有些地区有夏令时，一年里会有一次时间跳变，导致某天的刻度数量不是 24 个。如果业务对本地时间敏感，就不能用简单的取模，而要用日期库（如dayjs、date-fns）按本地时间构造刻度序列，再逐个匹配。

我的经验是：如果业务只关心"每N分钟"这种相对间隔，用 UTC 取模最省事；如果业务关心"每天几点"这种绝对时刻，老老实实用日期库处理时区。不要试图用取模硬扛时区问题，那是给自己挖坑。

4.3 容差设置：太大漏点，太小丢点

容差是这类抽取逻辑里最需要调参的地方。设太小，数据因为网络延迟偏了几百毫秒就被丢掉；设太大，相邻两个刻度的数据可能被重复匹配到同一个刻度上。

一个实用的经验公式是：容差取间隔的 5% 到 10%，但不超过数据平均采集间隔的一半。比如间隔是 5 分钟（300秒），容差可以取 15-30 秒；但如果数据平均每 10 秒上报一次，容差就不该超过 5 秒，否则一个刻度窗口里会挤进好几条数据。

当容差窗口里有多条数据时，要决定取哪一条。常见策略有三种：取最接近刻度的、取窗口内第一条、取窗口内最后一条。我一般默认取最接近的，因为它在时间上最有代表性。

function pickClosest(candidates, tick) { return candidates.reduce((best, cur) => { const curDiff = Math.abs(normalizeTimestamp(cur.timestamp) - tick); const bestDiff = Math.abs(normalizeTimestamp(best.timestamp) - tick); return curDiff < bestDiff ? cur : best; }); }

4.4 边界处理：start 和 end 是否包含

时间段筛选的边界是开区间还是闭区间，这个看似小的问题经常引发争议。我的做法是默认闭区间[start, end]，因为用户说"10点到11点"通常包含两端。但在对齐判断时，由于有容差，实际匹配范围会扩展到[start - tolerance, end + tolerance]，然后再用原始时间戳做一次严格的范围过滤，确保结果不会超出用户预期。

还有一个边界情况是：如果start本身不在对齐刻度上，第一个结果应该从start之后的第一个刻度开始，还是从start之前最近的刻度开始？这取决于业务语义。做监控采样通常取之后的，做数据回填可能取之前的。我一般把这个做成配置项boundaryMode: 'after' | 'before' | 'nearest'，让调用方决定。

4.5 性能实测数据

为了让大家对性能有个直观感受，我在本地跑了一组测试（Node.js 18，普通笔记本）：

可以看到数据量越大，二分方案的优势越明显。但 10 万条以内，朴素遍历其实完全够用，没必要为了那十几毫秒引入更复杂的代码。选方案要看实际场景，不要盲目追求"最优"。

5. 常见问题排查速查表

实际开发中遇到的问题五花八门，我把高频问题和排查思路整理成表，方便对照。

5.1 一个真实的排查案例

有次线上反馈说某天的数据抽取结果比平时少了一半。我先查了数据量，发现原始数据正常；再查时间戳范围，发现那天的数据时间戳整体偏移了 1 小时。原因是那天正好是夏令时切换日，设备用的是本地时间，切换后时间戳跳变，导致大量数据落在了刻度之间的"空隙"里。

解决办法是在对齐判断前，先把所有时间戳统一转成 UTC，用 UTC 刻度做匹配，最后再转回本地时间展示。这样无论夏令时怎么跳，UTC 刻度始终是均匀的。这个案例告诉我们：只要涉及跨天、跨时区的数据，UTC 是唯一安全的中间表示。

5.2 另一个隐蔽的坑：数组越界与空数据

二分查找的边界条件很容易写错。我见过最常见的 bug 是hi = data.length而不是data.length - 1，导致访问data[data.length]返回undefined，然后normalizeTimestamp(undefined)抛异常。还有一种情况是数据为空数组，二分直接返回 0，后续循环访问data[0]也是undefined。

所以任何二分实现后面，都要加一层防御：

if (!data || data.length === 0) return [];

以及在循环里访问数据前判断idx < data.length。这些防御性代码看起来啰嗦，但能省下大量排查时间。

6. 可复用的完整实现与扩展思路

6.1 封装成一个通用工具函数

把前面的逻辑整合起来，我通常会封装成这样一个函数，配置驱动，开箱即用：

function extractAlignedData(data, options) { const { start, end, interval, tolerance = Math.min(interval * 0.1, 5000), baseTime = null, boundaryMode = 'after', strategy = 'closest', } = options; if (!Array.isArray(data) || data.length === 0) return []; if (interval <= 0) throw new Error('interval 必须大于 0'); if (tolerance >= interval / 2) { throw new Error('tolerance 必须小于 interval 的一半，否则刻度窗口会重叠'); } const startMs = normalizeTimestamp(start); const endMs = normalizeTimestamp(end); const base = baseTime === null ? 0 : normalizeTimestamp(baseTime); // 根据 boundaryMode 确定第一个刻度 let firstTick; if (boundaryMode === 'after') { firstTick = Math.ceil((startMs - base) / interval) * interval + base; } else if (boundaryMode === 'before') { firstTick = Math.floor((startMs - base) / interval) * interval + base; } else { firstTick = Math.round((startMs - base) / interval) * interval + base; } const result = []; let idx = binarySearchStart(data, firstTick - tolerance); let tick = firstTick; while (idx < data.length && tick <= endMs + tolerance) { const t = normalizeTimestamp(data[idx].timestamp); if (t < tick - tolerance) { idx++; } else if (t > tick + tolerance) { tick += interval; } else { // 收集当前刻度窗口内的所有候选 const candidates = []; let scan = idx; while (scan < data.length) { const st = normalizeTimestamp(data[scan].timestamp); if (st > tick + tolerance) break; candidates.push(data[scan]); scan++; } const picked = strategy === 'first' ? candidates[0] : strategy === 'last' ? candidates[candidates.length - 1] : pickClosest(candidates, tick); result.push({ ...picked, _tick: tick }); idx = scan; tick += interval; } } return result; }

这个函数把前面讨论的所有细节都收进去了：格式统一、容差校验、边界模式、多候选策略、二分加速。调用起来很直观：

const result = extractAlignedData(rawData, { start: '2024-01-01T00:00:00Z', end: '2024-01-01T01:00:00Z', interval: 5 * 60 * 1000, tolerance: 2000, boundaryMode: 'after', strategy: 'closest', });

6.2 扩展方向：从抽取到聚合

抽取只是第一步，很多场景下抽完之后还要做聚合。比如每5分钟取一个点之后，计算这一小时内的平均值、最大值、最小值。这时候可以在抽取的基础上加一层聚合：

function aggregateByTick(data, interval, baseTime, aggregator) { const groups = new Map(); for (const item of data) { const t = normalizeTimestamp(item.timestamp); const base = baseTime === null ? 0 : baseTime; const tick = Math.floor((t - base) / interval) * interval + base; if (!groups.has(tick)) groups.set(tick, []); groups.get(tick).push(item); } const result = []; for (const [tick, items] of groups) { result.push({ tick, value: aggregator(items) }); } return result.sort((a, b) => a.tick - b.tick); }

注意这里用的是Math.floor而不是取模判断，因为聚合场景下每个数据都要归属到某个刻度区间，而不是只挑对齐的点。这是抽取和聚合的本质区别：抽取是"选点"，聚合是"分桶"。

6.3 扩展方向：处理超大数据的流式方案

如果数据大到内存放不下（比如几千万条日志），就不能一次性加载了。这时候要用流式处理：数据按时间排序后逐条读入，维护一个当前刻度的游标，数据时间超过当前刻度窗口就输出结果并推进刻度。

function createStreamingExtractor(options) { const { interval, tolerance, baseTime, start, end } = options; const base = baseTime === null ? 0 : baseTime; let tick = Math.ceil((normalizeTimestamp(start) - base) / interval) * interval + base; const endMs = normalizeTimestamp(end); const buffer = []; return { push(item) { const t = normalizeTimestamp(item.timestamp); const output = []; while (tick <= endMs + tolerance && t > tick + tolerance) { if (buffer.length > 0) { output.push({ ...pickClosest(buffer, tick), _tick: tick }); buffer.length = 0; } tick += interval; } if (t >= tick - tolerance && t <= tick + tolerance) { buffer.push(item); } return output; }, flush() { const output = []; while (tick <= endMs + tolerance) { if (buffer.length > 0) { output.push({ ...pickClosest(buffer, tick), _tick: tick }); buffer.length = 0; } tick += interval; } return output; }, }; }

流式方案的内存占用只和容差窗口内的数据量有关，和总数据量无关，非常适合处理海量日志。代价是代码复杂度上升，而且要求数据必须有序输入。如果数据源本身无序，还得先做外部排序，那就另说了。

6.4 几个我踩过的坑，直接告诉你

第一个坑：不要用new Date(t).getMinutes() % 5 === 0来判断对齐。这个逻辑看起来直观，但它判断的是"分钟数能被5整除"，忽略了秒和毫秒。10:05:30 的分钟数是5，能被5整除，但它显然不对齐到5分钟刻度。正确做法还是用时间戳取模。

第二个坑：容差不要设成 interval 的一半以上。如果容差是 interval 的一半，相邻两个刻度的窗口就会在中间相接，一条数据可能同时落在两个窗口里，导致重复。我一般把容差控制在 interval 的 10% 以内。

第三个坑：注意Date.parse对"2024-01-01"这种纯日期字符串的时区处理。在 ES5 规范里，纯日期格式被当作 UTC，而带时间的格式被当作本地时间。这个不一致性会导致跨时区环境下结果偏差。稳妥做法是永远带上时区标识，比如"2024-01-01T00:00:00Z"或"2024-01-01T00:00:00+08:00"。

第四个坑：数据里的时间戳字段名可能不统一。有的叫timestamp，有的叫time，有的叫ts，还有的嵌套在metadata.createdAt里。写通用工具时，最好把"取时间戳"这个操作也做成可配置的：

const getTime = options.getTime || ((item) => item.timestamp);

这样不管数据长什么样，调用方传一个取值函数就能适配。

6.5 测试用例怎么写才靠谱

这类时间处理逻辑，光靠肉眼看代码很难发现边界 bug，必须写测试。我一般会覆盖这几类用例：

• 数据恰好落在刻度上（精确匹配）
• 数据略微早于刻度（容差内）
• 数据略微晚于刻度（容差内）
• 数据落在两个刻度中间（应该被丢弃或归到最近刻度）
• 数据在 start 之前和 end 之后（应该被排除）
• 空数组、单元素数组
• 时间戳为秒级、毫秒级、ISO字符串的混合输入
• 跨天、跨月、跨年的数据

const testCases = [ { name: '精确对齐', data: [{ timestamp: 1704067200000 }], // 2024-01-01T00:00:00Z options: { start: 1704067200000, end: 1704067500000, interval: 300000 }, expect: 1, }, { name: '容差内偏移', data: [{ timestamp: 1704067201500 }], // 晚1.5秒 options: { start: 1704067200000, end: 1704067500000, interval: 300000, tolerance: 2000 }, expect: 1, }, { name: '超出容差', data: [{ timestamp: 1704067205000 }], // 晚5秒 options: { start: 1704067200000, end: 1704067500000, interval: 300000, tolerance: 2000 }, expect: 0, }, ];

每次改完逻辑跑一遍这些用例，能挡掉 90% 的低级错误。时间处理这种东西，直觉往往靠不住，测试才是真理。

6.6 关于性能优化的最后一点心得

我见过有人为了追求极致性能，把对齐判断写成位运算，比如t & (interval - 1) === 0。这招只在 interval 是 2 的幂时成立（比如 1024 毫秒），而且可读性极差。对于 5 分钟、15 分钟这种非 2 的幂的间隔，位运算根本不适用。

我的观点是：时间处理的性能瓶颈通常在数据量和调用频率，而不是单次取模运算。与其抠那几纳秒的位运算，不如把算法从 O(n) 优化到 O(log n)，收益大得多。而且时间代码的可读性和正确性远比微秒级性能重要，毕竟一个时区 bug 造成的损失，够你跑几百万次取模了。

真要做性能优化，优先考虑这几个方向：数据预处理时建时间索引、用二分代替遍历、结果做缓存（相同查询参数直接返回上次结果）、大数据用 Web Worker 或流式处理避免阻塞主线程。这些才是真正能提升体验的优化点。