核心是分层隔离：解释器版本、项目依赖、动态库路径三者必须各自独立。用pyenv管理python解释器版本，venv隔离项目依赖，nvm/sdkman!等管理其他语言运行时，并严格控制动态库加载路径避免abi冲突。
核心是分层隔离：解释器版本、项目依赖、动态库路径三者必须各自独立，不能互相渗透。
用 pyenv 管理 Python 解释器版本
系统自带的 /usr/bin/python3 不可修改，Homebrew 安装的 Python 也不建议直接使用。统一交给 pyenv 控制：
- 安装后在
~/.zshrc中配置 shims，确保which python指向~/.pyenv/shims/python - 按需安装多个版本，例如：
pyenv install 3.9.18 3.11.9 - 全局设默认：
pyenv global 3.11.9；项目级覆盖：pyenv local 3.9.18（会在目录下生成.python-version） - 验证时
python --version和which python必须实时响应变更
用 venv 隔离每个项目的 Python 包依赖
pyenv 解决“用哪个 Python”，venv 解决“包装在哪”：
- 进入项目目录执行：
python -m venv .venv - 激活：
source .venv/bin/activate（终端提示符前会出现(.venv)） - 此时
which pip和which python都指向.venv内路径，pip install只影响当前环境 - 退出用
deactivate，环境保留，下次source即可复用
用 nvm 或 sdkman! 管理 Node.js、Java 等其他语言运行时
不要用 npm install -g 或系统级安装，而是用轻量用户态工具：
- Node.js：用
nvm，支持nvm install 18.20.4、nvm use 18.20.4、nvm alias default 20.15.0，配合.nvmrc自动切换 - Java：用
sdkman!，一条命令装 JDK + Maven：sdk install java 21.0.3-tem，再sdk default java 21.0.3-tem - Rust/Go：分别用
rustup和g管理，自动更新RUSTUP_HOME和GOROOT
控制动态库加载路径，避免 ABI 冲突
很多崩溃源于 Python 扩展或 CLI 工具错误链接了 Homebrew 的 dylib，而系统组件依赖旧版 ABI：
- 检查真实加载行为：
dyld_print_libs=1 python -c "import numpy" 2>&1 | grep -i lib - 确认 rpath 是否写入：
otool -l your_binary | grep -A2 LC_RPATH；缺失则用install_name_tool -add_rpath补上 - 避免全局污染：
DYLD_LIBRARY_PATH仅用于调试，生产环境推荐用@rpath编译或重写二进制依赖 - 对已编译工具，可用
install_name_tool -change替换 dylib 路径，并配-add_rpath确保间接依赖可被找到
