看起来你的虚拟环境虽然表面显示激活成功，但pip还是偷偷把包装到了系统Python的目录里，这种情况我之前排查过好几次，给你几个实用的排查和解决方向：

1. 优先使用python -m pip替代直接调用pip3.12 #

有时候直接用pip3.12命令会因为系统别名、pip配置缓存等问题“跑偏”，而python3.12 -m pip是强制绑定当前Python解释器对应的pip，这是最稳妥的调用方式。你可以试试：

python3.12 -m pip install hello-world

如果成功，包应该会被安装到venv/lib/python3.12/site-packages/目录下。

2. 检查pip的全局/用户配置是否被篡改 #

有可能你的pip被设置了全局的安装目标路径，导致不管用哪个环境的pip都往系统目录装。运行以下命令查看配置：

pip3.12 config list --global
pip3.12 config list --user

如果输出里有install.target这类指向/opt/homebrew/lib/python3.12/site-packages/的配置项，直接用下面的命令删除：

pip3.12 config unset --global install.target
pip3.12 config unset --user install.target

3. 确认虚拟环境的激活状态是否完全生效 #

除了用which python3.12检查路径，还可以验证虚拟环境的核心环境变量：

echo $VIRTUAL_ENV

正常情况下应该输出你的venv目录的绝对路径，如果结果是空的，说明source venv/bin/activate没有真正生效——比如你是不是在错误的目录下执行的激活命令？或者你的shell有特殊配置干扰了激活脚本？

4. 检查venv的pip脚本是否被意外替换 #

有时候创建虚拟环境时可能出现文件损坏，导致venv里的pip其实还是调用系统的Python。你可以查看pip脚本的头部：

cat $(which pip3.12)

正常的第一行应该是#!/<你的repo目录>/venv/bin/python3.12，如果显示的是#!/opt/homebrew/bin/python3.12，说明这个pip脚本有问题，需要重建虚拟环境。

5. 彻底重建虚拟环境（终极方案） #

如果上面的方法都没解决问题，大概率是虚拟环境创建时出了隐性错误，直接删掉重建：

# 先退出当前虚拟环境
deactivate
# 删除旧的venv目录
rm -rf venv
# 重新创建并激活
python3.12 -m venv venv
source venv/bin/activate
# 先升级venv里的pip到最新版本
python3.12 -m pip install --upgrade pip

重建后再试安装包，应该就能正常关联到venv目录了。

备注：内容来源于stack exchange，提问作者JaytheInj