别用 sqlite_open()，它在 PHP 7.0+ 已被移除；应使用 PDO + pdo_sqlite 扩展，确保扩展启用、路径正确、权限充足，并配置 PDO::ATTR_ERRMODE 为 EXCEPTION 以获取详细错误信息。
PHP 用 sqlite_open() 还是 PDO？选错就踩坑
直接结论：别用 sqlite_open()，它在 PHP 7.0+ 已被移除，连函数都不存在了。现在唯一可靠、跨版本的方式是用 PDO + pdo_sqlite 扩展。
常见错误现象：Fatal error: Uncaught Error: Call to undefined function sqlite_open() —— 这不是你代码写错了，是 PHP 版本升级后直接砍掉了旧 API。
-
PDO是官方推荐路径，支持预处理、事务、异常捕获，SQLite3 也原生兼容 - 确认扩展已启用：
extension=php_pdo_sqlite.dll（Windows）或extension=pdo_sqlite.so（Linux/macOS），可通过php -m | grep sqlite验证 - 如果只装了
sqlite3扩展但没开pdo_sqlite，new PDO('sqlite:db.db')会报could not find driver
连接 SQLite 文件时路径写错，数据库“凭空消失”
SQLite 不是服务端进程，它靠文件路径定位数据库。路径一错，PDO 就自动新建一个空文件——你以为连上了，其实操作的是全新空白库。
典型表现：插入数据后查不到、表结构始终为空、sqlite_master 里啥也没有。
立即学习“PHP免费学习笔记（深入）”；
- 绝对路径最稳：
new PDO('sqlite:/var/www/myapp/data/app.db')，避免相对路径受cwd影响 - 用
__DIR__拼接更安全：'sqlite:' . __DIR__ . '/data/app.db' - 注意权限：Web 服务器用户（如
www-data或_www）必须对文件和所在目录有读写权限，否则报unable to open database file
执行 SQL 报 SQLSTATE[HY000]: General error 怎么查
这个错误太笼统，实际原因几乎全是语法或运行时问题，PDO 默认不暴露具体 SQLite 错误码，得手动开调试。
关键动作：关掉模拟预处理、开启错误抛出，并用 getAttribute() 拿底层 SQLite 错误信息。
- 创建 PDO 时加选项：
new PDO($dsn, null, null, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_EMULATE_PREPARES => false]) - 捕获异常后打印详细信息：
$e->getMessage() . ' (SQLITE code: ' . $pdo->getAttribute(PDO::ATTR_DRIVER_NAME) . ')' → 实际要用 <code>$pdo->errorCode()和$pdo->errorInfo() - 常见诱因：字段名含空格/短横线没加反引号、
INSERT INTO table VALUES (?)却传了 2 个参数、用datetime('now')但 SQLite 版本太老（
用完不关闭连接？其实影响不大，但事务要手动 commit
SQLite 是嵌入式数据库，PDO 连接对象销毁时会自动释放资源，显式调用 $pdo = null 或 unset($pdo) 并非必须。真正容易漏的是事务控制。
现象：执行 BEGIN 后插入几条数据，脚本结束也没报错，但数据就是不落盘。
- SQLite 默认自动提交（autocommit），一旦执行 DML（
INSERT/UPDATE）就立即写入；只有显式BEGIN后才进入手动事务模式 - 务必配对使用：
$pdo->beginTransaction()→ 操作 →$pdo->commit()；失败时用$pdo->rollback() - 若忘了
commit，连接断开时 SQLite 会回滚未完成事务——不是丢数据，是压根没存进去
复杂点在于：SQLite 的 WAL 模式、busy timeout 设置、以及多进程并发写同一文件时的锁行为，这些不常碰，但真遇到 database is locked 就得回头调 PDO::ATTR_TIMEOUT 和检查是否用了 PRAGMA journal_mode = WAL。
