四个进口各 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 辆/小时则超过了两种固定周期的能力，排队会一直涨。
所以红灯等多久，不只是红时长的问题。损失时间、绿信比、需求量三者怎么配，才是关键。
二、四种策略，跑同一批车
我实现了四种控制方式，参数全部摆在页面上。
| 策略 | 周期 | 绿灯规则 | 切换条件 |
|---|---|---|---|
| 固定 60 秒 | 60 秒 | 每方向 27 秒 | 固定轮转 |
| 固定 90 秒 | 90 秒 | 每方向 42 秒 | 固定轮转 |
| 感应控制 | 不固定 | 最短 12 秒，最长 45 秒 | 对向有排队，且本方向 3 秒无新车 |
| LQF | 不固定 | 最短 12 秒，最长 45 秒 | 每 12 秒比较一次，绿灯给队列更长的一对进口 |
四种策略共用同一批到达车辆，随机种子 20261110，仿真 60 分钟，时间步长 0.1 秒。
车辆跟驰按 2 秒车头时距放行，第一辆车额外等 2 秒启动。
转向比例、饱和流率、清空时间都相同。变量只有控制逻辑。
三、2400 辆车的四种结果
先看 600 辆/小时这一档。
| 策略 | 平均延误 | P95 延误 | 最长等待 | 最大排队 | 完成/到达 | 切换 | 损失时间 |
|---|---|---|---|---|---|---|---|
| 固定 60 秒 | 13.8 秒 | 33.8 秒 | 50.4 秒 | 11 辆 | 2356/2367 | 120 次 | 16.7% |
| 固定 90 秒 | 18.2 秒 | 48.1 秒 | 58.4 秒 | 13 辆 | 2352/2367 | 80 次 | 11.2% |
| 感应控制 | 10.0 秒 | 25.6 秒 | 42.9 秒 | 10 辆 | 2361/2367 | 185 次 | 25.8% |
| LQF | 9.8 秒 | 23.4 秒 | 37.8 秒 | 10 辆 | 2362/2367 | 228 次 | 31.8% |
固定 90 秒的损失时间最低，只有 11.2%，但平均延误最高。
原因是它给每个方向 42 秒绿，不管那个方向有没有那么多车。
在 74% 的负荷下，多出来的绿时没有被车用掉，反而让另一个方向多等。
LQF 的损失时间最高，31.8%，平均延误却最低。
它把绿时花在队列更长的一对进口上，切换次数多，但每次切过去都有车可放。
这组数据说明，损失时间不是唯一指标。绿时给谁，同样决定等待。
四、需求量一变，结论就翻
同一套策略，只改每个进口的需求量，平均延误如下。
| 每进口需求 | 固定 60 秒 | 固定 90 秒 | 感应控制 | LQF |
|---|---|---|---|---|
| 300 辆/小时 | 10.4 秒 | 13.8 秒 | 6.7 秒 | 6.6 秒 |
| 600 辆/小时 | 13.8 秒 | 18.2 秒 | 10.0 秒 | 9.8 秒 |
| 750 辆/小时 | 16.6 秒 | 19.9 秒 | 13.8 秒 | 14.5 秒 |
| 900 辆/小时 | 44.2 秒 | 27.1 秒 | 27.1 秒 | 77.6 秒 |
| 1000 辆/小时 | 151.9 秒 | 67.7 秒 | 88.1 秒 | 201.2 秒 |
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 版：devcloud.cn-north-4.huaweicloud.com/chat?source…
登录后直接在对话框里描述需求，不需要装软件。
这个页面是单文件 index.html，没有外部脚本、字体和图片，断网也能打开。
七、直接下载试玩
这个 Demo 已经完整开源，源代码、本文档、全部截图都在公开仓库里。
- Demo Park 仓库：gitcode.com/OPCTeam/dem…
- 本案例目录：gitcode.com/OPCTeam/dem…
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 因为切换太频而崩盘。
如果你要做真实路口的配时，这篇只能算一个可控的沙盘。
它没有行人相位，没有保护左转，没有相邻路口协调，右转永远放行，到达也严格按泊松分布。
真实路口还要喂转向流量、行人过街需求和上下游协调，才谈得上落地。
下一步我想加绿波协调，把三个路口串起来，看车队能不能一路绿灯通过。
