1396. 设计地铁系统

NOTE

本文带有 todo 标签，表示尚未完成本人复刷。代码与推导已按公开题目和参考实现整理；刷完后可删除 frontmatter 中的 todo。

LeetCode：原题1
难度：中等
归类：栈/队列/哈希（设计、哈希表、字符串）
主解法：哈希表

先给结论

这道题的核心是用额外空间把查找或计数从线性扫描降为近似常数时间。面试时先说清楚“状态表示什么、为什么能排除其他候选、何时更新答案”，再写代码；只报出“用哈希表”还不足以证明理解。

题目描述

题目要求完成“设计地铁系统”。输入包括题目给定的输入，需要返回 boolean。完整限制以原题为准，解题时重点利用这些特征：设计、哈希表、字符串。

示例：

输入：
["UndergroundSystem","checkIn","checkIn","checkIn","checkOut","checkOut","checkOut","getAverageTime","getAverageTime","checkIn","getAverageTime","checkOut","getAverageTime"]
[[],[45,"Leyton",3],[32,"Paradise",8],[27,"Leyton",10],[45,"Waterloo",15],[27,"Waterloo",20],[32,"Cambridge",22],["Paradise","Cambridge"],["Leyton","Waterloo"],[10,"Leyton",24],["Leyton","Waterloo"],[10,"Waterloo",38],["Leyton","Waterloo"]]
输出：
[null,null,null,null,null,null,null,14.00000,11.00000,null,11.00000,null,12.00000]
解释：
UndergroundSystem undergroundSystem = new UndergroundSystem();
undergroundSystem.checkIn(45, "Leyton", 3);
undergroundSystem.checkIn(32, "Paradise", 8);
undergroundSystem.checkIn(27, "Leyton", 10);
undergroundSystem.checkOut(45, "Waterloo", 15);  // 乘客 45 "Leyton" -> "Waterloo" ，用时 15-3 = 12
undergroundSystem.checkOut(27, "Waterloo", 20);  // 乘客 27 "Leyton" -> "Waterloo" ，用时 20-10 = 10
undergroundSystem.checkOut(32, "Cambridge", 22); // 乘客 32 "Paradise" -> "Cambridge" ，用时 22-8 = 14
undergroundSystem.getAverageTime("Paradise", "Cambridge"); // 返回 14.00000 。只有一个 "Paradise" -> "Cambridge" 的行程，(14) / 1 = 14
undergroundSystem.getAverageTime("Leyton", "Waterloo");    // 返回 11.00000 。有两个 "Leyton" -> "Waterloo" 的行程，(10 + 12) / 2 = 11
undergroundSystem.checkIn(10, "Leyton", 24);
undergroundSystem.getAverageTime("Leyton", "Waterloo");    // 返回 11.00000
undergroundSystem.checkOut(10, "Waterloo", 38);  // 乘客 10 "Leyton" -> "Waterloo" ，用时 38-24 = 14
undergroundSystem.getAverageTime("Leyton", "Waterloo");    // 返回 12.00000 。有三个 "Leyton" -> "Waterloo" 的行程，(10 + 12 + 14) / 3 = 12

问题本质

用额外空间把查找或计数从线性扫描降为近似常数时间。需要解决的不是某个 API 的用法，而是如何用最少状态描述“已经处理什么、还剩什么”，并证明状态推进不会漏解。

数据结构与因果链

输入进入算法后，先建立哈希表所需的状态。
Map 或 Set 记录已经出现的值、频次、下标或从状态到结果的映射。
先查询当前元素需要的互补信息，再按是否允许复用当前元素决定写入时机。
满足终止条件后，把已经验证的状态转换成输出。

始终保持：处理当前元素前，哈希结构只包含题意允许使用的历史信息。

示例推演

