SQLite是一个单文件嵌入式数据库，不需要独立的服务进程，这让它在Docker容器中部署显得格外轻便。但轻便不等于省心，容器文件系统的临时性决定了如果不做持久化处理，容器一删数据就没了。这篇文章围绕SQLite在Docker环境中的使用展开，重点讲清持久化方案、锁机制的坑以及具体的配置实践。
一、容器化场景下SQLite的基本特性
SQLite把整个数据库放在一个普通文件里，读写都通过应用进程内的SQLite库完成，没有独立的数据库服务端。这一点和MySQL、PostgreSQL有本质区别：后者在容器里跑的是一个守护进程，而SQLite在容器里跑的只是你的应用程序本身。所以在Docker中用SQLite，本质上就是让你的应用在容器内对一个数据库文件进行读写。
容器的文件系统是分层的、临时的。默认情况下，容器内写入的所有文件都存在于可写层，一旦容器被删除或重新创建，可写层随之销毁。对SQLite来说，这意味着如果数据库文件放在容器内部的普通目录下，docker rm之后再docker run，数据就会全部丢失。这是新手最容易踩的第一个坑。
另外一个特性也值得注意：SQLite依赖文件锁实现事务的并发控制。容器本身不影响文件锁，但一旦数据库文件所在的目录跨越了文件系统边界（比如挂载到宿主机目录），锁行为就可能受底层文件系统影响，这一点在后面会详细展开。
二、持久化方案：volume与bind mount的选择
Docker提供两种主流的持久化方式：docker volume（由Docker管理）和bind mount（直接挂载宿主机目录）。两种方式都能解决数据丢失问题，但适用场景不同。
使用named volume是最推荐的方式，Docker会自动管理存储位置，兼容性最好：
# 创建一个命名卷 docker volume create sqlite_data # 启动容器时挂载，假设应用的数据目录是 /app/data docker run -d \ --name myapp \ -v sqlite_data:/app/data \ myapp:latest
使用bind mount可以把数据直接放在宿主机的指定目录，方便直接查看和备份数据库文件：
# 将宿主机 /srv/sqlite 目录挂载到容器的 /app/data docker run -d \ --name myapp \ -v /srv/sqlite:/app/data \ myapp:latest
两者的差异需要仔细权衡。named volume存储在Docker管理的区域（Linux上通常是/var/lib/docker/volumes），文件系统类型统一，文件锁行为可预期；bind mount则受宿主机目录所在文件系统影响。一个典型的问题是：如果宿主机目录位于NFS或某些网络文件系统上，SQLite的文件锁可能失效，导致并发写入时出现database is locked错误，甚至造成数据库损坏。因此在生产环境中，如果选择bind mount，务必确保底层是本地文件系统如ext4或xfs。
还有一个细节容易被忽略：SQLite在WAL模式下除了主数据库文件，还会生成-wal和-shm两个附属文件。备份或迁移时如果只拷贝主文件而遗漏这两个文件，可能会丢失尚未checkpoint的事务数据。正确做法是先执行PRAGMA wal_checkpoint(TRUNCATE)再拷贝，或者干脆把整个数据目录一起处理。
三、Dockerfile编写与容器内路径规划
合理的Dockerfile应该明确数据库文件的存放路径，并保持权限清晰。下面以一个Python应用为例：
FROM python:3.12-slim # 创建非root用户，提升安全性 RUN useradd -m appuser WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . # 数据目录单独创建，供volume挂载 RUN mkdir -p /app/data && chown appuser:appuser /app/data USER appuser ENV SQLITE_DB_PATH=/app/data/app.db CMD ["python", "main.py"]
这里有几个要点。第一，数据目录/app/data固定下来，volume就挂这一个位置，避免散落在各处。第二，使用非root用户运行，但要注意挂载进来的volume属主可能不是appuser，如果宿主机上的目录权限不对，容器内会报unable to open database file错误，可以通过chown或设置合适的uid解决。第三，用环境变量SQLITE_DB_PATH注入数据库路径，方便在开发和生产环境之间切换。
四、用docker-compose统一管理
实际项目中用compose文件管理会更清晰，示例如下：
services:
app:
build: .
ports:
- "8000:8000"
volumes:
- sqlite_data:/app/data
environment:
- SQLITE_DB_PATH=/app/data/app.db
restart: unless-stopped
volumes:
sqlite_data:
这个配置声明了一个named volume，compose会自动创建和管理它。升级应用时执行docker compose up -d --build重建容器，volume不会被删除，数据自动延续。如果需要查看数据，可以用一个临时容器挂载同一个volume：
docker run --rm -it \ -v sqlite_data:/app/data \ -v /srv/backup:/backup \ alpine sqlite3 /app/data/app.db ".backup /backup/app.db"
这里用到了SQLite自带的.backup命令，它是在线备份，即使数据库正在被写入也能保证一致性，比直接cp文件安全得多。恢复时反向操作即可。
五、性能与适用场景的权衡
容器化并不会显著拖慢SQLite本身，但有几个性能相关的问题需要了解。首先是WAL模式的并发能力：默认的journal模式下写入会独占锁，多个请求并发写入容易出现锁冲突。开启WAL后读写可以并行，适合Web应用。应用初始化时执行：
import sqlite3
conn = sqlite3.connect("app.db")
conn.execute("PRAGMA journal_mode=WAL")
conn.execute("PRAGMA synchronous=NORMAL")
conn.close()
其次是busy_timeout的设置。默认情况下遇到锁会立即报错，设置超时时间可以让写入请求排队等待，显著减少database is locked错误：
conn = sqlite3.connect("app.db", timeout=30)
最后要客观评估SQLite是否适合你的场景。它的优势是零运维、零额外资源、备份就是拷文件，非常适合单机部署的小型服务、边缘计算、嵌入式设备以及读多写少的场景。但如果服务需要多容器横向扩展共享同一个数据库文件，SQLite就不合适了，多个容器通过各自文件系统访问同一个数据库文件无法可靠协同，这时应该改用PostgreSQL或MySQL这类网络数据库，让多个容器通过网络连接访问同一个数据库服务实例。
总结一下，在Docker中使用SQLite的关键点有三：用volume或本地文件系统的bind mount保证持久化，注意WAL附属文件和锁机制带来的边界问题，以及诚实评估并发与扩展需求。做到这三点，SQLite在容器里可以跑得既轻快又稳定。