企业官网建设流程全解析

1. 项目概述：为什么是 Spring AI + PostgreSQL + pgvector 这个组合？

最近三个月，我手头连续接了四个企业级知识库项目，客户清一色要求“不依赖外部大模型服务、数据不出内网、能快速响应业务部门的FAQ更新”。一开始我本能想推 LangChain + Chroma 的轻量方案，结果在客户现场演示时被当场叫停——不是因为效果不好，而是因为 Chroma 默认把向量存本地文件系统，运维团队盯着我问：“这个 db 文件放在哪台服务器？权限怎么管？备份策略谁负责？并发写入冲突怎么处理？”三句话问得我后背发凉。那一刻我彻底明白：在真实生产环境里，向量数据库从来不是技术选型问题，而是运维治理问题。

Spring AI 这个框架之所以突然火起来，根本原因在于它把 LLM 调用、提示词编排、输出解析这些“脏活累活”全封装进 Spring 生态的 Bean 生命周期里，让 Java 工程师不用再写一堆胶水代码去拼接 OpenAI SDK、HuggingFace Inference API 和自定义 Embedding 服务。但光有 Spring AI 不够，它本身不带向量存储能力。这时候 PostgreSQL + pgvector 就成了最自然的选择——不是因为它性能最强（Qdrant 或 Milvus 单点吞吐确实更高），而是因为它把向量检索直接塞进了 DBA 每天都在维护的 PostgreSQL 里。你不需要额外部署一个新数据库，不用申请新端口白名单，不用给安全团队写三页纸的《向量数据库安全评估报告》，只需要在现有 PostgreSQL 实例上执行一条CREATE EXTENSION vector;，然后像建普通表一样建向量表。我上周刚帮某省政务云平台上线的 RAG 系统，他们 DBA 第一次看到SELECT * FROM documents ORDER BY embedding <=> '[0.1,0.2,...]' LIMIT 5;这条 SQL 时，眼睛都亮了：“这不就是个带距离函数的 ORDER BY 吗？索引还能照常建！”

标题里强调“上（环境安装）”，恰恰说明这是整个 RAG 落地最卡脖子的一环。很多团队卡在第一步就放弃了：Java 工程师对着 pgvector 的 C 扩展编译报错抓耳挠腮；运维同事在 CentOS 7 上死磕 PostgreSQL 15 的源码编译；前端同学想本地跑通 demo 却发现连 PostgreSQL 都没装好。这不是能力问题，而是信息碎片化太严重——官方文档只讲“怎么用”，社区教程要么只教 Docker 快速启动（脱离生产实际），要么堆砌 20 行 shell 脚本却不解释每一步为什么必须这么写。这篇内容，就是把我踩过的所有坑、记下的所有参数、验证过的每种安装路径，掰开揉碎了告诉你：在 x86_64 Linux 服务器、ARM64 Mac M系列芯片、Windows WSL2 三种主流开发环境里，如何让 PostgreSQL 和 pgvector 稳稳当当地跑起来，并且让 Spring Boot 项目能真正 connect 上去。如果你正被org.postgresql.util.PSQLException: ERROR: function vector_in(unknown) does not exist这类错误折磨，或者mvn clean install时 Spring AI 的VectorStoreBean 死活注入失败，请继续往下看。接下来的内容，没有一句废话，全是我在客户现场调通后的实操记录。

2. 环境整体设计与思路拆解：为什么拒绝 Docker 一键部署？

先说结论：在正式环境安装 PostgreSQL + pgvector，Docker 不是首选方案，而是最后兜底选项。这个判断不是凭空而来，而是基于过去半年我参与的 7 个 RAG 项目的真实反馈总结出来的。我把不同部署方式的适用场景画成一张表，你一眼就能看清取舍逻辑：

为什么我如此坚定地推荐“官方二进制包 + 预编译扩展”这条路径？核心就三个字：可追溯。当你在客户生产环境执行sudo apt install postgresql-15时，你清楚知道这个 deb 包来自 https://apt.postgresql.org/ 官方仓库，SHA256 校验值可在官网查到；当你从 https://github.com/pgvector/pgvector/releases 下载pgvector--0.7.2.sql和pgvector.so时，你能用gpg --verify pgvector--0.7.2.sql.sig验证签名。这种可验证的供应链，是 Docker 镜像永远无法提供的——你永远不知道那个postgres:15-alpine镜像里，基础 OS 层有没有被植入恶意模块。

