venv 激活本质是修改 shell 的 path 环境变量；direnv 是最可靠跨 shell 的自动激活方案，需安装、配置 hook 并在项目根目录创建授权的 .envrc；手动 alias 方案有跨目录失效和无法自动 deactivate 等缺陷。
venv 激活的本质是修改 shell 的 PATH 环境变量
Python venv 本身不提供“自动激活”功能，它只生成一个隔离环境目录（含 bin/activate 脚本）。所谓“自动激活”，其实是靠 shell 在进入目录时主动执行 source bin/activate —— 这步必须由用户或 shell 工具完成，venv 不参与也不感知。
常见误解是以为改 pyvenv.cfg 或加钩子就能触发激活，但那些只影响解释器行为（比如是否使用系统 site-packages），和 shell 环境变量无关。
用 direnv 实现真·自动激活（推荐）
direnv 是目前最可靠、跨 shell（bash/zsh/fish）、且不污染全局配置的方案。它在你 cd 进入含 .envrc 的目录时，自动加载环境变量并执行命令。
- 安装：
brew install direnv（macOS）或sudo apt install direnv（Ubuntu） - 在 shell 配置中添加 hook（例如 zsh 的
~/.zshrc）：eval "$(direnv hook zsh)" - 进入你的项目根目录，创建
.envrc：layout python
（如果已用python -m venv .venv创建了环境） - 首次运行会提示
direnv: disallowed changes to the environment，执行direnv allow授权
之后每次 cd 进该目录，bin/activate 就会静默执行，which python 指向 .venv/bin/python，退出目录则自动还原。
不用额外工具：在 cd 后手动 alias（简单但有坑）
如果你不想装 direnv，可以用 shell alias + 函数模拟，但要注意几个硬伤：
- 不能跨子目录生效（比如
cd src/就失效） - 容易和已有
cd别名冲突（如 oh-my-zsh 的autojump） - 无法自动 deactivate，退出后仍保留
venv环境
示例（zsh）：
cd() { builtin cd "$@"; [[ -f ".venv/bin/activate" ]] && source ".venv/bin/activate"; }——但不建议长期依赖这个，尤其团队协作时别人不会共享你的 shell 函数。
为什么不要碰 pyenv / conda 自动切换？
有人想用 pyenv 的 pyenv local 或 conda activate --stack 替代，但它们解决的是 Python 版本/环境名切换，不是当前目录下的 venv 激活。它们不会识别 .venv/ 目录，也不会执行 bin/activate 中的 PATH 注入逻辑。强行混用反而导致 python 和 pip 路径不一致，出现 ModuleNotFoundError 却 pip list 看不到包的诡异情况。
真正要小心的，是 .venv 目录名被工具误判（比如某些编辑器或 linter 默认忽略 .venv，但 direnv 默认支持）。如果换成了 env/ 或 venv-dev/，记得同步更新 .envrc 里的 layout python 或显式写 source env/bin/activate。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
