根本原因是SQLite驱动依赖PHP当前工作目录解析路径，而该目录在不同运行环境下不稳定；应使用database_path()等函数生成绝对路径，并确保目录存在且Web用户有写权限。
ThinkPHP6 使用 SQLite 时写相对路径报错，根本原因不是 TP6 本身限制，而是 SQLite 驱动对路径的解析完全依赖 PHP 运行时的 当前工作目录（Current Working Directory），而这个目录在不同启动方式下极不稳定——你写的 "database.db" 实际会被解释成 /var/www/html/database.db、/root/database.db 或 /tmp/database.db，具体取决于谁、在哪、怎么运行了你的脚本。
当前工作目录不可控是核心陷阱
ThinkPHP6 的 database.php 配置中若写：
'filename' => './runtime/database.sqlite'
这看似是“项目内相对路径”，但 PHP 的 sqlite: DSN 不会以 app_path() 或 root_path() 为基准，而是直接交给底层 SQLite 库处理。SQLite 库只认操作系统级别的当前目录（getcwd() 返回值）。常见失控场景：
- 用
php think command:run命令行执行：当前目录通常是项目根目录，可能成功； - 用 Nginx + PHP-FPM 访问 Web 接口：FPM worker 的当前目录默认是
/或/var/www，./runtime/就指向了错误位置； - 用 systemd 启动定时任务：当前目录常为
/root或/etc，./完全失效； - IDE 调试时点运行按钮：当前目录可能是 IDE 工程目录，也可能被重定向，结果不一致。
绝对路径才是唯一可靠解法
必须把相对路径转换为运行时可确定的绝对路径。TP6 提供了现成的辅助函数，推荐两种写法：
- 用
database_path()（最常用）：'filename' => database_path('app.sqlite')
该函数始终返回runtime_path('database/') . 'app.sqlite'对应的绝对路径，与环境无关； - 用
app_path()或root_path()自定义位置：'filename' => root_path() . 'data/myapp.db'
需确保data/目录存在且 Web 用户（如 www-data）有读写权限。
权限与目录存在性必须同步检查
即使路径写对了，SQLite 仍会因以下任一问题报 HY000 或 unable to open database file：
- 数据库文件所在父目录（如
runtime/database/）不存在 —— SQLite 不会自动创建多级目录； - Web 服务用户（如
www-data、nginx、apache）对该目录无写权限； - SELinux 或 AppArmor 等安全模块阻止了文件访问（常见于 CentOS/RHEL）；
- 文件系统挂载为只读（如某些 Docker 容器或云服务器临时盘）。
验证是否真连上了
别只看页面有没有报错。加一段调试代码确认实际路径和权限：
$path = database_path('app.sqlite');<br>echo "Resolved path: " . $path . "\n";<br>echo "Dir exists? " . (is_dir(dirname($path)) ? 'yes' : 'no') . "\n";<br>echo "Writable? " . (is_writable(dirname($path)) ? 'yes' : 'no') . "\n";
在命令行和浏览器中分别执行，对比输出差异，能快速定位是路径还是权限问题。