更关键的是，Spring AI 的PostgreSqlVectorStore类在底层调用的是 JDBC 的Connection对象，它对数据库的“感知”完全基于标准 SQL 协议。无论你是用 Docker 启动的 PostgreSQL，还是用源码编译的，只要 JDBC URL 能连上、vector扩展能成功创建，Spring Boot 就不会有任何感知差异。所以把精力花在“让 pgvector 在各种 Linux 发行版上稳定加载”，远比研究“如何给 Docker 容器挂载 pgvector 的 so 文件”更有价值。

还有一个容易被忽略的细节：pgvector 的向量索引类型选择，直接决定了你的 RAG 响应延迟。pgvector 提供两种索引：IVFFlat（适合中小规模数据，建索引快，查询延迟稳定）和HNSW（适合百万级以上向量，查询更快但建索引内存占用高）。很多教程一上来就教CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);，结果客户导入 50 万条文档后，建索引直接吃光 32GB 内存。我在某银行项目里实测过：同样是 100 万条 768 维向量，IVFFlat建索引耗时 8 分钟，内存峰值 4.2GB；HNSW建索引耗时 23 分钟，内存峰值 18.7GB。而查询 P95 延迟两者相差不到 12ms。所以本文所有实操步骤，默认采用IVFFlat索引，这是生产环境最稳妥的选择。等你真正需要亚秒级响应时，再考虑HNSW的调优。

3. 核心细节解析与实操要点：绕不开的三大硬核环节

3.1 PostgreSQL 安装：别再用apt install postgresql了！

这是新手最容易栽跟头的第一步。Ubuntu/Debian 系统自带的postgresql包，版本往往停留在 12 或 13，而 pgvector 0.7.x 要求 PostgreSQL 14+。更致命的是，系统包管理器安装的 PostgreSQL，其扩展目录（$libdir）路径和官方二进制包完全不同，导致你辛辛苦苦下载的pgvector.so文件放错地方，CREATE EXTENSION vector;永远报错could not open extension control file "/usr/share/postgresql/15/extension/vector.control"。

正确的做法，是完全绕过系统包管理器，直连 PostgreSQL 全球社区的官方 APT 仓库。以下是我在 Ubuntu 22.04 上验证通过的完整流程，每一步都附带原理说明：

# Step 1：导入官方 GPG 密钥（验证包来源合法性） wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - # Step 2：添加官方 APT 仓库（注意：这里指定了 jammy，即 Ubuntu 22.04 代号） echo "deb https://apt.postgresql.org/pub/repos/apt/ jammy-pgdg main" | sudo tee /etc/apt/sources.list.d/pgdg.list # Step 3：更新包索引（关键！很多教程漏掉这步，导致 apt 找不到新包） sudo apt-get update # Step 4：安装 PostgreSQL 15 及其客户端（不要装 postgresql-server-dev-15！那是给开发者编译扩展用的，我们用预编译 so） sudo apt-get install -y postgresql-15 postgresql-client-15 # Step 5：验证安装（重点看版本和数据目录） sudo -u postgres psql --version # 应输出 psql (PostgreSQL) 15.x sudo -u postgres psql -c "SHOW data_directory;" # 记下这个路径，后面 pgvector.so 要放这里

提示：CentOS/RHEL 用户请访问 https://www.postgresql.org/download/linux/redhat/，下载对应版本的 RPM 包。特别注意：RHEL 8+ 默认使用dnf，执行sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm后，再sudo dnf install postgresql15-server。千万别用yum install postgresql，那会装上系统自带的旧版。

安装完成后，最关键的一步是确认 PostgreSQL 的$libdir路径。这个路径决定了 pgvector.so 文件该放在哪里。执行以下命令获取精确路径：

sudo -u postgres psql -c "SHOW config_file;" # 输出类似 /etc/postgresql/15/main/postgresql.conf # 然后根据 config_file 路径，推导 libdir： # Ubuntu 22.04 的典型路径是 /usr/lib/postgresql/15/lib/ # CentOS 7 的典型路径是 /usr/pgsql-15/lib/ # macOS Homebrew 的典型路径是 /opt/homebrew/opt/postgresql@15/lib/postgresql/

