本文约 2,258 字，预计阅读 6 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：不装数据库，省一台机器？
SQLite 是一个嵌入式数据库，整个库就是一个文件，不需要独立服务进程。用 SQLite 跑 WordPress 意味着：不用装 MySQL、不用配用户权限、备份就是拷贝一个文件、迁移就是 SCP 一个文件。
听起来很美好。但 WordPress 是为 MySQL 设计的，SQLite 方案靠的是一层”翻译”（把 SQL 方言转换成 SQLite 语法），这层翻译决定了它的适用边界。
原理分析：SQLite 方案是怎么实现的
WordPress 官方并没有 SQLite 支持，社区方案（如 SQLite Integration、SQLite Database Integration）的做法是：
- 提供一个
db.phpdrop-in，放在wp-content/下； - 这个 drop-in 接管
$wpdb，把 MySQL 语法翻译成 SQLite 语法； - 数据库文件存在
wp-content/database/.htaccess保护下的.sqlite文件。
关键点：wpdb 的 SQL 是插件自己写的。翻译层能覆盖 WordPress 核心的查询，但插件里那些手写的复杂 SQL（JOIN 子查询、DATE_FORMAT()、GROUP_CONCAT()、正则匹配）就可能翻车。
保姆级实操：安装与验证
第一步：确认 PHP 有 SQLite 扩展
php -m | grep -i sqlite
# 应有 pdo_sqlite / sqlite3
第二步：安装插件
wp plugin install sqlite-database-integration --activate
激活后插件会把 db.php 复制到 wp-content/，之后 WordPress 会走 SQLite。
如果是全新安装，插件会引导你直接初始化 SQLite 数据库。
第三步：确认数据库文件位置
ls -la wp-content/database/
# .ht.sqlite 或类似文件
务必确认该文件不可通过 Web 访问（插件默认会写 .htaccess 拒绝访问，Nginx 用户需要自己加规则）：
location ~* /wp-content/database/ { deny all; }
location ~* \.(sqlite|sqlite3|db)$ { deny all; }
第四步：备份就是拷文件
cp wp-content/database/.ht.sqlite /backup/wp-$(date +%F).sqlite
注意：SQLite 在写入时会加锁，直接拷贝可能拿到不一致的快照。正确做法：
sqlite3 wp-content/database/.ht.sqlite ".backup '/backup/wp-$(date +%F).sqlite'"
可行性评估
优势
- 部署极简，适合本地开发、演示站；
- 备份/迁移就是一个文件；
- 内存占用极低，适合树莓派、极小 VPS；
- 读性能不错（小数据量下甚至比 MySQL 快）。
劣势
- 并发写入是硬伤：SQLite 写操作会锁整个库。多人同时评论、下单、后台编辑，会出现
database is locked错误； - 插件兼容性不稳定：WooCommerce、BuddyPress、复杂表单插件、统计类插件常有问题；
- 没有用户权限体系，安全全靠文件系统权限；
- 大数据量性能下降明显：超过几十万条记录后查询明显变慢；
- 很多运维工具不支持：phpMyAdmin、Adminer 的许多功能用不了，WP-CLI 的部分
wp db子命令不可用； - WP-Cron、对象缓存等涉及频繁写入的机制会成为瓶颈。
适合的场景
- 本地开发/演示（不用装 MySQL）；
- 个人静态博客，更新频率低、无评论；
- 离线内网文档站；
- 临时演示给客户看。
绝对不要用的场景
- 电商（WooCommerce）；
- 多作者、有评论互动的站点；
- 日 IP 上千的内容站；
- 需要定时写入的站点（统计、缓存插件会频繁写 options）。
常见踩坑与失败案例
database is locked—— 并发写入冲突。降低并发、减少插件写入，或者换回 MySQL。- 案例：某开发者用 SQLite 做演示站，客户验收时多人同时浏览并留言，站点频繁报错。最后迁回 MySQL 才稳定。SQLite 适合”一个人看”，不适合”一群人用”。
- 迁移回 MySQL 麻烦 —— SQLite 的 dump 与 MySQL 语法有差异，需要工具转换或重新导出内容（WXR）。先想清楚退出路径再用。
.sqlite文件被下载 —— Nginx 未配 deny 规则，数据库文件（含所有用户哈希）可被直接下载，这是严重事故。- 插件安装报错
no such function: ...—— 插件用了 SQLite 没有的 MySQL 函数，翻译层无能为力。
总结
SQLite 跑 WordPress 是一个”特定场景下的聪明方案”，不是通用替代。我的判断标准很简单：如果站点只有你一个人写、且内容量不大，可以用，省心；只要有并发写入需求（评论、订单、多作者），就不要用。 另外，采用前一定要确认退出路径——用 WXR 导出内容后能顺利迁回 MySQL，否则等于把自己锁死在一个小众方案里。
