我在评论中张贴的对该问题的链接很好地说明了这个问题。下面总结了我对问题仍然存在的原因的看法：

1. 刚开始的人可能对SQL注入一无所知。

2. 有些人知道SQL注入，但是认为转义是（唯一的）解决方案。如果您对Google进行快速搜索php mysql query，则显示的第一页是该mysql_query页面，在该页面上有一个示例，该示例显示了将转义的用户输入插入到查询中。没有提到（至少我看不到）使用准备好的语句。就像其他人所说的那样，有太多使用参数插值的教程，这并不奇怪，仍然经常使用它。

3. 缺乏对参数化语句如何工作的理解。有人认为这只是逃避价值的一种幻想手段。

4. 其他人知道参数化的语句，但不要使用它们，因为他们听说它们太慢了。我怀疑许多人已经听到过如此缓慢的参数化陈述，但实际上并没有对他们自己进行任何测试。正如比尔·卡文（Bill Karwin）在演讲中指出的那样，在考虑使用准备好的陈述时，很少应将绩效差异作为一个因素。 一次准备，多次执行 的好处常常被人们忘记，安全性和代码可维护性方面的改善也常常被人们遗忘。

5. 有些在各处都使用参数化语句，但会插值未检查的值，例如表和列名称，关键字和条件运算符。动态搜索（例如，允许用户指定许多不同搜索字段，比较条件和排序顺序的搜索）就是其中的主要示例。

6. 使用ORM时有错误的安全感。ORM仍然允许对SQL语句部分进行插值-参见5。

7. 编程是一个大而复杂的主题，数据库管理是一个大而复杂的主题，安全性是一个大而复杂的主题。开发安全的数据库应用程序并非易事-即使是经验丰富的开发人员也可能会遇到麻烦。

8. 关于stackoverflow的许多答案都无济于事。当人们编写使用动态SQL和参数插值的问题时，通常缺少建议使用参数化语句的答案。在某些情况下，我曾有人反对我使用准备好的语句的建议-通常是因为人们认为性能开销不可接受。我严重怀疑那些问大多数这些问题的人所处的位置，即准备参数化语句所花费的额外几毫秒时间将对其应用造成灾难性的影响。