注意：网上大量教程让你执行pg_config --pkglibdir，这个命令在某些环境下会返回空值。最可靠的方式，是直接查postgresql.conf中的dynamic_library_path参数，或用sudo -u postgres psql -c "SHOW dynamic_library_path;"。如果返回为空，则默认使用$libdir，而$libdir的值就是上面pg_config --pkglibdir的输出（若可用）或根据发行版约定的路径。

3.2 pgvector 扩展安装：so 文件放错位置，一切归零

pgvector 的安装，本质就是两件事：把pgvector.so动态链接库文件放到 PostgreSQL 能找到的地方，再把pgvector--0.7.2.sql控制文件放到 PostgreSQL 的扩展目录。很多人卡在这一步，反复执行CREATE EXTENSION vector;却始终报错ERROR: could not access file "$libdir/vector": No such file or directory。根本原因，就是pgvector.so文件放错了目录。

以下是我在 x86_64 Linux、ARM64 macOS 和 Windows WSL2 三种环境下的实测路径清单，请务必对照你的环境选择对应路径：

下载 pgvector 的正确姿势：

# 进入你的 PostgreSQL $libdir 目录（以 Ubuntu 为例） cd /usr/lib/postgresql/15/lib/ # 下载对应平台的 pgvector.so（注意：Linux x86_64 选 linux-amd64，ARM64 选 linux-arm64） sudo wget https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2-linux-amd64.so -O vector.so # 进入 extension 目录 cd /usr/share/postgresql/15/extension/ # 下载控制文件和 SQL 文件 sudo wget https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2.sql sudo wget https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2--0.7.1.sql # 升级脚本，备用

提示：pgvector--0.7.2-linux-amd64.so这个文件名里的linux-amd64是关键。如果你在 Apple M2/M3 芯片的 Mac 上用 Homebrew 安装 PostgreSQL，必须下载linux-arm64.so（Homebrew 在 ARM64 Mac 上构建的 PostgreSQL 二进制是通用的，能运行 ARM64 so）。Windows WSL2 用户，无论宿主机是 Intel 还是 AMD CPU，WSL2 子系统都是 x86_64 架构，所以一律下载linux-amd64.so。

文件放好后，别急着CREATE EXTENSION。先做两件事：

1. 检查文件权限：sudo chmod 755 vector.so，确保 PostgreSQL 进程（通常是postgres用户）有读取和执行权限。
2. 验证 so 文件完整性：file vector.so应输出ELF 64-bit LSB shared object, x86-64...（Linux）或Mach-O 64-bit dynamically linked shared library arm64（macOS）。如果输出cannot open，说明下载损坏，重下。

3.3 Spring Boot 项目集成：JDBC 驱动与依赖的隐秘战争

很多 Spring Boot 开发者以为，只要application.yml里配好spring.datasource.url=jdbc:postgresql://localhost:5432/mydb，再加个spring-ai-spring-boot-starter依赖，就能自动用上 pgvector。这是最大的认知误区。Spring AI 的PostgreSqlVectorStore类，底层依赖两个关键能力：JDBC 驱动必须支持vector数据类型的映射，以及PostgreSQL 服务端必须已加载vector扩展。前者是 Java 侧，后者是 DB 侧，缺一不可。

首先，JDBC 驱动版本是生死线。PostgreSQL 官方 JDBC 驱动（org.postgresql:postgresql）在 42.6.0 版本才正式支持vector类型。低于此版本，即使数据库里vector扩展已启用，JDBC 也会在解析SELECT embedding FROM documents时抛出org.postgresql.util.PSQLException: Bad value for type vector : [0.1,0.2,...]。因此，你的pom.xml必须显式声明驱动版本：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jdbc</artifactId> </dependency> <!-- 显式指定 JDBC 驱动，覆盖 Spring Boot 默认的 42.5.x --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>42.6.0</version> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-spring-boot-starter</artifactId> <version>0.8.1</version> <!-- Spring AI 当前最新稳定版 --> </dependency>

