用框架连数据库不一定更简单，但更安全、可维护；框架自动处理SQL注入防护、连接复用、事务管理等易错环节，而原生PDO需手动实现prepare/bind/fetch/异常捕获/资源关闭。
用框架连数据库真比原生 mysqli 或 PDO 简单？
不一定更简单，但更安全、更可维护。框架不是帮你少写几行代码，而是帮你绕过手写 SQL 注入防护、连接复用、事务管理这些容易出错的环节。比如 Laravel 的 DB::table('users')->where('id', 1)->first() 看似简洁，背后是预处理语句 + 连接池 + 查询日志 + 自动异常转换。而原生 PDO 写同样逻辑，至少要手动 prepare、bind、fetch、try/catch、finally 关闭句柄。
Laravel/Eloquent 和 ThinkPHP/Query 的连接配置差异在哪？
核心都是读取配置文件填进底层 PDO 实例，但默认行为不同：
- Laravel 默认开启
PDO::ATTR_EMULATE_PREPARES = false，强制走 MySQL 原生预处理，防注入更彻底；ThinkPHP 5.1+ 默认为true，兼容旧版 MySQL，但某些边界 case 可能绕过类型检查 - Laravel 的
.env里写DB_HOST=127.0.0.1就行，ThinkPHP 要在database.php里显式写'hostname' => '127.0.0.1'，键名不统一，迁移时容易漏改 - 两者都支持读写分离，但 Laravel 要配
read/write数组，ThinkPHP 用'master_num' => 1这类魔数，调试时查文档成本更高
不用框架时，PDO 连接必须自己管哪些事？
不是调通 new PDO(...) 就完事了，漏掉任何一项都可能在线上崩：
- 必须设
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则query()失败静默返回false，后续fetch()直接报致命错误 - 连接后立刻执行
set names utf8mb4（不能只写utf8），否则 emoji 和四字节字符存成乱码，且这个语句得用exec()，不能塞进 DSN - 长连接要用
PDO::ATTR_PERSISTENT => true，但 PHP-FPM 下要配合pm.max_children调整，否则连接数爆表被 MySQL 拒绝
ORM 查询生成的 SQL 为什么有时比手写还慢？
框架抽象层会悄悄加东西，比如：
立即学习“PHP免费学习笔记（深入）”；
- Eloquent 的
with('posts')默认生成两条查询（N+1 问题），不是自动变成 JOIN；要改成withCount('posts')或显式join()才行 - ThinkPHP 的
where('status', 'in', [1,2,3])在数据量大时可能触发全表扫描，因为框架没帮你加索引提示，而你手写 SQL 可以直接写FORCE INDEX (idx_status) - 所有框架对
LIKE '%abc%'都不做特殊优化，但原生 PDO 里你可以根据业务判断是否提前建全文索引或改用 Elasticsearch
真正省心的地方不在“连上”，而在“连上之后不出错”。别为了少敲几个字跳过连接超时设置、字符集校验、事务回滚兜底——这些细节框架帮你扛了，自己写就得一行行补。
