I
Member
"本地能跑，线上就挂"，十次有八次是依赖环境不一致。分享下我们现在的依赖管理流程：
1. 每个项目独立 venv：别再用系统 Python 装包了。python -m venv .venv 一个项目一个环境，激活脚本写进项目 README，新人照着做就行。
2. requirements 分层：requirements.in 只写直接依赖（比如 django、celery），用 pip-tools 编译出带完整版本锁定的 requirements.txt。升级依赖时改 .in 文件重新编译，而不是手改版本号。
3. 生产环境用锁定文件安装：部署脚本里 pip install -r requirements.txt --no-deps，配合 hash 校验，确保线上装的和测试时一字不差。
4. Python 小版本也要锁：3.10 和 3.11 的某些 C 扩展行为不一样，Docker 基础镜像的 tag 写死具体版本，别用 latest。
5. 定期跑 pip-audit：依赖锁死了不等于安全了，每月跑一次漏洞扫描，有 CVE 的包按计划升级。
这套流程跑下来，"在我机器上明明是好的"这类问题基本绝迹。大家现在用 poetry 还是 pip-tools？poetry 的 lock 文件在多人协作时冲突问题怎么处理的？
1. 每个项目独立 venv：别再用系统 Python 装包了。python -m venv .venv 一个项目一个环境，激活脚本写进项目 README，新人照着做就行。
2. requirements 分层：requirements.in 只写直接依赖（比如 django、celery），用 pip-tools 编译出带完整版本锁定的 requirements.txt。升级依赖时改 .in 文件重新编译，而不是手改版本号。
3. 生产环境用锁定文件安装：部署脚本里 pip install -r requirements.txt --no-deps，配合 hash 校验，确保线上装的和测试时一字不差。
4. Python 小版本也要锁：3.10 和 3.11 的某些 C 扩展行为不一样，Docker 基础镜像的 tag 写死具体版本，别用 latest。
5. 定期跑 pip-audit：依赖锁死了不等于安全了，每月跑一次漏洞扫描，有 CVE 的包按计划升级。
这套流程跑下来，"在我机器上明明是好的"这类问题基本绝迹。大家现在用 poetry 还是 pip-tools？poetry 的 lock 文件在多人协作时冲突问题怎么处理的？