其次，application.yml的配置有陷阱。很多教程直接抄spring.ai.vector-store.postgresql.jdbc-url=jdbc:postgresql://localhost:5432/mydb，却忽略了JDBC URL 必须启用stringtype=unspecified参数。这是因为 pgvector 的vector类型在 JDBC 中被映射为PGobject，而默认的stringtype=binary会强制将向量数组转成二进制流，导致 Spring AI 解析失败。正确配置如下：

spring: datasource: url: jdbc:postgresql://localhost:5432/mydb?stringtype=unspecified&sslmode=disable username: postgres password: your_password ai: vector-store: postgresql: jdbc-url: ${spring.datasource.url} # 复用上面的 URL # 注意：这里不能写成 jdbc:postgresql://...，必须和 datasource.url 一致 # 因为 Spring AI 内部会复用 DataSource Bean

注意：sslmode=disable是为了本地开发环境简化配置。生产环境必须启用 SSL，并配置sslmode=require及对应的证书路径。

最后，也是最容易被忽略的一步：在 Spring Boot 启动时，必须确保vector扩展已在目标数据库中创建。不能指望 Spring AI 自动帮你执行CREATE EXTENSION vector;。你需要在项目启动前，手动登录 psql 执行：

-- 切换到你的业务数据库 \c mydb -- 创建 vector 扩展（只需执行一次） CREATE EXTENSION IF NOT EXISTS vector; -- 验证是否成功 SELECT * FROM pg_extension WHERE extname = 'vector'; -- 应返回一行，extversion 字段为 0.7.2

如果你用 Flyway 或 Liquibase 做数据库迁移，强烈建议把CREATE EXTENSION vector;写进第一个 migration 脚本里，作为整个 RAG 系统的“基石 SQL”。

4. 实操过程与核心环节实现：从零开始的完整安装流水线

4.1 Ubuntu 22.04 x86_64 环境：生产环境黄金标准

这是我在金融、政务、制造业客户中最常部署的环境。以下是我整理的、可直接复制粘贴执行的完整 Shell 脚本，每一步都经过 3 次以上重装验证：

#!/bin/bash # Ubuntu 22.04 PostgreSQL 15 + pgvector 0.7.2 安装脚本 # 作者：一线 RAG 工程师 | 2024年10月实测于阿里云 ECS（4C8G） set -e # 任何命令失败立即退出 echo "=== 步骤1：导入 PostgreSQL 官方 GPG 密钥 ===" wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - echo "=== 步骤2：添加官方 APT 仓库 ===" echo "deb https://apt.postgresql.org/pub/repos/apt/ jammy-pgdg main" | sudo tee /etc/apt/sources.list.d/pgdg.list echo "=== 步骤3：更新包索引 ===" sudo apt-get update echo "=== 步骤4：安装 PostgreSQL 15 ===" sudo apt-get install -y postgresql-15 postgresql-client-15 echo "=== 步骤5：初始化数据库并启动服务 ===" sudo systemctl start postgresql sudo systemctl enable postgresql echo "=== 步骤6：获取 PostgreSQL 的 libdir 和 extension 目录 ===" LIBDIR=$(sudo -u postgres psql -t -c "SHOW config_file;" | xargs dirname | sed 's|/data||' | sed 's|/global||' | sed 's|/pg_hba.conf||' | sed 's|/postgresql.conf||' | sed 's|/main||' | sed 's|/15||' | sed 's|/etc||' | sed 's|^$|/usr/lib/postgresql/15/lib/|' | head -1) EXTDIR=$(echo $LIBDIR | sed 's|lib|share|' | sed 's|/postgresql/15/lib|/postgresql/15/extension|') echo "检测到 libdir: $LIBDIR" echo "检测到 extension 目录: $EXTDIR" echo "=== 步骤7：下载并安装 pgvector 扩展 ===" # 创建目录（如果不存在） sudo mkdir -p $LIBDIR $EXTDIR # 下载 pgvector.so（x86_64） cd $LIBDIR sudo wget https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2-linux-amd64.so -O vector.so sudo chmod 755 vector.so # 下载 SQL 控制文件 cd $EXTDIR sudo wget https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2.sql sudo wget https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2--0.7.1.sql echo "=== 步骤8：切换到 postgres 用户，创建测试数据库并启用 vector 扩展 ===" sudo -u postgres psql -c "CREATE DATABASE rag_demo;" sudo -u postgres psql -d rag_demo -c "CREATE EXTENSION IF NOT EXISTS vector;" echo "=== 步骤9：验证安装 ===" RESULT=$(sudo -u postgres psql -d rag_demo -t -c "SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';") if [[ $RESULT == *"vector"* ]]; then echo "✅ pgvector 安装成功！扩展版本：$(echo $RESULT | awk '{print $2}')" else echo "❌ pgvector 安装失败，请检查日志" exit 1 fi echo "=== 步骤10：配置 PostgreSQL 允许远程连接（可选，生产环境必需） ===" # 修改 postgresql.conf sudo sed -i "s/#listen_addresses = 'localhost'/listen_addresses = '*'/" /etc/postgresql/15/main/postgresql.conf # 修改 pg_hba.conf，允许所有 IP 连接（生产环境请替换为具体网段） echo "host all all 0.0.0.0/0 md5" | sudo tee -a /etc/postgresql/15/main/pg_hba.conf echo "=== 步骤11：重启 PostgreSQL 服务 ===" sudo systemctl restart postgresql echo "🎉 安装完成！请执行以下命令验证：" echo "psql -h localhost -U postgres -d rag_demo -c \"SELECT * FROM pg_extension WHERE extname = 'vector';\""

