 + PDOStatement::execute() 执行。)
这句话在绝大多数情况下是正确的：Laravel 中所有通过 Query Builder 或 Eloquent 发起的数据库查询，最终都会经由PDO::prepare()+PDOStatement::execute()执行。这是 Laravel 实现SQL 注入防护和跨数据库兼容性的核心技术机制。
但为了严谨，我们需明确其适用范围、例外情况、底层细节，做到“知其然，更知其所以然”。
✅ 一、正常路径：几乎所有查询都走预处理
1.Eloquent 查询
User::where('email','john@example.com')->first();- 编译为 SQL：
SELECT * FROM users WHERE email = ? - 绑定参数：
['john@example.com'] - 执行路径：
$pdo=$connection->getPdo();$stmt=$pdo->prepare("SELECT * FROM users WHERE email = ?");$stmt->bindValue(1,'john@example.com',PDO::PARAM_STR);$stmt->execute();// ← 最终调用
2.Query Builder
DB::table('users')->insert(['name'=>'John']);- 同样生成带占位符的 SQL，通过
PDOStatement::execute()执行。
3.原生查询（带绑定）
DB::select('SELECT * FROM users WHERE id = ?',[1]);- 显式使用绑定，必然走预处理。
🔒安全基石：因为参数通过
bindValue()或execute($bindings)传递，与 SQL 模板分离，数据库在解析阶段就区分“代码”与“数据”，彻底阻断 SQL 注入。
⚠️ 二、例外情况：绕过预处理的“危险操作”
虽然 Laravel默认且推荐使用预处理，但开发者主动选择时，可绕过它：
1.DB::statement()执行无绑定的原生 SQL
DB::statement("DELETE FROM users WHERE created_at < '2020-01-01'");- 若 SQL 中不含参数绑定，Laravel 会直接调用
PDO::exec()（非prepare+execute）。 - 但若传入用户输入且未绑定，极易导致注入！
2.DB::raw()+ 字符串拼接（反模式）
// ❌ 危险！绕过绑定，直接拼接$where="email = '".$userInput."'";User::whereRaw("{$where}")->get();- 此时 SQL 完全由字符串构成，Laravel 无法干预，直接传给
prepare()但无参数绑定。 - 虽仍调用
prepare()，但因无占位符，等效于不安全执行。
✅ 正确用法：
User::whereRaw('email = ?',[$userInput])->get();// 安全，走预处理
3.Schema 操作（Migration）
Schema::create('users',function(Blueprint$table){...});- DDL 语句（CREATE, ALTER）通常不支持参数绑定，故直接通过
PDO::exec()执行。 - 但因 DDL 一般不包含用户输入，风险较低。
🔬 三、底层验证：Laravel 源码如何执行？
在Illuminate\Database\Connection中：
// 执行带绑定的查询（SELECT, INSERT, UPDATE...）protectedfunctionrunQueryCallback($query,$bindings,Closure$callback){try{$result=$callback($query,$bindings);}catch(PDOException$e){// 包装为 QueryExceptionthrownewQueryException($query,$bindings,$e);}return$result;}// 示例：select 方法内部publicfunctionselect($query,$bindings=[],$useReadPdo=true){return$this->run($query,$bindings,function($query,$bindings)use($useReadPdo){$pdo=$this->getPdoForSelect($useReadPdo);$statement=$pdo->prepare($query);// ← prepare$this->bindValues($statement,$bindings);// ← bind$statement->execute();// ← executereturn$statement->fetchAll(/* ... */);});}✅ 可见：只要查询有
$bindings，就必然走prepare+bind+execute。
📌 四、重要补充：模拟预处理（Emulated Prepares）
PDO 有两种预处理模式：
| 模式 | 行为 | Laravel 默认 |
|---|---|---|
Native Prepares(ATTR_EMULATE_PREPARES = false) | SQL 与参数分别发送到数据库服务器，由 DB 引擎处理 | ✅默认启用 |
Emulated Prepares(= true) | PDO 在 PHP 层拼接 SQL，再发送完整语句 | ❌ 禁用 |
Laravel 在连接器中显式关闭模拟预处理（config/database.php中默认设置）：
'options'=>extension_loaded('pdo_mysql')?array_filter([PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT=>false,PDO::ATTR_EMULATE_PREPARES=>false,// ← 关键！]):[],✅ 这确保了真·预处理，即使在极端情况下（如二进制数据、特殊字符）也能安全执行。
✅ 结论
| 说法 | 是否成立 | 说明 |
|---|---|---|
“Laravel 所有查询都通过prepare()+execute()执行” | 基本成立 | 只要使用了参数绑定（Laravel 默认行为），就一定走此路径 |
| “包括 Eloquent” | ✅ 成立 | Eloquent 最终调用 Query Builder → Connection → PDO |
| “100% 无例外” | ❌ 不严谨 | DB::statement("raw sql")、DDL、错误使用DB::raw()可能绕过绑定，但仍可能调用prepare()（只是无参数） |
🔑核心要义：
Laravel 的安全默认行为是——所有含动态值的查询，都通过带参数绑定的预处理语句执行。
开发者只要不手动拼接 SQL，即可天然免疫 SQL 注入。
