若确认是 权限问题 导致 SQLite 数据库「无法打开」或「无法读写」，核心解决思路是：确保运行应用的用户（如 wzf）对数据库文件、数据库所在目录拥有完整的「访问权限」和「所有权」，同时排除系统级权限限制（如 SELinux/AppArmor）。以下是分场景的精准解决方案：
一、先明确「关键角色」
在解决权限问题前，需先确认两个核心信息：
运行应用的用户：你用 (venv) wzf@sweet:/var/www/blog$ 启动 Gunicorn，因此运行用户是 wzf；
数据库路径：假设你的数据库文件是 /var/www/blog/app.db（绝对路径），所在目录是 /var/www/blog。
二、基础权限修复：文件 + 目录权限 + 所有权
这是最常见的权限问题场景，需同时修复「文件权限」「目录权限」和「所有权」（三者缺一不可）。
1. 修复「数据库文件」的权限和所有权
数据库文件需要 wzf 有 读写权限（rw-），且所有者必须是 wzf（避免其他用户占用）：
bash
# 1. 强制将文件所有权改为 wzf（关键！避免 root 等其他用户占用）
sudo chown wzf:wzf /var/www/blog/app.db

# 2. 赋予文件读写权限（所有者可读写，其他用户只读，安全合规）
sudo chmod 644 /var/www/blog/app.db

# 3. 验证结果（必须确保所有者是 wzf，权限是 -rw-r--r--）
ls -l /var/www/blog/app.db
# 正确输出示例：
# -rw-r--r-- 1 wzf wzf 16384 Sep 27 10:00 /var/www/blog/app.db
2. 修复「数据库所在目录」的权限和所有权
SQLite 会在数据库所在目录创建临时文件（如 app.db-journal），因此目录需要 wzf 有 执行 + 写入权限（rwx）：
bash
# 1. 强制将目录所有权改为 wzf（递归，子目录也生效）
sudo chown -R wzf:wzf /var/www/blog

# 2. 赋予目录读写执行权限（所有者可操作，其他用户只读执行）
sudo chmod -R 755 /var/www/blog

# 3. 验证结果（所有者是 wzf，权限是 drwxr-xr-x）
ls -ld /var/www/blog
# 正确输出示例：
# drwxr-xr-x 2 wzf wzf 4096 Sep 27 10:00 /var/www/blog
3. 测试基础权限是否生效
修复后，用 wzf 用户直接读写数据库文件，验证权限是否正常：
bash
# 1. 用 wzf 用户创建一个测试文件（验证目录写入权限）
touch /var/www/blog/test.txt

# 2. 用 wzf 用户读写数据库文件（验证文件权限）
cat /var/www/blog/app.db  # 即使乱码，无「Permission denied」即正常

# 3. 若以上命令无报错，说明基础权限已修复
rm /var/www/blog/test.txt  # 删除测试文件
三、进阶权限修复：排除系统级限制（SELinux/AppArmor）
若基础权限修复后仍报错，大概率是 系统级安全工具（SELinux 或 AppArmor） 阻止了进程访问文件（常见于 CentOS、RHEL、Ubuntu Server）。
场景 1：SELinux 限制（CentOS/RHEL 为主）
SELinux 会强制管控进程对文件的访问，即使文件权限是 777，也可能被阻止。
1. 验证是否是 SELinux 问题
临时关闭 SELinux（重启后失效，仅用于测试）：
bash
# 临时关闭 SELinux
sudo setenforce 0

# 重新启动 Gunicorn 测试
/var/www/blog/venv/bin/gunicorn --bind 0.0.0.0:8888 app:app
若关闭后数据库正常访问，确认是 SELinux 限制，需添加永久规则；
若仍报错，跳过此节，检查 AppArmor。
2. 添加 SELinux 永久规则（允许访问数据库目录）
临时关闭 SELinux 不安全，需添加规则允许 Gunicorn（识别为 httpd 进程）访问 /var/www/blog：
bash
# 1. 为数据库目录添加 SELinux 标签（httpd_sys_rw_content_t 表示 httpd 可读写）
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/blog(/.*)?"

# 2. 应用标签到目录（让规则生效）
sudo restorecon -Rv /var/www/blog

# 3. 重新启用 SELinux（恢复系统安全）
sudo setenforce 1

# 4. 验证规则是否生效（输出包含 httpd_sys_rw_content_t 即正常）
ls -Z /var/www/blog | grep app.db
# 正确输出示例：
# -rw-r--r--. wzf wzf unconfined_u:object_r:httpd_sys_rw_content_t:s0 app.db

# 5. 启动 Gunicorn 验证
/var/www/blog/venv/bin/gunicorn --bind 0.0.0.0:8888 app:app
场景 2：AppArmor 限制（Ubuntu Server 为主）
AppArmor 类似 SELinux，会限制进程的文件访问范围，默认可能阻止 Gunicorn 访问非标准目录。
1. 验证是否是 AppArmor 问题
临时停止 AppArmor 服务（仅测试）：
bash
# 临时停止 AppArmor
sudo systemctl stop apparmor

# 重新启动 Gunicorn 测试
/var/www/blog/venv/bin/gunicorn --bind 0.0.0.0:8888 app:app
若停止后正常，确认是 AppArmor 限制；
若仍报错，需检查是否有其他进程占用数据库文件（如旧 Gunicorn 进程）。
2. 添加 AppArmor 规则（允许访问数据库目录）
bash
# 1. 为 Gunicorn 创建 AppArmor 配置文件
sudo nano /etc/apparmor.d/usr.local.bin.gunicorn  # 路径需匹配你的 Gunicorn 实际路径

# 2. 在文件中添加以下内容（允许访问数据库目录和文件）
#include <tunables/global>

/usr/local/bin/gunicorn {  # 替换为你的 Gunicorn 路径（用 which gunicorn 查看）
  # 原有规则...
  /var/www/blog/ r,          # 允许读取目录
  /var/www/blog/* rw,        # 允许读写目录下所有文件（含数据库）
  /tmp/ rw,                  # 允许读写临时文件（SQLite 可能用到）
}

# 3. 重新加载 AppArmor 规则
sudo apparmor_parser -r /etc/apparmor.d/usr.local.bin.gunicorn

# 4. 启动 AppArmor 服务
sudo systemctl start apparmor

# 5. 启动 Gunicorn 验证
/var/www/blog/venv/bin/gunicorn --bind 0.0.0.0:8888 app:app
四、终极验证：确保权限完全生效
修复后，通过以下步骤确认权限无问题：
重启 Gunicorn：确保加载最新的权限配置；
访问文章页面：如 http://服务器IP:8888/post/12，观察日志是否有「unable to open」错误；
检查数据库临时文件：访问后，查看数据库目录是否生成 app.db-journal（有则说明写入权限正常）：
bash
ls -l /var/www/blog | grep journal
# 若显示类似 -rw-r--r-- 1 wzf wzf 0 Sep 27 10:30 app.db-journal，说明正常
总结
权限问题的核心是「谁（用户）能访问什么（文件 / 目录），能做什么（读 / 写 / 执行）」，按以下优先级排查：
先修复 文件 + 目录的所有权和基础权限（最常见问题）；
再排查 SELinux/AppArmor 系统级限制（次之）；
最后确认 无其他进程占用数据库文件（如旧 Gunicorn 进程，用 pkill -f gunicorn 终止）。
按此流程操作，即可彻底解决 SQLite 数据库的权限问题。