pip freeze > requirements.txt 在新机器上装不完，因它导出所有包（含间接依赖、开发依赖、本地包），不区分来源与版本约束强度，且跨平台编译产物、系统库依赖易导致安装失败。
pip freeze > requirements.txt 为什么在新机器上装不完？
因为 pip freeze 会导出所有已安装包（包括间接依赖、开发依赖、甚至你手动 install -e 的本地包），但不区分来源和版本约束强度。很多包在不同平台编译产物不同（比如 numpy、torch），或依赖系统库（如 lxml 需要 libxml2），直接 pip install -r 容易卡在编译或版本冲突。
- 只在干净虚拟环境中运行
pip freeze > requirements.txt，避免混入全局或旧环境残留 - 用
pip install --no-deps先装主依赖，再逐个验证子依赖是否真需要 - 对二进制包（如
torch、tensorflow），优先从官网找对应平台的.whl下载后本地 install，别依赖 PyPI 自动选 - 若项目用了
pyproject.toml，优先用pip install .而非requirements.txt，它更准地表达依赖树
venv + pip 无法还原 conda 环境？
是的，conda 和 venv 是两套隔离机制：conda 管理 Python 解释器本身、C 库、非 Python 包（如 R、ffmpeg），而 venv 只管 Python 包。跨工具迁移时，解释器版本、ABI 兼容性、动态链接路径全可能断掉。
- 如果原环境是 conda 创建的，别试图用
venv克隆——先用conda env export > environment.yml，新机器用conda env create -f environment.yml -
environment.yml中若含pip:块，确保新机器 conda 版本 ≥ 4.6（否则忽略 pip 部分） - 导出时加
--from-history可只保留你显式conda install的包，避免锁死 build 数字（如python=3.9.16=h900ac7f_0_cpython）
requirements.txt 里该不该写版本号？
写，但要分层：主依赖写兼容范围（如 requests>=2.28.0,），底层工具类包（如 <code>setuptools、wheel）可固定（setuptools==65.5.1），绝对不要写 == 锁死所有包——这会让迁移变成版本解谜游戏。
- 用
pip-compile（来自pip-tools）从requirements.in生成带哈希的requirements.txt，兼顾可复现与灵活性 - 避免
pip freeze直接输出到生产用requirements.txt，它会把pkg-resources==0.0.0这类虚拟环境占位符也写进去 - Windows 和 macOS 上
pywin32、pyobjc这类平台相关包，要用环境标记过滤：pywin32==305; platform_system=="Windows"
打包整个 venv 文件夹行不行？
技术上可以，但极不推荐。虚拟环境包含绝对路径（如 /home/user/venv/bin/python）、硬编码的 Python 解释器 ABI 标识、以及平台特定的 .so/.dll，复制到另一台机器大概率 ImportError: cannot open shared object file 或直接启动失败。
立即学习“Python免费学习笔记（深入）”；
- 唯一能“拷文件夹”成功的场景：同 OS、同架构、同 Python 小版本（如都是 macOS ARM64 + Python 3.11.5）、且没用任何 C 扩展包
- 如果真想离线传，打包的是
requirements.txt+pyproject.toml+setup.py（如有）+wheels/目录（用pip wheel --no-deps --wheel-dir wheels/ -r requirements.txt预下载） - 注意
wheel文件名里的cp311-cp311-macosx_12_0_arm64.whl这种标签，换平台就失效
最麻烦的永远不是怎么打包，而是搞清哪些依赖其实是隐式绑定操作系统或硬件的——比如 onnxruntime 的 CPU/GPU 版本不能混用，psycopg2 在 M1 Mac 上必须用 psycopg2-binary，这些细节不会出现在 requirements.txt 里，得靠迁移时实际跑一下关键 import 才暴露。
