来自http://php.net/manual/en/mysqli.quickstart.prepared-statements.php的正确MySQLi参数化查询语法：
$stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)");
$stmt->bind_param("i", $id);
但永远不要这样：
$stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (:id_value)");
$stmt->bind_param("i", "id_value", $id);
在我看来，命名参数替换是在API级别实现的合理功能。令我惊讶的是，MySQLi 在库中只实现了 未命名参数。
有正当理由吗？看到 PDO、DQL、ORM 都如何在查询中采用命名参数，这对我来说没有意义。
我希望 MySQLi 开发人员不会出现“我们很懒且不想”的情况。我相信一定有一个很好的理由，并且我正在寻找那个理由，或者寻找那个理由的方法。 MySQLi 扩展库中未实现命名参数的原因。
传统上，MySQLi 是 MySQL API。它本身不会添加任何内容，并且是有原因的：添加命名占位符等功能将需要（如果您想到的话）整个 SQL 查询解析的庞然大物。当然，这不是数据库 API 的工作。就像其他答案中所说的那样，API 不是 DAL 或 DBAL；它们有不同的用途。
PDO 是一项您在语言中很难再看到的伟大壮举，而韦斯·弗隆 (Wes Furlong) 是一位天才，他几乎单枪匹马地承担了这项任务。但 PDO 又是另一回事了。它是一个数据库访问抽象层，为了实现这个目标，无论你喜欢与否，你都需要一个查询解析器。由于您已经有了一个查询解析器，并且其中一个驱动程序已经支持命名占位符，因此很自然地将其添加到所有支持的驱动程序中。正如您所看到的，使用 MySQLi 一切都不同了。
简单来说，不是“懒”，而是“懒”。这是关于遵循规范。
MYSQLi不支持命名参数有两个主要原因：PDO确实如此 - 而且没有必要重新发明轮子详细说明第 1 点：
mysqli，尽管与PDO相比有许多缺点，但很容易与一个好的包装器相媲美 - 即命名参数（除其他外） ）由包装器而不是 mysqli 本身支持。这是设计使然，只有一个原因：Mysqli被设计为一个快速且灵活的库。如果开发人员将更多功能合并到基础库中，与直觉相反，它就会变得不太灵活，并且需要更长的加载/执行时间。
mysqli和pdo都是随 PHP 5 发布的（我相信 PDO 版本为 5.3），因此有不同的用途。您想要更快的执行时间吗？使用没有包装器的
mysqli。您想要命名参数吗？使用PDO或构建mysqli包装器来处理此类问题 - 但请注意，这会阻碍您的执行时间。