输入：
["UndergroundSystem","checkIn","checkIn","checkIn","checkOut","checkOut","checkOut","getAverageTime","getAverageTime","checkIn","getAverageTime","checkOut","getAverageTime"]
[[],[45,"Leyton",3],[32,"Paradise",8],[27,"Leyton",10],[45,"Waterloo",15],[27,"Waterloo",20],[32,"Cambridge",22],["Paradise","Cambridge"],["Leyton","Waterloo"],[10,"Leyton",24],["Leyton","Waterloo"],[10,"Waterloo",38],["Leyton","Waterloo"]]
输出：
[null,null,null,null,null,null,null,14.00000,11.00000,null,11.00000,null,12.00000]
解释：
UndergroundSystem undergroundSystem = new UndergroundSystem();
undergroundSystem.checkIn(45, "Leyton", 3);
undergroundSystem.checkIn(32, "Paradise", 8);
undergroundSystem.checkIn(27, "Leyton", 10);
undergroundSystem.checkOut(45, "Waterloo", 15);  // 乘客 45 "Leyton" -> "Waterloo" ，用时 15-3 = 12
undergroundSystem.checkOut(27, "Waterloo", 20);  // 乘客 27 "Leyton" -> "Waterloo" ，用时 20-10 = 10
undergroundSystem.checkOut(32, "Cambridge", 22); // 乘客 32 "Paradise" -> "Cambridge" ，用时 22-8 = 14
undergroundSystem.getAverageTime("Paradise", "Cambridge"); // 返回 14.00000 。只有一个 "Paradise" -> "Cambridge" 的行程，(14) / 1 = 14
undergroundSystem.getAverageTime("Leyton", "Waterloo");    // 返回 11.00000 。有两个 "Leyton" -> "Waterloo" 的行程，(10 + 12) / 2 = 11
undergroundSystem.checkIn(10, "Leyton", 24);
undergroundSystem.getAverageTime("Leyton", "Waterloo");    // 返回 11.00000
undergroundSystem.checkOut(10, "Waterloo", 38);  // 乘客 10 "Leyton" -> "Waterloo" ，用时 38-24 = 14
undergroundSystem.getAverageTime("Leyton", "Waterloo");    // 返回 12.00000 。有三个 "Leyton" -> "Waterloo" 的行程，(10 + 12 + 14) / 3 = 12

阶段	要检查的内容
初始化	边界、辅助结构与默认答案是否符合定义
推进	当前动作是否只依赖已知正确状态
更新	当前状态何时有资格成为答案
结束	是否覆盖空输入、无解和极端规模

边界与陷阱

空输入、单元素、重复元素以及不存在合法答案时，要有明确返回值。
最容易错在键的类型、重复值覆盖下标，以及查询和写入顺序导致元素自用。
如果实现会修改输入，面试时要主动说明；如果不能修改，则复制数据或改用额外结构。

代码实现

参考实现来源：JoshCrozier/leetcode-javascript，按本文结构重新整理；原项目采用 MIT License。

JavaScript 实现

var UndergroundSystem = function() {
  this.travels = new Map();
  this.averages = new Map();
};

/**
 * @param {number} id
 * @param {string} stationName
 * @param {number} t
 * @return {void}
 */
UndergroundSystem.prototype.checkIn = function(id, stationName, t) {
  this.travels.set(id, { startStation: stationName, startTime: t });
};

/**
 * @param {number} id
 * @param {string} stationName
 * @param {number} t
 * @return {void}
 */
UndergroundSystem.prototype.checkOut = function(id, stationName, t) {
  const { startStation, startTime } = this.travels.get(id);
  const route = `${startStation}-${stationName}`;
  const duration = t - startTime;

  if (!this.averages.has(route)) {
    this.averages.set(route, { totalTime: 0, count: 0 });
  }

  const record = this.averages.get(route);
  record.totalTime += duration;
  record.count += 1;

  this.travels.delete(id);
};

/**
 * @param {string} startStation
 * @param {string} endStation
 * @return {number}
 */
UndergroundSystem.prototype.getAverageTime = function(startStation, endStation) {
  const route = `${startStation}-${endStation}`;
  const { totalTime, count } = this.averages.get(route);
  return totalTime / count;
};

代码与思路对照

