Chroma 报 SQLite 版本太旧，命令行 sqlite3 却已经升级

导入 Chroma 报 Your system has an unsupported version of sqlite3，要求 SQLite 至少 3.35.0；终端 sqlite3 --version 却显示更高版本。这两个结果可以同时成立：命令行程序和 Python 扩展模块可能使用不同的 SQLite 库。

Chroma 0.5.0 的初始化源码检查 sqlite3.sqlite_version_info，Linux 等非 Colab 环境低于 (3, 35, 0) 就抛异常。官方 issue #1985保留了同类报错。本文针对存在这项检查的 Python 客户端，不把要求推广到所有历史版本或远程服务。

在应用的解释器里查版本

import sqlite3
import sys
print(sys.executable)
print(sqlite3.__file__)
print(sqlite3.sqlite_version)
with sqlite3.connect(":memory:") as connection:
    print(connection.execute("select sqlite_version()").fetchone()[0])

最后两项反映 Python 当前使用的库。服务由虚拟环境、systemd 或容器启动时，必须在那个环境执行；宿主机终端的结果不能证明容器也更新了。python -m pip show chromadb 则用于确认实际 Chroma 包版本。

若 Python 仍绑定旧 SQLite，选择含兼容 SQLite 的受支持 Python/基础镜像，并重建运行环境。仅升级命令行 SQLite，或在旧虚拟环境里再建一层 venv，未必改变底层 _sqlite3 的链接。重启应用后重新执行上面的诊断，版本达标后才检查 Chroma。

模块替换需要明确边界

一些受限平台使用 pysqlite3-binary，并在导入 Chroma 前替换 sys.modules["sqlite3"]。这要求包有适配当前 Python 和平台的 wheel，而且所有相关导入必须发生在替换后。已经被其他模块保存的旧 sqlite3 引用不会自动更新。

因此更适合优先修正基础运行环境，而不是在业务代码里到处加入替换片段。确需采用兼容模块时，把它放在唯一启动入口，记录包版本并检查返回的 sqlite_version。不要删除最低版本检查，或手工改 sqlite_version_info 让它看起来达标；底层 SQL 能力并没有随字符串变化。

持久化数据应先备份。用独立临时目录创建测试 collection，使用固定的显式向量执行 add、query，再关闭进程后重新打开，核对记录仍在。显式向量能避开默认 embedding 模型下载，把检查集中在存储链路。版本检查通过不能证明原库升级兼容；已有库还要按 Chroma 对应版本的迁移要求验收。