这个坑值得记一笔。Windows 上 Python 3.12 自带 sqlite3，pip install sqlite-vec 0.1.6 后照文档执行 conn.load_extension("vec0")，报 sqlite3.OperationalError: no such module: vec0，换了绝对路径也一样。
刚开始盯着「扩展名写成了 vec0 而实际要加载 vec0.dll 的全路径」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。Python 的 sqlite3 默认没开 enable_load_extension；loadable_path 指向的 dll 与当前解释器位数不匹配；系统自带的 sqlite 编译时没打开动态加载选项。
动手时先打印解释器里 sqlite 的版本和编译选项
python -c "import sqlite3;print(sqlite3.sqlite_version);print([r for r in sqlite3.connect(':memory:').execute('pragma compile_options') if 'LOAD' in r[0]])"接着确认扩展文件真实路径
python -c "import sqlite_vec;print(sqlite_vec.loadable_path())"显式开启加载后再加载并查版本
python -c "import sqlite3,sqlite_vec;c=sqlite3.connect(':memory:');c.enable_load_extension(True);sqlite_vec.load(c);print(c.execute('select vec_version()').fetchone())"若系统 sqlite 不支持，改装自带扩展的 pysqlite3-binary
pip install pysqlite3-binary隔了一天再看，现象没变，说明不是偶发。
那几天正好在做别的变更，先把时间线对齐才敢动手。
怎么算真的好了，看的是同一批现象。vec_version() 返回 0.1.6，建 vec0 虚拟表并插入三条向量后 KNN 查询能正常返回距离。
容易忽略的是，sqlite-vec 是运行时加载的扩展，不是纯 Python 包，换成打包好的 pysqlite3-binary 往往比在系统 sqlite 上折腾编译快得多。报错文案容易误导，真正的原因往往在相邻那一层的日志里。