把这个脚本保存为install_pgvector.sh，然后执行chmod +x install_pgvector.sh && ./install_pgvector.sh。整个过程约 4 分钟，结束后你会得到一个已启用vector扩展的rag_demo数据库。

4.2 macOS Monterey (ARM64) 环境：M系列芯片开发者的终极指南

Apple Silicon 的痛点在于：Homebrew 安装的 PostgreSQL，其$libdir路径和传统 Linux 完全不同，且pgvector.so必须是 ARM64 架构。很多开发者用brew install postgresql后，直接下载 x86_64 的 so 文件，结果CREATE EXTENSION报mach-o, but wrong architecture错误。

正确流程如下（全程在终端执行）：

# Step 1：确保 Homebrew 是最新版 brew update && brew upgrade # Step 2：安装 PostgreSQL 15（Homebrew 会自动处理依赖） brew install postgresql@15 # Step 3：启动 PostgreSQL 服务 brew services start postgresql@15 # Step 4：获取 Homebrew PostgreSQL 的真实路径（关键！） # Homebrew 的 PostgreSQL 15 通常安装在 /opt/homebrew/opt/postgresql@15 POSTGRESQL_HOME=$(brew --prefix postgresql@15) echo "PostgreSQL Home: $POSTGRESQL_HOME" # Step 5：确定 libdir 和 extension 目录 LIBDIR="$POSTGRESQL_HOME/lib/postgresql" EXTDIR="$POSTGRESQL_HOME/share/postgresql/extension" echo "libdir: $LIBDIR" echo "extension dir: $EXTDIR" # Step 6：创建目录并下载 ARM64 版本的 pgvector.so mkdir -p $LIBDIR $EXTDIR cd $LIBDIR # 下载 ARM64 版本（注意文件名中的 linux-arm64） curl -L https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2-linux-arm64.so -o vector.so chmod 755 vector.so # Step 7：下载 SQL 文件 cd $EXTDIR curl -L https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2.sql -o pgvector--0.7.2.sql curl -L https://github.com/pgvector/pgvector/releases/download/v0.7.2/pgvector--0.7.2--0.7.1.sql -o pgvector--0.7.2--0.7.1.sql # Step 8：初始化数据库并启用扩展 createdb rag_demo psql -d rag_demo -c "CREATE EXTENSION IF NOT EXISTS vector;" # Step 9：验证 psql -d rag_demo -c "SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';"

实操心得：M系列 Mac 上，brew install postgresql@15会同时安装libpq和postgresql两个 Formula。libpq是 C 客户端库，postgresql是服务器。你必须brew install postgresql@15，而不是brew install libpq，否则pg_config命令不可用，$libdir路径也无法准确推导。

4.3 Windows WSL2 (Ubuntu 22.04) 环境：无缝衔接 Windows 开发者

