phpEnv不提供SQLite配置功能，其支持完全取决于当前PHP版本是否编译并启用了sqlite3和pdo_sqlite扩展；需手动验证扩展加载状态、修改对应php.ini启用扩展、确保文件路径绝对且权限正确，并优先使用PDO方式连接以获得更好错误提示与兼容性。
phpEnv 本身不提供 SQLite 配置功能——它只是个 PHP 版本管理工具，SQLite 支持完全取决于你当前激活的 PHP 版本是否已编译并启用了 sqlite3 和 pdo_sqlite 扩展。 很多人卡在“phpEnv 配了却连不上 SQLite”，其实问题从来不在 phpEnv，而在 PHP 扩展加载状态和文件权限。
确认当前 PHP 版本是否真支持 SQLite
phpEnv 只切换 php 命令指向的二进制，但不自动启用扩展。必须手动验证：
- 运行
php -m | grep -E '^(sqlite3|pdo_sqlite)$'，看到两行输出才算完整支持 - 如果只看到
sqlite3没有pdo_sqlite，PDO 方式会报could not find driver - 若无任何输出，说明该 PHP 版本编译时没带 SQLite 支持（常见于某些精简版或自定义编译包）
- 用
php --ini找到正在使用的php.ini，检查是否存在且未被注释的这两行：extension=sqlite3和extension=pdo_sqlite
phpEnv 下启用 SQLite 扩展的实操步骤
Linux/macOS 用户（Windows 同理，但路径和文件名不同）：
- 先用
phpenv versions确认当前激活版本，比如是8.2.15 - 找到对应配置目录：通常为
~/.phpenv/versions/8.2.15/etc/php.ini - 编辑该文件，取消注释（删掉前面的分号）：
extension=sqlite3和extension=pdo_sqlite - 保存后执行
phpenv rehash（非必需，但可刷新命令缓存） - 重启你的 Web 服务（如 Apache/Nginx）或 PHP-FPM 进程；CLI 下直接生效
连接 SQLite 时最常踩的三个坑
即使扩展开了，new SQLite3() 或 new PDO('sqlite:/path/to/db.db') 仍可能失败：
-
路径不可写：Web 服务器用户（如
www-data或_www）必须对数据库文件及其父目录有写权限；用__DIR__ . '/data/app.db'时，确保data/目录存在且可写 -
相对路径陷阱：CLI 下工作目录是执行命令的位置，Web 下是脚本所在目录，二者不一致会导致
unable to open database file；一律用绝对路径或__DIR__构造 -
WAL 模式未适配：开启 WAL（
$db->exec('PRAGMA journal_mode = WAL;')）能提升并发，但需确保 SQLite 版本 ≥ 3.7.0，且文件系统支持（如 NFS 不行）
SQLite3 类 vs PDO：选哪个？
两者都可用，但行为差异明显，影响调试和迁移：
立即学习“PHP免费学习笔记（深入）”；
-
SQLite3类更轻、无依赖，exec()失败只返回false，得手动调$db->lastErrorMsg()查错；query()返回SQLite3Result，必须用fetchArray()取数据 -
PDO报错更友好（设PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION后直接抛异常），预处理语法统一，适合将来换 MySQL/PostgreSQL；但 DSN 中路径若含空格或特殊字符，需urlencode() - 不建议混用：一个项目里同时用
SQLite3和PDO操作同一 DB 文件，可能因锁机制不同引发database is locked
真正麻烦的不是配置，而是权限判断和路径上下文——很多错误信息（比如 unable to open database file）根本没说清到底是路径错、权限错，还是扩展压根没加载。动手前先跑一遍 php -r "var_dump(extension_loaded('sqlite3'));"，比反复改配置快得多。
