绝对没有
虽然标题中的问题是模棱两可的， 可以 解释为“动态mysql查询的 每个部分 格式 是否正确……”，因此有肯定的答案，但正文中的问题
不是 ：
如果我运行了通过mysql真正的转义从用户那里收到的所有数据，那么它与使用mysql预准备语句一样安全吗？
如果您更仔细地看这个问题，您将理解，这只是 魔术引述的 化身！此不受欢迎，不推荐使用和已删除的功能的确切目的是“通过转义运行所有用户输入”。
如今，每个人都知道魔术引号是不好的。 那为什么要肯定的答案呢？
好的，似乎需要再次解释，为什么批量转义不好。
问题的根源是一个非常强烈的妄想，几乎每个PHP用户
都对它抱有幻想：每个人都有一个奇怪的信念，即逃避对“危险字符”（它们是什么？）进行某些操作，使它们“安全”（如何？）。不用说，这只是一个完整的垃圾。
事实是：
- 逃逸不会“消毒”任何东西。
- 逃逸与注射无关。
- 转义与用户输入无关。
转义只是一种 字符串格式 而已。
当需要时-尽管有注射的可能，但仍需要它。
当您不需要它时，即使有一点注射也无济于事。
说到与准备好的语句的区别，至少存在一个问题（在
sql-injection标记下已经多次提及）：这样
的代码
$clean = mysql_real_escape_string($_POST['some_dangerous_variable']);$query = "SELECt * FROM sometable WHERe somevalue = $clean";
将帮助您避免注射。
Beause转义只是字符串格式化工具，无论如何都不是防止注入的工具。
去搞清楚。
但是，转义与准备好的语句有一些共同点：
如果发生以下情况，它们都不能保证您不会被注入
- 您仅在臭名昭著的“用户输入”上使用它，而不管构建ANY查询的严格规则，尽管有数据源。
- 如果您需要插入的不是数据，而是标识符或关键字。
为了安全起见，请参阅我的答案，以解释FULL
sql注入保护的操作方法
长话短说：只有在您对初始陈述进行2次必要的更正和1次补充之后，您才能认为自己是安全的：
如果我运行
了通过mysql真正的转义从用户那里收到的所有数据，并且始终将其括在引号中
（并且，如ircmaxell所提到的，mysqli_set_charset()它用于使mysqli_real_escape
string（）实际上起作用了（在这种罕见的情况下，使用一些奇怪的编码，例如GBK））是否与使用mysql准备好的语句一样安全？
遵循这些规则-是的，它与本地准备好的语句一样安全。
