红绿灯配时实测：固定 60 秒 vs 自适应，2400 辆车差多少

四个进口各 600 辆/小时，一小时理论上有 2400 辆车经过这个路口。

泊松到达实际来了 2367 辆，我把同一批车喂给四种配时策略，只换信号灯的控制方式。

最快的是 LQF，平均延误 9.8 秒。最慢的是固定 90 秒周期，18.2 秒。

两者差 29%。

更反直觉的是，绿灯时间更长的固定 90 秒，输给了固定 60 秒。

这些数字不是我盯着一辆车掐表算的。

每辆车都有到达、排队、启动、通过四个时间戳，延误由仿真器逐秒推出来。

一、为什么值得看：红灯前的几十秒浪费在哪

路口有四条进口道，北、南、东、西。

每辆车按 60% 直行、25% 左转、15% 右转生成，右转不受灯控，直接走。

直行和左转跟随机动车绿灯，两相位轮转：南北放行，东西放行。

每次切换要 3 秒黄灯加全红，用来清空路口。

一个 60 秒周期切两次，固定损失 6 秒。绿灯刚亮还有 2 秒启动损失。

饱和流率按 1800 辆/小时算，但一个进口能过多少车，取决于它拿到多少绿时。

固定 60 秒给每个方向 27 秒绿，理论通行能力是 1800×27÷60，也就是 810 辆/小时。

固定 90 秒给 42 秒绿，理论值 840 辆/小时。

600 辆/小时的需求，已经占到固定 60 秒能力的 74%。

900 辆/小时则超过了两种固定周期的能力，排队会一直涨。

所以红灯等多久，不只是红时长的问题。损失时间、绿信比、需求量三者怎么配，才是关键。

二、四种策略，跑同一批车

我实现了四种控制方式，参数全部摆在页面上。

四种策略共用同一批到达车辆，随机种子 20261110，仿真 60 分钟，时间步长 0.1 秒。

车辆跟驰按 2 秒车头时距放行，第一辆车额外等 2 秒启动。

转向比例、饱和流率、清空时间都相同。变量只有控制逻辑。

三、2400 辆车的四种结果

先看 600 辆/小时这一档。

固定 90 秒的损失时间最低，只有 11.2%，但平均延误最高。

原因是它给每个方向 42 秒绿，不管那个方向有没有那么多车。

在 74% 的负荷下，多出来的绿时没有被车用掉，反而让另一个方向多等。

LQF 的损失时间最高，31.8%，平均延误却最低。

它把绿时花在队列更长的一对进口上，切换次数多，但每次切过去都有车可放。

这组数据说明，损失时间不是唯一指标。绿时给谁，同样决定等待。

四、需求量一变，结论就翻

同一套策略，只改每个进口的需求量，平均延误如下。

300 辆/小时这一档，固定 90 秒最差，13.8 秒。

车很少，它还是给每个方向 42 秒绿，另一边空等。

600 辆/小时这一档，感应控制和 LQF 领先，比固定 60 秒少等 27% 到 29%。

750 辆/小时时差距收窄，感应控制 13.8 秒，固定 60 秒 16.6 秒，只差 17%。

900 辆/小时是分水岭。

固定 60 秒的通行能力只有 810 辆/小时，需求 900 已经超过它，平均延误冲到 44.2 秒。

固定 90 秒和感应控制都做到 27.1 秒。

LQF 在这里崩了，77.6 秒。

它每 12 秒就比一次队列，谁长就给谁，切换了 207 次。

每次切换损失 3 秒清空加 2 秒启动，损失时间占比 28.8%，有效通行能力被自己吃掉。

到了 1000 辆/小时，固定 90 秒最好，67.7 秒。LQF 最差，201.2 秒。

所以没有一种配时在所有需求量下都赢。

低需求怕空放，高需求怕切换，过饱和时稳定的大周期反而更抗压。

五、验证与踩坑：感应控制第一版会丢绿灯

页面加载会跑 12 条自检，当前 12/12 通过。

自检覆盖固定周期的时长相加、同种子结果一致、延误非负、完成数不超过到达数、右转不占绿灯、LQF 优先放行长队列、零需求不出 NaN、非法输入被拦截。

