在我用php开发的所有年份中，我一直都听说使用eval()邪恶。
考虑以下代码，使用第二个（更优雅的）选项是否有意义？如果没有，为什么？
// $type is the result of an SQL statement
// e.g. SHOW COLUMNS FROM a_table LIKE 'a_column';
// hence you can be pretty sure about the consistency
// of your string
$type = "enum('a','b','c')";
// possibility one
$type_1 = preg_replace('#^enum\s*\(\s*\'|\'\s*\)\s*$#', '', $type);
$result = preg_split('#\'\s*,\s*\'#', $type_1);
// possibility two
eval('$result = '.preg_replace('#^enum#','array', $type).';');
Answers:
在将eval（）称为纯邪恶时，我会保持谨慎。动态评估是一个强大的工具，有时可以节省生命。使用eval（）可以解决PHP的缺点（请参见下文）。
eval（）的主要问题是：
实际使用eval（）的主要问题只有一个：
根据经验，我倾向于遵循以下规则：
当用户输入包含在评估字符串中的可能性很小时，eval是邪恶的。当您进行评估而没有来自用户的内容时，您应该是安全的。
不过，在使用eval之前，您至少应该三思而后行，它看起来看似简单，但是考虑到错误处理（请参见VBAssassins注释），可调试性等方面，它不再那么简单了。
因此，根据经验：算了吧。当eval是答案时，您很可能会问错问题！;-)
eval()不可能，这是一种更好的方法。许多人说eval()在某些情况下是不可避免的，但是他们没有提到我们可以争论的任何具体例子，这样的辩论就没有意义了。因此，请说eval()不可避免的人首先证明这一点！
eval（）始终都是邪恶的。
“什么时候eval（）不邪恶？” 我认为这是一个错误的问题，因为这似乎暗示在某些情况下使用eval（）的弊端会神奇地消失。
使用eval（）通常是个坏主意，因为它会降低代码的可读性，使您在运行时之前预测代码路径的能力（以及可能的安全隐患），从而降低调试代码的能力。使用eval（）还可以防止操作码缓存（例如集成到PHP 5.5及更高版本中的Zend Opcache）或JIT编译器（例如HHVM中的编译器）对评估的代码及其周围的代码进行优化。
而且，没有绝对必要使用eval（）的情况-PHP是没有它的全功能编程语言。
是否实际将其视为邪恶，还是在某些情况下可以使用eval（）亲自证明情况由您决定。对某些人来说，弊端太大，无法证明其合理性；对另一些人来说，eval（）是方便的快捷方式。
但是，如果您将eval（）视为邪恶，那么它始终都是邪恶的。它不会根据上下文神奇地失去其邪恶性。
在这种情况下，eval可能足够安全，只要用户永远不可能在表中创建任意列。
不过，它实际上并没有更优雅。这基本上是一个文本解析问题，并且滥用PHP的解析器来处理似乎有点棘手。如果要滥用语言功能，为什么不滥用JSON解析器？至少对于JSON解析器，根本没有代码注入的可能性。
$json = str_replace(array(
'enum', '(', ')', "'"), array)
'', '[', ']', "'"), $type);
$result = json_decode($json);
正则表达式可能是最明显的方法。您可以使用单个正则表达式从此字符串中提取所有值：
$extract_regex = '/
(?<=,|enum\() # Match strings that follow either a comma, or the string "enum("...
\' # ...then the opening quote mark...
(.*?) # ...and capture anything...
\' # ...up to the closing quote mark...
/x';
preg_match_all($extract_regex, $type, $matches);
$result = $matches[1];
eval() 速度很慢，但我不会称之为邪恶。
我们对它的不好使用会导致代码注入并变得邪恶。
一个简单的例子：
$_GET = 'echo 5 + 5 * 2;';
eval($_GET); // 15
一个有害的例子：
$_GET = 'system("reboot");';
eval($_GET); // oops
我建议您不要使用，eval()但如果您使用，请确保将所有输入验证/列入白名单。
我会在这里公然窃取内容：
评估本质上永远都是安全问题。
除了安全方面的问题，eval还存在难以置信的缓慢问题。在我对PHP 4.3.10的测试中，它的速度比普通代码慢10倍，而对PHP 5.1 beta1则慢28倍。
eval()永远是邪恶的。
eval()，我就以为我问错了这个问题。很少有“正确”的答案，但总括来说，永远都是邪恶是根本不正确的。
我还要考虑一些维护您代码的人。
eval（）并非只是查看并知道应该发生什么的简单方法，您的示例并没有那么糟糕，但是在其他地方，这可能是一场噩梦。
就我个人而言，我认为代码仍然很邪恶，因为您没有评论它在做什么。它还没有测试其输入的有效性，因此非常脆弱。
我还感到，由于95％（或更多）的eval使用具有积极危险性，因此在其他情况下可能节省的少量潜在时间不值得沉迷于使用eval的不良做法。另外，您稍后将不得不向您的奴才解释为什么使用eval是好事，而使用eval是坏事。
而且，当然，您的PHP最终看起来像Perl;）
eval（）有两个关键问题（作为“注入攻击”场景）：
1）可能会造成伤害2）可能会导致崩溃
还有一个比技术更社会化的：
3）会诱使人们不当使用它作为其他地方的捷径
在第一种情况下，您冒着任意代码执行的风险（显然，不是在评估已知字符串时）。但是，您的输入可能不如您想像的那样知名或固定。
在这种情况下，您更有可能崩溃，而您的字符串将以无用的模糊错误消息终止。恕我直言，所有代码都应尽可能整齐地失败，否则将引发异常（这是最易于处理的错误形式）。
我建议在此示例中，您是通过巧合进行编码，而不是根据行为进行编码。是的，SQL枚举语句（您确定该字段的枚举？-您是否调用了正确版本的数据库的正确表的正确字段？实际回答了吗？）碰巧像PHP中的数组声明语法，但我建议您真正要做的不是找到输入到输出的最短路径，而是解决指定的任务：
这大致就是您的选择所要做的，但是为了清楚和安全起见，我会在其中包裹一些if和注释（例如，如果第一个匹配项不匹配，则抛出异常或将结果设置为null）。
转义的逗号或引号仍然可能存在一些问题，您可能应该解压缩数据然后再将其取消引用，但是它至少确实将数据视为数据而不是代码。
使用preg_version时，最糟糕的结果可能是$ result = null，而使用eval版本，最糟糕的结果是未知的，但至少会导致崩溃。
糟糕的编程会使eval（）变成邪恶，而不是函数。我有时会用它，因为我无法在多个站点上进行动态编程。我无法在一个站点上解析PHP，因为我不会收到想要的东西。我只会收到结果！我很高兴eval（）函数存在，因为它使我的生活更加轻松。用户输入？只有糟糕的程序员才会被黑客吸引。我不用担心
糟糕的编程会使eval（）变成邪恶，而不是函数。我有时会用它，因为我无法在多个站点上进行动态编程。我无法在一个站点上解析PHP，因为我不会收到想要的东西。我只会收到结果！我很高兴eval（）函数存在，因为它使我的生活更加轻松。用户输入？只有糟糕的程序员才会被黑客吸引。我不用担心
我预计您很快就会遇到严重的问题...
老实说，在像PHP这样的解释语言中，过高的功能（例如eval）绝对没有什么用处。我从未见过eval执行无法使用其他更安全的方法执行的程序功能...
我衷心同意，对于所有认为测试用户输入会有所帮助的人们，评估是万恶之源。三思而后行，用户输入可能以多种不同形式出现，而正如我们所说，黑客正在利用您不太在意的功能。我认为，请完全避免评估。
我已经看到了精心制作的示例，这些示例滥用了超出我自己创造力的评估功能。从安全的角度出发，不惜一切代价避免，我甚至会要求它至少是PHP配置中的一个选项，而不是“给定的”。
eval。因此，对于任何功能X：X是所有评估的根...呃...邪恶，所以最好完全放弃编程（这样就从那些愚蠢的黑客手中夺走了地毯，最终仍然使它们变得聪明）。
这是在不使用eval的情况下运行从数据库提取的PHP代码的解决方案。允许所有范围内的函数和异常：
$rowId=1; //database row id
$code="echo 'hello'; echo '\nThis is a test\n'; echo date(\"Y-m-d\");"; //php code pulled from database
$func="func{$rowId}";
file_put_contents('/tmp/tempFunction.php',"<?php\nfunction $func() {\n global \$rowId;\n$code\n}\n".chr(63).">");
include '/tmp/tempFunction.php';
call_user_func($func);
unlink ('/tmp/tempFunction.php');
基本上，它使用文本文件中包含的代码创建一个唯一的函数，包括该文件，调用该函数，然后在完成处理后将其删除。我正在使用它来执行每日数据库提取/同步，其中每个步骤都需要唯一的代码来处理。这解决了我所面临的所有问题。
我过去经常使用eval（），但是我发现大多数情况下您不必使用eval来完成技巧。好吧，您在PHP中拥有call_user_func（）和call_user_func_array（）。静态地和动态地调用任何方法就足够了。
要执行静态调用，请将回调构造为array（'class_name'，'method_name'），甚至构造为简单的字符串，例如'class_name :: method_name'。要执行动态调用，请使用array（$ object，'method'）样式回调。
eval（）的唯一明智用途是编写自定义编译器。我做了一个，但是eval仍然是邪恶的，因为它是如此难以调试。最糟糕的是，无效代码中的致命错误使调用它的代码崩溃。我至少使用Parsekit PECL扩展来检查语法，但仍然不满意-尝试引用未知类和整个应用程序崩溃。
除了安全方面的考虑，eval（）不能被编译，优化或缓存操作码，因此，它总是比普通的php代码慢（慢得多）。因此，使用eval是无效的，尽管这不会使它变得邪恶。（goto是邪恶的，eval只是不好的作法/臭味的代码/丑陋的）
eval得到的邪恶等级低于goto？是对面的日子吗？
goto在5.3中实现的PHP开发人员怀恨在心。
goto-fobians：有（有或没有）使用工具的工匠。这是永远不会犯错误的时候，让一个专业的外观像一个白痴，工具，而是无法使用合适的工具（正常）。但这始终是指责的工具……
$result = array(); preg_replace_callback('#^enum\s*\(\s*\'|\'\s*\)\s*$#', function($m) use($result) { $result[] = $m[1]; }, $type);