uv批量升级依赖的唯一可靠路径是uv lock --upgrade-all && uv sync，必须先更新锁文件再同步环境，不可用uv add --upgrade（该参数不存在），否则破坏一致性。
uv 批量升级依赖不是靠“一次命令扫所有目录”，而是靠 uv lock --upgrade-all + 多项目并行执行的组合策略。直接用 uv add --upgrade 或类似 pip 的全局 upgrade 命令不存在，强行遍历目录调 pip install --upgrade 会绕过 uv.lock，破坏一致性。
为什么不能用 uv add --upgrade 批量升级
uv 没有 --upgrade 参数支持 uv add；它坚持“声明式依赖管理”：升级必须先改锁文件（uv.lock），再同步环境。直接升级包而不更新锁文件，会导致下次 uv sync 时回退、CI 构建不一致、团队成员环境漂移。常见错误现象是：本地跑通了，CI 报 Package 'requests' not found in lockfile。
uv lock --upgrade-all && uv sync 是唯一可靠路径
这是 uv 官方推荐且唯一保证跨平台一致性的升级流程。关键点在于：
- uv lock --upgrade-all 重算整个依赖图，尊重 pyproject.toml 中的版本约束（如 "requests>=2.28"），同时避免冲突；
- uv sync 只安装 uv.lock 里锁定的版本，不查 PyPI，极快且可重现；
- 二者必须成对使用，顺序不可颠倒。
示例操作：
cd /path/to/project-a uv lock --upgrade-all && uv sync
注意：uv lock 默认只读取 pyproject.toml，不会处理 requirements.txt —— 如果项目还在用旧格式，得先迁移到 uv add -r requirements.txt 再开始锁文件管理。
真正高效的批量升级：用 shell 脚本并行执行
手动 cd 进每个项目太慢。推荐写一个轻量脚本，利用 shell 的并行能力（&）和 uv 的无状态设计（无需提前激活环境）：
Python uv 0.12.20 是 Astral 开发的 Python 包与项目管理工具，支持依赖解析、虚拟环境、Python 版本及项目锁文件管理。本下载包适用于 Windows x64，解压后可使用 uv 命令。
- 确保每个目标项目根目录下都有
pyproject.toml和已生成的uv.lock（首次运行可用uv lock初始化） - 脚本中不要用
cd && cmd链式写法，改用pushd/popd或直接指定工作目录（uv --cwd /path lock...）更健壮 - 加上超时和错误检查，避免某个项目卡住拖垮全部
简版脚本示例（macOS/Linux）：
#!/bin/bash
PROJECTS=("./proj1" "./proj2" "./proj3")
for dir in "${PROJECTS[@]}"; do
(cd "$dir" && uv lock --upgrade-all && uv sync) &
done
waitWindows PowerShell 用户需改用 Start-Process 或分批调用，因 & 行为不同；且注意路径分隔符和空格转义。
容易被忽略的细节：缓存、镜像源和 Python 版本锁定
批量升级快不快，不只看命令本身，更取决于三件事：
-
uv cache info显示缓存命中率；首次批量升级前建议uv cache prune清无效项，再uv python install 3.12预装常用 Python 版本，避免每个项目重复下载解释器 - 若公司内网或国内开发，务必在
pyproject.toml里配好镜像源，否则每个项目单独连 PyPI 会触发限流，批量时尤其明显 -
.python-version文件或requires-python = ">=3.11"必须明确；uv 不会自动降级 Python，如果某项目声明requires-python = ">=3.12"，但机器只装了 3.11，uv lock会直接失败，而不是跳过
最后提醒：批量升级后，别忘了跑 uv run pytest 或对应测试命令——uv 能保证依赖装对，但不能保证新版本 API 兼容。这点永远要人来把关。