阶段	对应代码	作用
入口	`UndergroundSystem`	接收题目输入，入口签名与 LeetCode 元数据一致
初始化	`var UndergroundSystem = function()const { startStation, startTime } = this.travels.get(id);const route = \`${startStation}-${stationName}`;`<br />`const duration = t - startTime;`	建立后续推进所需的边界、缓存或答案变量
核心推进	`if (!this.averages.has(route))`	落实“先查询当前元素需要的互补信息，再按是否允许复用当前元素决定写入时机”
输出	`return totalTime / count`	只返回已经满足状态定义的最终结果

读代码时应把每个判断还原成“它排除了什么状态或完成了哪次转移”，而不是只记变量名。

复杂度分析

时间复杂度：O(1)。
空间复杂度：O(n)。

复杂度必须按“状态数量 × 每个状态处理成本”分析；如果存在排序、堆操作、递归深度或结果数组，需要单独计入，不能只看最外层循环。

面试官递进追问

1. 为什么本题适合哈希表？

因为用额外空间把查找或计数从线性扫描降为近似常数时间。 为什么问： 检查你是在识别性质，还是只凭题号背模板。回答要抓住可被利用的单调性、重复子问题或数据结构约束。

2. 代码维护的核心状态是什么？

Map 或 Set 记录已经出现的值、频次、下标或从状态到结果的映射。 为什么问： 状态定义决定代码是否可证明。回答时要让每个变量都能对应到题意。

3. 这个实现依赖什么不变量？

处理当前元素前，哈希结构只包含题意允许使用的历史信息。 为什么问： 不变量比逐行复述代码更能证明理解，回答要说明它在初始化、推进和结束时都成立。

4. 为什么这样推进不会漏掉答案？

先查询当前元素需要的互补信息，再按是否允许复用当前元素决定写入时机，被跳过的状态已经由题目性质证明不可能更优或已经处理完成。 为什么问： 检查正确性证明，重点不是“指针这样写”，而是“为什么可以排除”。

5. 最危险的边界是什么？

最容易错在键的类型、重复值覆盖下标，以及查询和写入顺序导致元素自用。 为什么问： 检查代码能否一次通过，回答要给出具体失败场景而不是只说“注意边界”。

6. 复杂度还能优化吗？

先看瓶颈来自状态数量、每次转移成本还是辅助结构操作；只有其中一项能被减少时，复杂度才可能继续下降。 为什么问： 检查你能否从成本组成出发优化，而不是机械背最优复杂度。

7. 如果输入规模扩大或数据改成流式，方案怎么变？

要判断当前算法是否需要随机访问全部输入；若只依赖有限历史状态，可以做滚动或在线维护，否则需要分块、外存或调整数据结构。 为什么问： 检查算法理解能否迁移到工程约束。

8. 有哪些替代解法，如何取舍？

可以从暴力枚举开始，再比较排序、哈希、搜索或动态规划等方案；取舍标准是时间、空间、是否修改输入和实现复杂度。 为什么问： 检查横向比较能力。回答要说明替代方案为什么更慢或在什么条件下更合适。

常见错误回答

“这题套哈希表模板即可”：只有结论，没有说明题目性质和排除依据。
逐行朗读代码：没有建立状态、不变量和正确性因果链。
只报 O(n) 或 O(n²)：没有解释每个状态被访问多少次，也容易漏掉排序或辅助结构。
把示例能跑通当成证明：示例只能帮助检查，不能覆盖重复值、空输入和极端边界。

可迁移总结

核心关键词：哈希表、状态定义、不变量、推进规则、边界。
一句话本质：用额外空间把查找或计数从线性扫描降为近似常数时间。
思考链路：识别题目性质 → 定义状态 → 证明推进安全 → 确定更新时机 → 检查边界与复杂度。
1 分钟回答：说清题型、核心状态、推进规则和复杂度。
3 分钟回答：补上正确性依据、示例和两个关键边界。
10 分钟回答：写出代码，并比较替代方案、空间优化和工程限制。

刷题后自测

先只回答第 1 题，再展开后续问题：

不看代码，你能用一句话说出本题的不变量吗？

如果把示例中的重复值、空输入或边界值换掉，哪一行代码最先受到影响？

不改变正确性的前提下，你能写出一种替代方案并比较复杂度吗？

#1396. 设计地铁系统

#先给结论

#题目描述

#问题本质

#数据结构与因果链

#示例推演

#边界与陷阱

#代码实现

#JavaScript 实现

#代码与思路对照

#复杂度分析

#面试官递进追问

#1. 为什么本题适合 哈希表？

#2. 代码维护的核心状态是什么？

#3. 这个实现依赖什么不变量？

#4. 为什么这样推进不会漏掉答案？

#5. 最危险的边界是什么？

#6. 复杂度还能优化吗？

#7. 如果输入规模扩大或数据改成流式，方案怎么变？

#8. 有哪些替代解法，如何取舍？

#常见错误回答

#可迁移总结

#刷题后自测