rusqlite加载spatialite扩展执行cargo run触发bus error如何解决

触发bus error的核心原因是进程内存在两套独立的SQLite实例导致内存访问冲突，属于系统级的内存访问异常，不是SQLite层面的逻辑错误，因此不会抛出常规的SqliteFailure异常：

• 你给rusqlite开启了bundled特性，该配置会在编译阶段拉取SQLite源码，静态编译出一套独立的SQLite实现直接嵌入到程序二进制中，这套SQLite和系统、Homebrew安装的SQLite完全隔离。
• 你加载的Homebrew预编译mod_spatialite扩展，编译时默认动态链接到Homebrew自身安装的SQLite动态库。
• 扩展加载进进程后，会和rusqlite静态打包的SQLite产生符号冲突、内部数据结构定义不匹配的问题，扩展尝试访问SQLite内部接口时直接触发非法内存访问，系统就会抛出bus error终止进程。
  你之前猜测的「SQLite和spatialite需要联合编译、版本匹配」方向是正确的，这个场景属于更极端的实例完全隔离问题，比普通版本号不匹配的故障层级更底层。

二选一即可，优先推荐方案1，配置成本最低：

方案1：关闭bundled特性，统一使用系统SQLite #

让rusqlite和mod_spatialite链接同一份系统安装的SQLite，从根源避免实例冲突：

1. 修改Cargo.toml里的rusqlite依赖，移除bundled特性：

[dependencies]
rusqlite = { version = "0.28.0", features = ["load_extension"] }

2. 确认本地Homebrew安装的sqlite3、libspatialite架构统一（M系列芯片不要混装arm64原生版和x86_64转译版），如果编译时提示找不到sqlite3头文件，先执行brew install sqlite3，再把Homebrew的sqlite3路径加入环境变量后重新编译即可。
3. 重新执行cargo run就能正常加载扩展。

方案2：保留bundled特性，自行编译匹配版本的spatialite #

如果你必须使用rusqlite bundled版本的SQLite（比如需要用到特定编译参数的SQLite能力），不要直接用Homebrew预编译的mod_spatialite，需要手动下载spatialite源码，编译时指定链接rusqlite bundled版本的SQLite，保证扩展和主程序使用完全一致的SQLite实现，彻底避免符号冲突。该方案配置复杂度高，无特殊需求不推荐使用。

你之前已经验证过路径错误时会正常抛出SqliteFailure，说明扩展加载的路径、入口点配置逻辑本身没有问题，不需要再在这两个方向上浪费排查时间。只要保证SQLite和spatialite来自同一套编译产物、版本完全匹配，就不会出现这类底层崩溃。

内容的提问来源于stack exchange，提问作者Seth Vincent