经OPcache处理的混淆PHP代码为何运行仍慢于原代码？

原代码和混淆代码生成的opcode确实存在差异，这是OPcache缓存后性能仍有差距的核心原因，具体可以从以下几点分析：

• 混淆代码生成的opcode指令更冗余
  常见的混淆手段（如超长乱码变量名、嵌套编码字符串、无用代码插入）会让Zend引擎生成更多的opcode指令。比如原代码的直接变量赋值$a = 1;，混淆后可能变成$x2dFgHjKl = (int)base64_decode('MQ==');，对应的opcode会包含base64_decode调用、类型转换指令，比原代码多两步执行逻辑，即使缓存了opcode，Zend VM执行这些冗余指令也会消耗更多CPU周期。

• 混淆代码会绕过OPcache的优化逻辑
  OPcache内置了常量折叠、死代码消除等优化，但混淆代码常故意破坏这些优化条件：比如把静态常量改成动态生成的字符串、用eval包裹代码片段、插入无意义的分支判断。例如原代码define('MAX', 100); $b = MAX;会被OPcache优化为直接赋值$b = 100;，但混淆后写成$max = base64_decode('TUFY'); define($max, 100); $b = constant($max);时，OPcache无法识别动态常量，只能保留constant调用的opcode，执行时必须额外查找常量表，增加了运行开销。

• 变量访问的哈希查找开销更高
  混淆后的变量名通常更长且无规律，Zend VM的符号表在查找这些变量时，哈希计算和匹配的开销会远高于短命名的原变量。即使opcode被缓存，每次访问变量时的哈希查找步骤无法跳过，累积起来会导致明显的性能差异。

内容的提问来源于stack exchange，提问作者Sergey Bakotin