能，但需确认PHP版本及sqlite3扩展已启用；实际环境多为8.3或8.4 dev版，须用php -m验证，否则报Class 'SQLite3' not found。
PHP 8.5 能直接用 SQLite3 吗？
能，但得确认你装的是带 sqlite3 扩展的 PHP 版本——PHP 8.5 尚未发布（截至 2024 年中，最新稳定版是 8.3），所以实际运行环境大概率是 8.3 或自己编译的 8.4 dev 版。只要 php -m | grep sqlite3 有输出，就说明扩展已启用；没输出就别往下试了，会报 Class 'SQLite3' not found。
常见错误现象：Fatal error: Uncaught Error: Class "SQLite3" not found
- Linux（如 Ubuntu）：装
php-sqlite3包，不是php-sqlite（那是旧的 sqlite 扩展） - macOS（Homebrew）：重装 PHP 时加
--with-sqlite3，或确认ext-sqlite3在php.ini中已取消注释 - Windows：检查
php.ini是否启用了extension=sqlite3，且php_sqlite3.dll在ext/目录下
怎么安全地打开并查询 SQLite3 数据库？
别用 new SQLite3('db.sqlite') 硬写路径，尤其当数据库文件可能不存在时——它会静默创建空库，后续查不到数据还怪逻辑错。真正该做的是先检查文件是否存在、是否可写，并显式处理异常。
使用场景：Web 请求中读取配置表、CLI 工具批量处理本地数据
立即学习“PHP免费学习笔记（深入）”；
- 用
file_exists()+is_writable()预判，比靠 try/catch 更早发现问题 -
SQLite3::open()不抛异常，失败返回false；推荐用new SQLite3($path)并捕获Exception - 查询必须用
prepare()+bindValue()防注入，哪怕只是查固定 ID——因为用户输入可能来自 URL 参数或 POST
示例：
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
$db = new SQLite3('/var/data/app.db');
if (!$db) {
throw new RuntimeException('无法打开数据库');
}
$stmt = $db->prepare('SELECT name FROM users WHERE id = :id');
$stmt->bindValue(':id', $_GET['id'] ?? 0, SQLITE3_INTEGER);
$result = $stmt->execute();
插入数据后怎么拿到自增 ID？
别用 lastInsertRowID 以外的方式——比如 SELECT MAX(id)，在并发写入时大概率出错。SQLite3 的 lastInsertRowID() 是线程安全的，只返回当前连接最后一次 INSERT 生效的 rowid。
参数差异：lastInsertRowID() 返回整数，不是字符串；如果上一条语句不是 INSERT（比如 UPDATE 或 SELECT），它返回 0，不会报错也不会抛异常
- 必须在同一次
SQLite3实例中调用，换一个对象就无效 - 不适用于 REPLACE 或 INSERT OR REPLACE 场景——它们可能触发 DELETE+INSERT，此时返回的是新插入行的 ID，不是原记录 ID
- 如果用事务，要在
commit()后再取，否则可能返回 0（取决于驱动实现，PHP 官方扩展里通常 commit 后才刷新）
为什么用完不 close() 有时会锁表？
SQLite3 在写操作时会对整个数据库文件加锁，而 PHP 的 SQLite3 对象析构时并不保证立即释放锁——尤其在 CLI 脚本里有长循环、或 Web 请求中对象生命周期被框架延长时，close() 没被调用，锁就一直挂着。
性能影响：多个请求同时写同一个 db 文件，后到的会卡在 SQLITE_BUSY 错误，而不是等几秒自动重试
- 显式调用
$db->close()是最稳妥的做法，别依赖 GC - Web 场景下，建议把 DB 实例放在 request 生命周期末尾 close，比如在 PSR-15 中间件的
process()结束前 - 注意：调用
close()后再访问$db任何方法会触发致命错误Trying to access property on null，因为内部资源已被释放
容易被忽略的地方：SQLite3 的锁机制是文件级的，不是表级；哪怕你只更新一张小表，整个 .sqlite 文件都不可写。这点和 MySQL 完全不同，也决定了它不适合高并发写场景。
