电梯调度题目集1~3 — 阶段性总结与复盘
本文为三次电梯调度题目集（单类实现 → SRP分层实现 → 引入乘客实体）的阶段性技术博客。内容包含：前言、设计与分析（重点分析三次“单部电梯调度”题目的提交源码）、采坑心得（包含数据、类设计结构、流程图与测试结果）、改进建议与阶段性总结。
一、前言
本阶段包括三次题目集：
题目集1（单类实现）：在一个 Elevator/Main 单类或扁平结构中完成电梯的全部功能：状态管理、内外请求管理、调度逻辑和 I/O。该实现侧重快速交付与功能完整性；题量为单个集中任务，涵盖输入解析、队列管理与一步步运行模拟。难度定位为中等（对初学者而言理解并保证边界情况正确处理具有挑战）。
题目集2（SRP 重构）：按照单一职责原则将系统拆分为若干类（电梯类、请求类/队列类、控制类等），要求去除单类职责过多的问题，并增加对无效/重复请求的过滤。此阶段强调设计质量与模块接口规范，难度较题目集1提高，需理解设计模式与面向对象设计原则。
题目集3（引入 Passenger 实体）：进一步演化外部请求模型，由<楼层,方向>变为<源楼层,目的楼层>，引入 Passenger 实体并在外部请求处理完成后将乘客目的地加入电梯内部队列。此阶段更贴近真实场景，设计和测试复杂度进一步上升。
三次题目集中共同目标是：实现功能正确、设计合理、边界安全、可测试并可迭代改进。总体题量集中（每次为同类仿真程序），难度呈阶梯上升：第1次偏实现，第2次偏设计，第3次偏建模与系统交互。
二、设计与分析
2.1 题目集1（单类实现）——实现快照与关键行为
概述
设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例:
在这里给出一组输入。例如：
1
20
❤️,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例:
在这里给出相应的输出。例如：
Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
电梯运行过程详解.pdf
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB
题目集1 的提交以 Main + 内部静态 Elevator 类形式完成。实现特点：输入解析与调度逻辑耦合在 Main；Elevator 持有两个队列（内部请求 inside 与外部请求 outside），outside 为区分方向的请求队列（OutsideRequest 内含 floor 与 dir）。调度规则按题目要求：电梯移动时优先处理同向请求，达到楼层检查是否停靠并开关门；空闲时选择最近请求决定方向。
主要类/模块（摘要）
Main：负责 I/O、parse、将请求构造成 Request 并交给电梯。
Elevator：持有 current、dir、inside: Queue
设计优点
快速实现完整功能，便于测试与观察运行轨迹；
逻辑直观：getTarget() 在 dir==STOP 时用距离选择目标，在移动状态下寻找同向最近请求。
设计缺陷和可改进点（代码级）
-
职责耦合：Main 同时承担输入解析和调度启动，Elevator 内部仍承担太多决策（目标选择、队列更新、打印输出），不利于单元测试。
-
队列语义不明确：inside、outside 均使用 Queue（FIFO），但电梯调度常需要按楼层排序或按方向筛选，不适合简单队列的语义；更合适的是 TreeSet/优先队列或双向链表并按方向维护顺序。
-
重复/非法请求处理不足：实现中对无效楼层有检查但没有对连续重复请求做统一过滤，且 outside 队列可能出现与当前方向不匹配但位置相同的请求被延迟处理。
-
开关门打印格式小瑕疵：openDoor() 中 System.out.print("Close Door") 可能与题目示例要求换行不一致。
类图
Main：负责 I/O 与解析（main / parseRequest），包含静态枚举 RequestType 与 Direction（在源码中为内部枚举）。
Request：简单数据载体（type、floor、direction），由 Main.parseRequest 构建并传给 Elevator。
Elevator：承担大量职责（当前层、方向、内部/外部队列、调度算法、输出）。图中 OutsideRequest 为 Elevator 的内部类，聚合为 composition（*-- 表示强包含）。
该实现单体化，Elevator 方法（run、getTarget）包含复杂调度逻辑，解释了为何该版本单方法复杂度高。
源码复杂度与质量
代码行数集中，Elevator.run() 方法较长，包含多个分支与循环，建议拆分为更小的私有方法以降低认知复杂度。
getTarget() 的距离计算逻辑在 dir==STOP 与移动状态下两套分支，有重复代码片段可合并。
2.2 题目集2（SRP 重构）——模块化与请求过滤
概述
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。
电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
注意：本次作业类设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次电梯程序提交到本次题目中测试）。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：
1
20
❤️,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例1:
在这里给出相应的输出。例如：
Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
输入样例2:
在这里给出一组输入。例如：
1
20
❤️,UP>
❤️,UP>
<5>
<5>
<5>
<6,DOWN>
<7>
<7>
<3>
<22,DOWN>
<5,DOWN>
<30>
END
输出样例2:
在这里给出相应的输出。例如：
Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB
题目集2 将系统拆分为：ElevatorCar（电梯实体）、RequestManager（请求注册与队列管理）、CallRequest/DestinationRequest（请求类）以及 ElevatorSystem（控制类）。此实现主动处理重复请求与越界请求，并将请求录入 RequestManager 后由 ElevatorSystem 负责调度。
主要类/职责
ElevatorCar：封装楼层位置、方向、运动方法（ascend()、descend()）与门操作；只负责电梯内部状态与基本动作。
RequestManager：负责注册、去重（通过 lastCall/lastDestination 记录）与队列维护，提供 peek/poll 接口。
ElevatorSystem：集中控制调度、停靠判定、方向调整与移动行为。
设计优点
- 单一职责划分明显：每个类职责清晰，更便于单元测试与单元替换（如换队列实现）;
- 输入预处理：RequestManager 做了越界与连续重复过滤（lastCall/lastDestination 逻辑），减少主调度负担；
- 调度逻辑更明确：ElevatorSystem 根据 RequestManager 的 peek 信息决定方向，ElevatorCar 不再直接访问请求队列。
设计缺陷与潜在问题
-
去重策略欠灵活：使用 lastCall/lastDestination 仅能去掉“连续重复”请求，但不能去掉队列中任意位置的重复（例如：<3>、<5>、<3>）会被视为有效。若要求全局去重需在 RequestManager 中采用 Set 结合顺序结构。
-
clearProcessedRequests() 方法语义含糊：示例代码中对 clearProcessedRequests() 的实现可能误删未对应的请求，需仔细审查。
-
测试覆盖需补强：边界测试（无请求、所有无效请求、方向切换时多个同层请求）需要更多的单元测试用例。
类图
MoveDirection：替代了 v1 中的 Direction，并提供 parseDirection()（源码中存在）。
CallRequest / DestinationRequest：分别表示外部呼叫与车内目的地请求（数据对象 + 验证方法）。
RequestManager：负责请求队列管理（入队、去重、peek/poll），实现 SRP（把请求管理从控制器抽离）。
ElevatorCar：只负责电梯状态与物理操作（升降、开关门、显示状态）。
ElevatorSystem：控制器，负责调度决策、移动控制与停靠处理（核心调度逻辑在此）。该设计把复杂逻辑在类间拆分，降低了单方法复杂度（但仍有局部复杂方法）。
2.3 题目集3（引入 Passenger）——模型化与队列联动
概述
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。
电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：
1
20
<5,4>
<5>
<7>
end
输出样例1:
在这里给出相应的输出。例如：
Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
输入样例2:
在这里给出一组输入。例如：
1
20
<5,9>
<8>
<9,3>
<4>
<2>
end
输出样例2:
在这里给出相应的输出。例如：
Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Open Door # Floor 8
Close Door
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
Current Floor: 3 Direction: DOWN
Current Floor: 2 Direction: DOWN
Open Door # Floor 2
Close Door
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB
题目集3 将外部请求由 <楼层,方向> 改为 <源楼层,目的楼层>，引入 Passenger 实体。系统要求：当外部请求在源楼层被处理（乘客上电梯）后，把该乘客目的楼层追加到电梯内部队列（尾部）。此改动使得外部请求携带完整意图数据，同时增加了内部队列的动态生成行为。
主要类/职责
Passenger：表示从 sourceFloor 到 destinationFloor 的请求，包含 getDirection() 与 isValid() 校验方法。
RequestManager：维护 externalRequests: LinkedList
ElevatorSystem 与 ElevatorCar：延续 SRP 实现，但需要在处理外部请求时向内部请求队列追加目的地。
设计优点
语义更丰富：Passenger 蕴含上下行意图，使调度逻辑在停靠时能同时把目的地转入内部队列；
更接近真实流程：上车后乘客在车内发出目的地请求的动作被写入系统，便于后续扩展（比如乘客计数、容量限制、优先级）。
设计挑战
-
外部请求的排序语义：当多个 Passenger 在 externalRequests 中，如何在不同方向与楼层之间选择最优次序（如同向同路的合并）需要更细化的策略；
-
内部队列尾部加入策略：直接 offer(destination) 将目标加在队尾是简单可行的实现，但在复杂流量下可能导致“反复走楼层”的低效问题；需要考虑使用按方向排序或优先级数据结构；
-
并发与串行化设计：题目采用串行请求模型，若后续支持并发请求则需进一步考虑线程安全与事件驱动调度。
类图（简化 PlantUML）
Passenger：域模型（sourceFloor、destinationFloor），带验证与方向计算方法 getDirection()。这是语义最丰富的模型，有利于后续扩展（如计费、优先级）。
RequestManager：维护 externalRequests: LinkedList
ElevatorSystem：调度器读取 getAllExternalRequests() / getAllInternalRequests() 来决定是否在当前层停靠并在停靠时将 Passenger.destination 加入内部队列。
需要注意：源码中对集合的遍历/修改要用 Iterator 安全移除；图中显示组合关系（RequestManager 包含多个 Passenger）。
指标 题目集1 题目集2 题目集3
总行数 238 593 628
类数量 4 9 9
枚举数量 2 1 1
方法数量 11 30 33
最大方法圈复杂度 22 21 20
平均方法复杂度 7.27 3.37 4.1
最长方法行数 43 37 37
SourceeMonitor报表
三、采坑心得（代码提交与测试过程中遇到的问题与数据说明）
本节基于三次迭代开发中常见问题做详实记录，目的是让后续复现更少踩坑、提交更高质量代码。内容包含：问题描述、复现步骤、定位方法、改进措施与测试数据或流程图说明。
3.1 常见问题一：输入解析与字符串格式容错
现象：学生提交中普遍在输入解析处出错（例如 trim()/大小写判断、< > 包裹与逗号分割异常），导致程序在读取到 end/END 时不能正常终止或在遇到空行/额外空格时报错。
定位方法：在 Scanner.nextLine() 后立即 trim()，并统一用 equalsIgnoreCase("end") 或正则 ^\send\s$ 判断；解析请求前先判断字符串是否以 < 开始并以 > 结束。
改进：实现一个 InputParser 小类负责：去掉首尾空白、检查包裹字符、统一大小写、对逗号分割后 parts.length 做严格范围校验、捕获 NumberFormatException 并返回 Optional.empty()。
示例测试：
输入 " ❤️,UP> " → 能正确解析为外部请求。
输入 "END"、"end"、" End " → 能正常结束。
3.2 常见问题二：重复请求与队列去重策略
现象：使用 lastRequest 去重只能屏蔽连续重复，但无法屏蔽“后到重复”。提交中部分队列出现了多次相同目的地，导致不必要的停靠。
定位方法：阅读 RequestManager.register… 的去重实现，发现仅与 lastCall 比对。
改进：建议采用 LinkedHashSet（保持插入顺序的同时去重）或在 RequestManager 内维护 Set 索引（例如 Set
数据参考（伪示例）：
原策略：队列 3,5,3 → 触发 3 次停靠。
改进后：队列 3,5,3 → 变为 3,5（若要求同一轮次内去重）。
3.3 常见问题三：方向切换与“同向优先”边界
现象：实现 getTarget() 时若只对队头元素做判断，会忽略队列中存在的“更优”同向请求，导致电梯绕路或反复切换方向。
定位方法：通过单步调试 run() 循环，观察 sameDir 集合的构建方式以及是否遍历整个队列或仅看队首。
改进：在查找同向请求时，应遍历全部请求集合（或使用基于方向的有序集合），找出所有在当前方向上的请求并选择最近的目标（按绝对楼层差最小）。数据结构推荐：TreeSet
3.4 常见问题四：开关门输出与题目格式不一致
现象：打印行尾或换行不一致导致输出与样例不符，从而被自动评测判为 WA。
定位方法：审查所有 System.out.print 与 println 的调用，确保 Open Door # Floor n 与后续 Close Door 各占一行。
改进：统一使用 println，或构建 Printer 封装输出行为，减少格式差异错误。
3.5 常见问题五：队列并发修改与迭代器安全（在本题串行模型下少见）
现象：在处理 externalRequests 与 internalRequests 时，代码用 for-each 遍历集合同时在内部 remove()，会引发 ConcurrentModificationException（在使用 Iterator/remove() 的实现中需注意）。
改进：使用 Iterator 并调用 iterator.remove() 或先收集待删元素到临时列表，遍历完毕后统一 removeAll()。
3.6 测试用例与结果说明（建议）
为保证覆盖，建议至少包含以下测试类别：
-
基础路径：若干正常请求，上行/下行混合。
-
重复/无效请求：连续重复、超出楼层范围、源与目的相同（对于 Passenger）。
-
方向切换场景：电梯处理完同向请求后需转向处理反向请求的连续场景。
-
中途插入请求：模拟在电梯运行过程中新增请求（串行模型可在队列尾追加），以观察系统响应是否符合“顺路优先”原则。
四、改进建议
4.1 改进数据结构
内部请求：使用 TreeSet
外部请求：使用 Map<Direction, TreeSet
4.2 改进调度算法
基于方向的最近优先：当电梯向上运行时，从上行集合选择最小的 higher(current)；当没有同向请求时再切换方向。
合并同楼层请求：对同一楼层的内外请求合并处理，避免重复停靠开门。
容量与优先级扩展：如果后续要支持多人并发或容量限制，可以给 Passenger 添加 timestamp 与 priority 字段，调度器可采用加权选择。
4.3 改进测试与可测性
单元测试：为 RequestManager、ElevatorCar、ElevatorSystem 编写单元测试；对 RequestManager 的去重与队列一致性编写边界测试。
日志替代打印：使用可配置的 Logger（或 Printer 接口）替代直接 System.out，在测试中可以捕获输出并断言格式与顺序。
引入示例驱动测试：把输入样例做成若干 .txt 文件与期望输出文件，做回归测试，保证输出格式稳定。
4.4 设计层面建议
明确接口契约：例如 RequestManager 提供的 peek/poll/contains 应保证并发安全与一致性；接口注释要明确语义（是否会删除、是否线程安全）。
拆分大型方法：run()、startOperation() 等方法应拆为 determineNextTarget()、moveOneFloor()、handleStop() 等小函数以降低圈复杂度并便于单元测试。
五、总结
5.1 学到了什么
-
从实现到设计的跨越：第一阶段侧重实现细节，第二阶段学习到面向对象的 SRP 原则及模块划分的价值；第三阶段通过引入 Passenger 实体体会到领域建模的重要性。
-
数据结构决定算法效率：从 Queue 到 TreeSet 的演化，直接影响查找同向最近请求的效率与代码复杂度。
-
测试与格式一致性的重要性：自动评测对输出格式敏感，统一的输出封装与系统化测试可避免很多 WA 问题。
5.2 需要进一步学习与研究的方向
高级调度算法：考虑多部电梯联动、负载均衡与等待时间优化。
并发与事件驱动模型：从串行请求演化到并发请求时，需要学习线程安全、事件队列与消息驱动架构。
形式化验证：对边界条件运用断言或模型检测，确保复杂场景下的正确性。
