云函数（Serverless Function）以按需执行、自动扩缩容著称，很多开发者会被它“零运维”的特性吸引，顺手就把轻量级的SQLite数据库嵌了进去。SQLite本身就是单文件、零配置的嵌入式数据库，看起来和云函数这种轻量执行单元是绝配。但真正跑起来之后，文件系统只读、临时目录丢失、并发写冲突、实例销毁导致连接失效等问题会一个接一个冒出来。下面从四个角度把SQLite在无服务器环境里的限制彻底拆开。

文件系统与持久化限制

云函数平台为了保证实例的快速拉起和销毁，通常会把运行环境的文件系统分成两个区域：一个是只读的代码包目录，另一个是容量很小的临时可写目录（常见的是/tmp）。SQLite数据库文件必须落在可写区域才能执行增删改操作，但这个临时目录有几个致命特性。

第一，临时目录的空间上限很小，AWS Lambda的/tmp只有512MB，阿里云函数计算默认512MB，Google Cloud Functions甚至给到的可写空间更小。SQLite数据库稍微积累一些业务数据就可能撑爆。第二，临时目录的生命周期和实例绑定，实例被回收时整个/tmp内容会被清空。云函数平台为了资源利用效率，会在实例空闲几分钟到几十分钟后将其销毁，这意味着你写入SQLite的数据随时可能消失。第三，即使同一个云函数同时存在多个实例，它们的/tmp也是彼此隔离的，实例A写入的数据实例B完全看不到。所以你根本没办法用SQLite在云函数里构建一个可共享、可持久化的数据层。

下面这个Python示例展示了在只读代码目录中尝试打开SQLite数据库时抛出的错误：

import sqlite3
import os
# 假设云函数的代码包目录是 /var/task，该目录只读
db_path = "/var/task/mydata.db"
try:
    conn = sqlite3.connect(db_path)
    conn.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)")
    print("数据库打开成功")
except sqlite3.OperationalError as e:
    print(f"操作失败: {e}")
    # 常见错误: attempt to write a readonly database

想绕过只读限制，只能把数据库文件放到/tmp，但这又回到了数据不持久、实例间不共享的老问题。除非你的业务完全不需要数据留存，比如把SQLite当作一次性的计算缓存，否则这条路走不通。

并发与锁机制的限制

SQLite的并发模型基于文件锁，同一个数据库文件在同一时间只允许一个写入者，读操作可以多个并行。在单机应用里这不是大问题，因为所有请求都走同一个进程，锁竞争可控。但云函数是典型的高并发场景，平台会在请求量上升时瞬间拉起几十上百个实例，每个实例都是一个独立进程，它们如果同时去写同一个SQLite文件，文件锁的争抢会非常严重。

更麻烦的是，云函数实例通常分布在不同的物理机上，即使你把SQLite数据库文件放在一个共享的网络存储（如NFS）上，SQLite的文件锁在NFS上的行为也不可靠。SQLite官方文档明确指出，在大多数NFS实现上，文件锁可能失效或者出现未定义行为，这会导致数据损坏而不是简单的锁等待。此外，多个实例同时写入同一个文件，还会触发“database is locked”错误，因为SQLite默认的锁超时时间很短（通常5秒），而云函数的执行时间往往很长，很容易超时失败。

下面模拟两个并发写入的场景，展示锁冲突的报错：

import sqlite3
import threading
db_path = "/tmp/shared.db"
conn = sqlite3.connect(db_path, timeout=2)
conn.execute("PRAGMA journal_mode=WAL")
conn.execute("CREATE TABLE IF NOT EXISTS counter (id INTEGER PRIMARY KEY, value INTEGER)")
conn.execute("INSERT OR IGNORE INTO counter (id, value) VALUES (1, 0)")
conn.commit()
def writer(name):
    local_conn = sqlite3.connect(db_path, timeout=2)
    try:
        for i in range(50):
            local_conn.execute("UPDATE counter SET value = value + 1 WHERE id = 1")
            local_conn.commit()
        print(f"{name} 写入完成")
    except sqlite3.OperationalError as e:
        print(f"{name} 遇到锁错误: {e}")
    finally:
        local_conn.close()
