~~兰博的不公平选边持续了14年！！！
根据近期全球服务器白金及以上段位的综合数据，兰博在蓝色方的胜率为49.4%，而红色方胜率为44%，导致胜率差距达到5.4%，这使得兰博成为红蓝方胜率差异最大的英雄。
经过测试，兰博Q/R技能的总伤害、伤害段数和单次伤害目前在红蓝双方都是相同的。然而，红色方兰博Q/R技能开始和结束造成伤害的时间被向后推迟了，这使得红色方释放的Q/R比蓝色方晚了大约0.2秒（如下图所示）。
这种情况只发生在红色方兰博对蓝色方英雄使用Q/R技能时（对小兵或训练假人使用时则正常）。这个问题已经存在了超过10年，尽管在2014年的4.9版本中曾宣布修复。
在实际游戏中，由于敌方走位和其他原因，Q/R技能很难打满伤害。在这种情况下，蓝色方通常比红色方多造成一到两段伤害，并更早地触发装备效果（如兰德里的苦楚）和符文（如征服者）。
可通过游戏内简易测试复现该bug，发现其他条件不变时，蓝方兰博对红方英雄至少造成3段伤害，而红方兰博对蓝方英雄仅造成2段伤害。关于R技能，其debuff会显示在状态栏，测试更简单。最简易方法是让乐芙兰用W（魔影迷踪）穿过兰博大招。 蓝方兰博会对红方乐芙兰造成2段伤害，而红方兰博对蓝方乐芙兰仅造成1段伤害。
原理：
伤害和状态计算按固定顺序处理，很可能基于单位ID优先级： 蓝方英雄 > 红方英雄 > 假人/小兵
bug触发条件：
当低优先级单位（红方兰博）伤害高优先级单位（蓝方英雄）时触发bug
当高优先级单位（蓝方兰博）伤害低优先级单位（红方英雄/假人）时不触发
因此红方兰博对目标假人的行为与对蓝方兰博对红方英雄相同，使我们能同时观察两种场景且时间完全同步。
Q技能发现：
兰博Q每秒造成4次伤害（每0.25秒1次），红方兰博Q对蓝方英雄有约0.25秒伤害延迟，若Q被提前打断，红方兰博会少1段伤害（如2:1、3:2等） 这意味着每次线上Q换血都可能丢失伤害，严重影响红方兰博表现
R技能发现：
红方兰博R对蓝方英雄有0.25秒伤害延迟，伤害不同步——红方兰博的伤害会在目标间交替生效
原作者对bug起源的推测：
兰博Q/R被归类为DOT-AOE伤害，在引擎层（AOE）和脚本层（DOT）表现不一致，这导致了兰博代码在引擎层与脚本层存在隐形耦合。
原作者怀疑：
原始bug（红蓝方伤害不均）被"修复"的方式是给红方兰博添加延迟，虽"平衡"了总伤害却制造了更隐蔽的新bug，即设计师将一个小bug修成了一个更隐蔽的大bug，该bug影响2011年4月26日兰博上线以来的数亿局游戏，包括约3000场职业比赛
~~有意思，可能发现什么了。我会去看看。
~~哇，你是官方人员吗？
~~他们名字旁边的拳头图标是只会发给真正的拳头员工的，所以他肯定是！
~~是的，GalaxySmash是拳头主要的……呃，是其中一个主要负责bug的人。这对兰博玩家来说真是个好日子。
~~哈哈，只是Reddit上最爱发言的那个。在这待得够久了，所以也见过不少东西了，而且自己也能搞定一些简单的问题了。
~~感谢你维护我最喜欢的游戏
~~乐意效劳，这也是我还有所有英雄联盟玩家共同的游戏嘛
~~如果我没理解错的话，早在4.9版本，兰博在紫色方（蓝色方）时Q技能的伤害偏低，所以他们搞了个修复方案，内容是：“如果兰博在红色方，就给Q技能的伤害增加0.25秒的延迟。”
但是——他们从没考虑过“如果有人在兰博的Q或R技能范围内反复进出”会怎么样，结果现在每一段伤害的刷新都有了0.25秒的延迟。
这不是什么像意大利面条的代码，这就是写死的代码。
~~我去，这最初的“修复”方案也太没道理了，笑死。
~~当你意识到拳头的代码一直都是意大利面条时，这个最初的修复方案就完全说得通了。在S4那个年代，他们还在不停地往这坨面条上加料，当时的游戏代码根本就没人想过去控制一下。
~~意面平行宇宙
~~那时候他们确实搞了很多这种用蛮力做的蠢修复。
~~纠正一下，紫色方当时就是红色方（以前是蓝色方对阵紫色方，后来改成了蓝色方对阵红色方）。
~~我花了大约四年时间追踪兰博在不同阵营的胜率，研究了所有能想到的，也和拳头员工聊过。尽管我和u/caenen_、u/vandirilol测试了所有能想到的可能性，但我们就是找不到这个bug到底是什么，甚至不确定是否存在。所以今天早上看到这个消息真是太酷了。
重要的是：这是Reddit上那个视频作者的帖子，里面有更详细的信息。
此外，还得补充一点，兰博在蓝色方还有一个额外的优势——施放大招更容易。由于HUD界面的位置，在红色方施放远距离大招时，为了瞄准而向后移动，更容易导致角色脱离视野，而蓝色方则没有这个问题。这一点一直都知道，也被认为是兰博胜率差异的部分原因。但有一点一直暗示着可能还有其他问题，那就是兰博在极限闪击模式（一张横向地图）中也存在同样的蓝红方胜率差距。
这就是为什么每当有人问起这个问题时，我们唯一能给出的答案就是：“嗯，有证据表明存在一个bug，但没人能找到。”
很高兴这个问题终于水落石出了。也很高兴我们终于能找到一个解决方案，来应对“如何从平衡性角度处理一个在同一时间，一边胜率41%，另一边胜率59%的英雄”这个难题。
