简介C# 模拟电梯控制是一套基于 Windows Forms 的完整 Visual Studio 工程面向初学 C# 的桌面应用开发者也适合准备课程设计或希望理解对象建模、事件驱动与多线程调度等机制的读者。源码通过电梯、楼层、乘客对象抽象还原核心逻辑借助委托与事件响应楼层呼叫以状态机管理开关门与上下行状态并结合线程同步与调度算法模拟电梯运行。压缩包共 27 个文件以 cs 源码为主体配合 sln/csproj 工程配置、resx/resources 界面资源、ico/bmp 图标素材、pdb 调试符号及 exe 可执行程序整体约 246KB可直接在 Visual Studio 中打开运行。工程内含入口与界面代码启动后通过 GUI 实时观察电梯响应与停靠过程对照源码可层层拆解设计模式、异常处理和测试思路。已有 282 人学习使用适合借助完整可运行示例快速掌握 C# 控制类项目的编写与调试技巧。1. 先想明白这源码到底在模拟什么如果你以为“C# 模拟电梯控制源码”就是把电梯在界面上上下移动那大概率会翻车。真正让它值得做的不是动画而是背后那套调度逻辑外呼怎么分配、内呼怎么排序、电梯什么时候换向、多台电梯会不会抢同一层楼。很多拿着别人源码来改的开发者最后都卡在“电梯动起来了但乱跑”这个环节上。这个方向适合三类人一是做课程设计或毕设需要一套能演示、能答辩的完整系统二是想学 C# 异步编程和状态机设计的开发者电梯恰好是两者结合得最好的练手场景三是准备面试作品想展示自己写过“带并发控制的项目”。这篇内容把 C# 模拟电梯控制源码从模型拆分、代码落地到踩坑排查完整梳理一遍你可以边看边照着你手上的版本来改。2. 把电梯问题拆成三个模型楼层、按钮、状态机2.1 电梯控制到底在控制什么先看运行闭环一台电梯在真实世界里同时处理两类请求一类是轿厢内的楼层按钮乘客已经进电梯目标明确另一类是每个楼层上下行按钮乘客还没进电梯只知道要去“上”或“下”。这两类请求汇聚到电梯控制器里控制器再输出两个结果当前位置和当前方向。整个控制闭环拆开看就三层运动控制负责“电梯走不走、走到哪停”逻辑控制负责“方向怎么定、目标怎么排序”调度控制负责“多台电梯谁来接这个外呼”。多数模拟源码翻车都是在逻辑控制这层偷了懒——把所有按钮塞进一个集合然后每次只挑最近的楼层完全不管方向一致性。结果就是电梯在 5 楼和 6 楼之间来回折腾乘客按钮按了个寂寞。所以写模拟电梯之前先把这三个问题分清楚。运动控制推进展逻辑控制定目标调度控制做分配。三个模块之间只通过电梯对象的状态字段通信别互相直接访问按钮队列。2.2 状态机设计Idle / Moving / DoorOpen 的流转条件电梯对象最适合用一个状态机来描述这也是绝大多数模拟源码的通用做法。状态枚举不需要太多五个就够用Idle、Moving、DoorOpening、DoorOpen、DoorClosing。这里不把 DoorClosed 单独列出来因为它可以合并进 Idle 或 Moving 之间否则状态太多反而难维护。public enum ElevatorStatus { Idle, // 停着门已关无目标 Moving, // 正在运行 DoorOpening, // 开门动画/计时 DoorOpen, // 门完全打开等待乘客 DoorClosing // 关门动画/计时 } public enum Direction { Up 1, Down -1, None 0 }状态流转的关键规则用文字描述更清楚Idle 状态下收到任意目标就变 MovingMoving 状态下到达某个目标楼层就变 DoorOpeningDoorOpening 计时结束变 DoorOpenDoorOpen 计时结束变 DoorClosingDoorClosing 结束如果还有目标就继续 Moving否则回 Idle。这套流转在任何一门语言里都成立但 C# 里最舒服的做法是用枚举做 switch而不是搞一堆布尔标志位。布尔标志位的典型反例是isMoving、doorOpen、isUp三个字段互相组合到后面你会发现“门开着但还在 Moving”这种非法状态根本拦不住。状态机的核心价值就是让非法状态在编译层面就不存在。2.3 用一张参数表定死行为速度、开门延时、超时模拟电梯不是越快越好。很多源码把移动延迟写成 50 毫秒一层电梯像子弹一样飞调度问题根本看不出来。我的建议是把参数统一收敛到一个配置类里不要在代码各处散落魔法数字。参数推荐初值说明楼层移动耗时400ms/层太快看不出调度冲突太慢演示煎熬开门耗时800ms模拟门完全打开的时间开门等待2500ms模拟乘客进出实际是调度节奏的节拍器关门耗时800ms关门后到启动的缓冲帧刷新周期100msUI 状态刷新频率和移动计时分开目标楼层误差0.1 层到达判断的容差防止浮点楼层永远对不齐楼层数建议用常量而不是写死在循环里比如TotalFloors 12。楼层数设定会影响调度测试的价值5 层以下任何算法都显得“合理”12 层以上才能暴露方向排序和换向的缺陷。3. 在 C# 里让电梯跑起来项目结构与异步主循环3.1 一个最小可运行的项目怎么组织拿到“C# 模拟电梯控制源码”第一件事不是读代码而是看项目结构。一个结构正常的模拟电梯项目文件夹长这样ElevatorSim/ ├─ ElevatorSim.sln ├─ ElevatorSim/ │ ├─ Models/ │ │ ├─ Elevator.cs │ │ ├─ Building.cs │ │ ├─ FloorPanel.cs │ │ └─ Enums.cs │ ├─ Core/ │ │ ├─ ElevatorController.cs │ │ └─ DispatchStrategy.cs │ ├─ UI/ │ │ ├─ MainForm.cs │ │ └─ ElevatorControl.cs │ └─ Program.csModels 放电梯和楼栋的数据结构Core 放调度算法UI 只负责渲染和接收按钮点击。这个分离做不好后面每一步都是坑。常见的问题是 UI 代码里直接改电梯目标集合调度逻辑散在按钮事件里结果就是一旦增加多电梯支持代码彻底重构。拿到源码先看 Models 和 Core 是否独立。如果所有逻辑都堆在 MainForm.cs 里那这个源码的学习价值就打折了建议自己按这个结构重写一遍。3.2 电梯实体类楼层、方向、目标集合的封装电梯实体类是所有逻辑的中枢设计上要做到“调度器只能修改目标集合不能直接拨动状态”。内呼按钮按下后其实是往目标集合里插入楼层同时电梯自己会在合适的时机取下一个目标。public sealed class Elevator { public int Id { get; } public int CurrentFloor { get; private set; } public Direction Direction { get; private set; } public ElevatorStatus Status { get; private set; } private readonly SortedSetint _targets new(); private readonly object _lock new(); public void AddTarget(int floor) { lock (_lock) { _targets.Add(floor); } } public bool HasTarget _targets.Count 0; public int NextTarget PickNextFloor(); }这里用SortedSetint保存目标楼层原因有二一是天然去重同一层内呼按一百次只会留一条二是默认有序调度器只需要做方向过滤不需要自己排序。_lock对象的作用后面避坑章节会详细讲这里的核心原则是按钮事件线程、调度线程、UI 定时器线程都可能同时访问目标集合不加锁后面必然出并发问题。方向字段不要用 bool 表示Direction.Up / Down / None三态才是真实场景因为电梯空闲时就是“无方向”状态。很多源码用isGoingUp布尔值然后到处判断“如果 isGoingUp 为 true 且当前在上行”读得人脑壳疼。3.3 异步移动循环为什么用 Timer 而不是 while(true)Thread.Sleep模拟电梯的主循环有两种主流写法System.Windows.Forms.Timer驱动还是async/await Task.Delay。我实测下来的结论是如果你做的是 WinForms 或 WPF 界面用 Timer 最简单如果做控制台版本的纯逻辑模拟用异步循环更干净。WinForms 里用 Timer 的最大好处是它在 UI 线程触发 Tick改界面控件不需要跨越线程。移动逻辑写成每 Tick 检查一次当前状态private async void MoveTimer_Tick(object sender, EventArgs e) { if (elevator.Status ! ElevatorStatus.Moving) return; int moveDelayMs 400; await Task.Delay(moveDelayMs); elevator.MoveOneFloor(); RefreshElevatorUI(); if (elevator.IsAtTarget()) { BeginDoorSequence(); } }这个 tick 函数里体现了两个关键参数moveDelayMs代表每层楼的移动耗时BeginDoorSequence()负责把状态机推向开门流程。注意这里的async void用在事件处理器里是安全的但不要在任何同步方法里调用它否则异常会直接炸线程。控制台版本更纯粹一个 while 循环一直跑直到电梯没目标才休眠但要注意必须让出控制权不能死循环空转。无论哪种写法核心思想都一样用时间驱动的状态推进而不是“按下按钮立即变楼层”。电梯移动是异步过程源码里如果看到Thread.Sleep(5000)直接阻塞 UI那一定不是合格做法。4. 调度算法落地优先方向、顺路捎带和换向4.1 单电梯调度SCAN 思路和它的前提多数单电梯源码用的都是 SCAN 算法的变体电梯保持当前方向把该方向上所有目标楼层走完再反方向接剩余请求。这个算法也叫“电梯算法”在真实电梯里广泛使用因为它能兼顾效率和公平。实现 SCAN 有个前提目标集合必须分成上行和下行两批。按下行外呼的乘客和按上行外呼的乘客他们的等待逻辑完全不同——一个在 8 楼按“下”说明他的目标楼层要低于 8 楼一个在 3 楼按“上”目标要高于 3 楼。正确做法是方向保持期间只处理“去往当前方向”的请求。具体说电梯在 5 楼向上运行此时目标集合里有 7、10 和 2 楼。SCAN 会先处理 7 和 10到了 10 楼没人了才换向下行然后停 2 楼。直接按“楼层差值排序”的做法就是“最近优先”会让电梯在上下两个方向反复横跳乘客体验极差。4.2 多电梯怎么分配外呼先到先得还是就近单电梯的逻辑搞清楚后多电梯分配的难度不在电梯本身而在于“谁来响应某个外呼”。常见做法有两种先到先得式谁先到达那个楼层谁接就近分配式调度器提前判断哪台电梯最合适直接指派。先到先得实现简单但会出现两台电梯同时开门抢人——乘客上哪台都不对。我更推荐做指派式外呼按钮按下时遍历所有电梯计算每台的优先级得分得分最高者负责此次外呼其他电梯保持不动。优先级得分一般看两个维度方向匹配电梯当前方向与外呼需求方向一致加分距离电梯当前楼层与外呼楼层差值越小越好负载状态如果电梯已经有很多目标减分避免忙的忙死闲的闲死。这三个因素按权重相加权重参数应该能在界面上调这样答辩时有演示材料可讲。4.3 调度核心代码PickNextFloor 的实现调度器最核心的方法是PickNextFloor()它从目标集合里挑出下一个停靠楼层。这里的逻辑能否写对直接决定了源码的可用性。private int PickNextFloor() { lock (_lock) { if (_targets.Count 0) return -1; var available new Listint(); if (Direction ! Direction.None) { // 按当前方向筛选上行时只找更高的楼层下行时只找更低的 foreach (var floor in _targets) { if (Direction Direction.Up floor CurrentFloor) available.Add(floor); if (Direction Direction.Down floor CurrentFloor) available.Add(floor); } } if (available.Count 0) { // 当前方向没有目标则允许反向 available.AddRange(_targets); } if (available.Count 0) return -1; // 同方向取最近一站 return Direction Direction.Up || Direction Direction.None ? available.Min() : available.Max(); } }这段代码的关键在三个地方一是方向过滤上行只挑高于当前楼层的目标二是反向兜底同方向没目标才允许反向三是取最近站上行取最小楼层下行取最大楼层。参数方面其实没有显式调参但你可以把“方向偏好”理解成一个隐含权重——只要同方向还有目标反向楼层永远不被选择这正是 SCAN 的行为特征。调用时机也很重要PickNextFloor()不应该在按钮点击时调用而应该在电梯完成一次停靠、即将进入移动状态的瞬间调用。这样每次取到的都是“当前位置当前方向”下的最优目标不会出现按下按钮后电梯目标集合更新不及时的情况。5. 模拟电梯源码最容易翻车的 5 个坑5.1 坑一两台电梯同时响应同一个外呼现象乘客在 8 楼按了下行按钮两台电梯几乎同时开门到达 8 楼乘客不知所措调度记录里出现两台电梯同层停靠的事件。 原因外呼按钮没有绑定“分配状态”。按钮被按下后调度器广播给所有电梯每个电梯都把这个楼层当成自己的目标。 解决外呼按钮需要增加一个AssignedElevatorId字段。按下后提交给调度器调度器选出最优电梯后写入该字段其他电梯检查到该外呼已被分配就直接忽略。public class FloorPanel { public int Floor { get; init; } public bool UpRequested { get; private set; } public bool DownRequested { get; private set; } public int? AssignedElevatorId { get; private set; } public void AssignTo(int elevatorId) { AssignedElevatorId elevatorId; } }这里的关键设计是外呼和“已分配的电梯”绑定而不是和“按钮状态”绑定。哪怕电梯 A 到达前按钮已经被电梯 B 分配A 也只会路过不会停靠。分配后要记得在电梯开门的同时清除外呼状态的 “指派人”否则下一轮外呼会有残留。5.2 坑二UI 卡死或按钮按下不响应现象电梯跑着跑着窗口像休眠了一样拖动窗口极其卡顿有时按钮点了没反应。这是初学异步最容易遇到的“玄学”问题。 原因代码里某处用了Thread.Sleep模拟开门延时或移动延时而那段代码跑在 UI 线程里。UI 线程被阻塞整个窗口自然假死。 解决把一切耗时操作替换为异步等待。凡是“等一会儿再继续”的业务逻辑统一用await Task.Delay(...)不要用Thread.Sleep。这两者的区别在于 Task.Delay 会释放当前线程继续响应界面而 Thread.Sleep 真的把线程挂起。5.3 坑三开门状态把整个调度卡住现象电梯到了某一层后门一直开着不关其他所有目标全部排队等待调度日志停在 “DoorOpen”。 原因状态机里DoorOpen没有任何超时退出条件。进入开门状态后直接卡死没人去推动它进入DoorClosing。 解决DoorOpen 状态必须引入一个计时器通常可以用DateTime doorOpenSince在 PickNextFloor 之前检查一次if (elevator.Status ElevatorStatus.DoorOpen) { if ((DateTime.Now - doorOpenSince).TotalMilliseconds doorOpenWaitMs) return; // 还在等乘客不做任何调度 elevator.StartClosingDoor(); }额外注意不要在 DoorOpen 状态下还接受新的内呼因为门开着时乘客可以按按钮但这只是把楼层加入目标集合电梯不应该立刻关门出发。等关门完成后调度器再取下一个目标。5.4 坑四遍历目标集合时抛 InvalidOperationException现象电梯运行中偶尔在拾取下一个目标时报System.InvalidOperationException: Collection was modified。 原因一个线程正在 foreach 遍历目标集合另一个线程同时往里添加了新楼层。这是经典的并发集合修改问题。 解决所有对目标集合的读写操作都放在同一个锁对象里foreach 时也要在锁内完成遍历。上面 PickNextFloor 的代码已经演示了lock (_lock)但要注意别只锁写不锁读。血泪经验就是C# 的SortedSet不是线程安全的集合任何遍历都可能在修改时爆炸。如果不想每个循环都加锁也可以换成ConcurrentDictionaryint, byte这类并发容器但语义没有 SortedSet 直观新手不建议。5.5 坑五外呼在高频运行时丢按钮现象连点几次同一个楼层的外呼按钮调度日志只显示第一次乘客明明按了两次内呼集合没有更新。 原因按钮点击事件直接操作 UI 状态而 UI 状态没有同步到控制器。界面亮了、亮了又灭内部控制器的目标集合没有收到指令。 解决按钮点击事件必须只做一件事——调用调度器接口提交请求。所有请求直接写入电梯的目标集合并且用时间戳记录请求顺序private void FloorButton_Click(object sender, EventArgs e) { int floor (int)((Button)sender).Tag; elevator.AddTarget(floor); // 只通过接口操作UI 只做反馈 UpdateButtonLights(); }记住界面状态是“显示层”控制器集合才是“事实层”。模拟源码里这种 UI 按钮反馈和实际数据不同步的错误相当隐蔽因为单线程运行时根本看不出问题只有加了异步移动后才会暴露。6. 再进一步群控、换乘和调度日志怎么验证单电梯跑通后真正的加分项是多电梯群控。把外呼按钮从“直接改某台电梯的目标”改成“提交到调度器统一分配”是这套源码里最值得扩展的架构升级。建议把调度器里的AssignBestElevator(int floor, Direction direction)单独提出来用独立的策略类封装。验证调度效果别靠肉眼看动画接一个 CSV 日志输出记录电梯号、请求楼层、分配时间、到达时间、托盘状态。字段少、比对直观电梯ID, 请求楼层, 请求方向, 分配耗时ms, 到达耗时ms, 换向次数 1, 8, Down, 12, 2300, 2对比不同分配策略的同一组请求序列比任何答辩截图都有说服力。换乘模型不建议新手直接做——那是在群控之上再叠加乘客路径规划复杂度翻倍一个外呼对应两台以上的电梯状态机和日志都得重构。我自己的习惯是先跑 30% 随机外呼、10% 高峰外呼的混合压力测试再把参数表中的开门等待从 2500ms 调到 500ms观察电梯是否进入“疲于奔命”状态。这种调参实验做完你对调度特征的理解会比看十份源码都深。希望帮到你。本文还有配套的精品资源点击获取