t1 = threading.Thread(target=writer, args=("线程A",))
t2 = threading.Thread(target=writer, args=("线程B",))
t1.start(); t2.start()
t1.join(); t2.join()

在实际的云函数环境中，这种锁冲突会成倍放大，因为不同实例之间没有线程共享内存，锁调度完全依赖文件系统，稳定性更差。很多开发者最终发现，在高并发下SQLite的写入性能会急剧下降，甚至直接报错，完全无法满足生产要求。

实例生命周期与连接管理限制

云函数的实例管理对SQLite还有一个隐蔽但影响巨大的限制：实例随时可能被冻结或销毁，数据库连接无法跨请求可靠复用。在传统后端服务里，我们通常会维护一个连接池，让多个请求复用已经建立的数据库连接，降低每次建立连接的开销。但云函数每次冷启动后，内存状态全部重置，你无法保证上一个请求建立的连接在下一次调用时仍然有效。

更糟糕的是，即使云函数平台复用了一个实例（热启动），SQLite连接对象也可能因为底层文件描述符失效而不可用。因为云函数在请求结束后可能会冻结实例的CPU和部分I/O，但文件句柄的状态不一定能保留。这就导致你每次请求都必须重新打开数据库连接，而SQLite打开连接的耗时虽然不高，但在高频率调用下累积起来也是明显的性能损耗。此外，频繁地打开和关闭数据库文件还会增加文件锁的获取和释放次数，进一步加剧并发问题。

还有一个容易忽略的点：SQLite的WAL模式（Write-Ahead Logging）依赖共享内存和文件系统特性，在云函数的临时目录或网络存储上可能无法正常工作。WAL模式需要mmap支持，但某些云函数运行环境限制了mmap的使用，导致WAL模式退化为普通日志模式，性能大打折扣。下面代码展示了尝试开启WAL模式可能遇到的错误：

import sqlite3
conn = sqlite3.connect("/tmp/test.db")
try:
    conn.execute("PRAGMA journal_mode=WAL")
    print("WAL模式开启成功")
except sqlite3.OperationalError as e:
    print(f"WAL模式开启失败: {e}")
    # 可能提示: cannot open memory mapped file
finally:
    conn.close()

综合来看，云函数的生命周期管理让SQLite连接复用成为奢望，而每次冷启动重新初始化数据库也会拖慢函数启动速度，影响用户体验。

替代方案与架构调整建议

既然SQLite在云函数中有如此多的限制，最直接的替代方案就是使用云厂商提供的托管数据库服务，比如AWS RDS、阿里云RDS、腾讯云TDSQL等。这些服务通过网络协议访问，天然支持多实例并发、持久化存储和自动备份，完全契合无服务器架构的特点。虽然会增加一定的网络延迟，但换来的是稳定性和可扩展性。

如果你的业务确实只需要轻量的键值存储，可以考虑使用云厂商的对象存储（如S3、OSS）配合简单的JSON文件，或者使用无服务器友好的数据库如Amazon DynamoDB、Google Firestore、阿里云表格存储等。这些服务按请求计费、自动扩缩容，和云函数的模型完美匹配。对于需要关系型模型的场景，Serverless Aurora或类似产品提供了MySQL/PostgreSQL兼容的按需实例，也是比SQLite更合理的选择。

如果因为某些原因必须使用SQLite，也可以退而求其次，将SQLite仅用于只读场景，比如把预先打包好的数据库文件放在代码包中，只做查询操作。这种方式下文件系统只读限制不会影响使用，而且只读并发读性能尚可。但要注意数据库文件不能太大，否则会增加函数冷启动时加载包的时间。还有一种做法是利用云函数的事件驱动特性，把SQLite当作临时计算工具，每次任务结束后主动删除文件，避免数据残留和锁竞争。

总之，SQLite在云函数环境中更适合当作只读缓存或一次性计算工具，而不是生产级数据存储。理解清楚这些限制，能帮助你少走很多弯路，在架构设计初期就做出正确的技术选型。