这是很多 Java 工程师的首选：用 Windows 做 IDE（IntelliJ IDEA），用 WSL2 做后端服务。关键是要让 WSL2 的 PostgreSQL 能被 Windows 主机上的 IDEA 访问。

# 在 WSL2 的 Ubuntu 终端中执行 # （假设你已按 4.1 节安装好 PostgreSQL 15） # Step 1：修改 PostgreSQL 配置，监听所有地址 sudo sed -i "s/#listen_addresses = 'localhost'/listen_addresses = '0.0.0.0'/g" /etc/postgresql/15/main/postgresql.conf sudo sed -i "s/#port = 5432/port = 5432/g" /etc/postgresql/15/main/postgresql.conf # Step 2：修改 pg_hba.conf，允许 WSL2 网络访问 # 获取 WSL2 的主机 IP（Windows 主机在 WSL2 网络中的 IP） HOST_IP=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}') echo "host all all $HOST_IP/32 md5" | sudo tee -a /etc/postgresql/15/main/pg_hba.conf # Step 3：重启服务 sudo systemctl restart postgresql # Step 4：在 Windows 主机上，用 DBeaver 或 IDEA 的 Database 工具连接 # JDBC URL: jdbc:postgresql://127.0.0.1:5432/rag_demo # 用户名: postgres # 密码: 你的密码

注意：WSL2 的网络是 NAT 模式，localhost在 Windows 和 WSL2 中指向不同设备。Windows 上的localhost:5432指向 Windows 自身，不是 WSL2。所以必须用127.0.0.1（这是 WSL2 的 loopback 地址），并在pg_hba.conf中添加host ... 127.0.0.1/32规则。

5. 常见问题与排查技巧实录：那些让我凌晨三点还在改配置的 Bug

5.1 经典报错：function vector_in(unknown) does not exist

这是 pgvector 安装失败的“头号杀手”，90% 的案例都源于同一个原因：pgvector.so文件没放进$libdir，或者放进了$libdir但文件名不是vector.so。

排查步骤：

1. 确认 PostgreSQL 进程看到的$libdir：

   SELECT name, setting FROM pg_settings WHERE name = 'dynamic_library_path'; -- 如果为空，则执行： SHOW config_file; -- 然后根据 config_file 路径，推导 libdir（如 /etc/postgresql/15/main/postgresql.conf -> /usr/lib/postgresql/15/lib/）

2. 确认vector.so文件存在且权限正确：

   ls -la /usr/lib/postgresql/15/lib/vector.so # 应输出 -rwxr-xr-x 1 root root ... vector.so # 如果是 -rw-r--r--，则执行 sudo chmod 755 /usr/lib/postgresql/15/lib/vector.so

3. 确认pgvector--0.7.2.sql文件存在且内容完整：

   head -5 /usr/share/postgresql/15/extension/pgvector--0.7.2.sql # 应看到类似 "comment on extension vector is 'vector similarity search for PostgreSQL';" 的内容

4. 终极验证：手动加载 so 文件：

   -- 在 psql 中执行 SELECT pg_reload_conf(); -- 重新加载配置 CREATE OR REPLACE FUNCTION vector_in(cstring) RETURNS vector AS '/usr/lib/postgresql/15/lib/vector', 'vector_in' LANGUAGE C IMMUTABLE STRICT;

   如果这一步成功，说明 so 文件路径和符号都正确，CREATE EXTENSION vector;就一定能成功。

5.2 Spring Boot 启动报错：Failed to instantiate [org.springframework.ai.vectorstore.VectorStore]

这个错误表面是 Spring AI Bean 创建失败，根源往往在 JDBC 层。按以下顺序排查：

5.3 性能怪谈：为什么IVFFlat索引查询比全表扫描还慢？

这是新手最容易陷入的思维陷阱。IVFFlat索引不是“建了就快”，它需要两个前提：足够多的训练样本和合理的lists参数。

IVFFlat的工作原理是：先把所有向量聚成lists个簇（cluster），查询时只搜索离查询向量最近的probes个簇。如果lists太小（如lists=10），每个簇里向量太多，搜索范围还是很大；如果lists太大（如lists=10000），训练时间爆炸，且probes设置不当会导致漏召回。

我的实测黄金比例是：lists = sqrt(n)，其中 n 是向量总数。例如，1