这些自检不是装饰。它们确实抓出了一个逻辑错误。

第一版感应控制的条件是：对向有排队，且本方向 3 秒没有新车，就切换。

听起来合理，实际会丢绿灯。

900 辆/小时换算下来是 0.25 辆/秒，3 秒没有新车很常见，哪怕本方向还排着 8 辆车。

控制器把绿灯切走了，付了 3 秒清空和 2 秒启动，再切回来时队列更长。

修复只加了一个条件：本方向队列必须清空。

if (otherQ > 0 && quiet && ownQ === 0) beginClear(now);

改完之后，900 辆/小时的平均延误从 113.7 秒降到 27.1 秒。

600 辆/小时只从 11.1 秒降到 10.0 秒，差别不大。

这就是边界场景的价值。低负荷下看起来正常的逻辑，到接近饱和才暴露。

第二个真问题是场景定义。

我最初把 900 辆/小时标成高峰，可固定 60 秒的能力只有 810，这个场景其实已经过饱和。

四种策略都在排队，比出来的数字没有意义。

后来把高峰改成 600，过饱和改成 1000，才有了上面那张分档表。

失败路径也测了。需求输入 abc，页面不白屏，结果区保留上一次的有效数字。

错误条原文是「参数错误：每进口需求必须是数字　已保留上一次有效结果」。

六、准备环境：进入码道 Web

码道有三种使用方式：WebUI、TUI 和桌面 IDE。本文用 WebUI 版演示。

浏览器打开码道 Web 版：https://devcloud.cn-north-4.huaweicloud.com/chat?source=dmzntgwlb&sourcead=dmzntgwlb1&invitecode=INV-IXhxk5bwWx_qKSP1FcgSuiOEf6ruDXtjvLFiCH9nMs5dZGLapaSSylwt-cKRj5LoT3MlxikWxy8VhqplfvtQjefQOq31Tbp3R3wYP3K535Cn4XTaUzqqExKPYTWvvw4LijV14IS1torXdTGp7oyXb6SR5VxgYTg50jM

登录后直接在对话框里描述需求，不需要装软件。

这个页面是单文件 index.html，没有外部脚本、字体和图片，断网也能打开。

七、直接下载试玩

这个 Demo 已经完整开源，源代码、本文档、全部截图都在公开仓库里。

• Demo Park 仓库：https://gitcode.com/OPCTeam/demo_park
• 本案例目录：https://gitcode.com/OPCTeam/demo_park/tree/main/codearts-traffic-signal-lab

git clone https://gitcode.com/OPCTeam/demo_park.git

进入 codearts-traffic-signal-lab 文件夹，把 index.html 用浏览器打开即可运行，不需要安装任何依赖。

八、使用码道体会

这个页面由码道 Web 一次对话生成，单文件约 84 KB。

它自己跑了 12 条自检，还把对比表、柱状图和 SVG 路口都做出来了，布局基本不用我重排。

生成过程中它检查了自己的截图，发现路口画得太小、上下留白太多，又调了一版。

这部分确实省时间。

但语义错误它没有发现。感应控制丢绿灯这个 bug，页面看起来完全正常，600 辆/小时的数据也很像样。

只有把需求推到 900，数字才露馅。

所以我对它的第一版数据保持怀疑。界面可以信，控制逻辑要自己验。

场景定义也是我改的。它默认把 900 当高峰，可那个需求已经超过路口能力。

工具能写出能跑的代码，判断“这个场景是否成立”，还是得靠人。

九、总结

固定周期不落后，自适应也不是免费的。

在这个路口，600 辆/小时时感应控制和 LQF 比固定 60 秒少等约 28%。

过了通行能力，固定 90 秒反而最稳，朴素的 LQF 因为切换太频而崩盘。

如果你要做真实路口的配时，这篇只能算一个可控的沙盘。

它没有行人相位，没有保护左转，没有相邻路口协调，右转永远放行，到达也严格按泊松分布。

真实路口还要喂转向流量、行人过街需求和上下游协调，才谈得上落地。

下一步我想加绿波协调，把三个路口串起来，看车队能不能一路绿灯通过。