uv 通过 UV_NO_BINARY 环境变量控制源码构建，而非命令行参数；需配合系统环境变量（如 CC、LIBRARY_PATH）和缓存清理（uv cache clean）确保编译行为生效。
uv add 时如何控制包的编译行为
uv 默认会复用 pip 的构建逻辑，但不直接暴露 --no-binary 或 --force-recompile 这类 pip 原生参数。它通过环境变量和底层构建策略间接控制编译，而不是在 uv add 命令里加开关。
-
UV_NO_BINARY环境变量可全局禁用二进制分发包（.whl），强制源码构建：运行UV_NO_BINARY=1 uv add numpy会跳过所有预编译 wheel，改用本地编译 -
UV_BUILD_OPTIONS不被 uv 支持 —— 别尝试设这个，它会被忽略 - 若需传递具体编译参数（如
--rustc-args或CC=clang），必须通过系统级环境变量前置设置，例如：CC=clang UV_NO_BINARY=1 uv add cryptography - uv 对
pyproject.toml中的[build-system]和[project.optional-dependencies]完全尊重，但不会修改构建过程本身；它只决定“用哪个版本”和“从哪下”，不干预“怎么编”
为什么 uv 没有 --no-binary 这类命令行选项
uv 的设计目标是“默认安全、一致、快”，而编译选项属于高度平台/项目/用户定制化行为。它把这类控制权让渡给更底层的机制（环境变量 + 构建工具链），避免在 CLI 层堆积易混淆的标志位。
Python uv 0.12.20
下载
Python uv 0.12.20 是 Astral 开发的 Python 包与项目管理工具，支持依赖解析、虚拟环境、Python 版本及项目锁文件管理。本下载包适用于 Windows x64，解压后可使用 uv 命令。
- pip 的
--no-binary是历史包袱产物，uv 选择用UV_NO_BINARY统一控制所有依赖（包括递归子依赖），更可靠 - 当你看到
Building cryptography from source日志，说明UV_NO_BINARY已生效；若没日志或提示Using cached ... .whl，说明变量未正确设置或拼写错误（注意大小写） - macOS 上 M1/M2 芯片用户常遇到
cryptography或numpy编译失败，此时除了UV_NO_BINARY=1，还需确保LIBRARY_PATH和PKG_CONFIG_PATH指向 Homebrew 的 openssl 路径
实际场景：交叉编译或嵌入式目标需要源码构建
uv 本身不支持交叉编译，但它能配合 setuptools 或 meson 的构建后端完成目标平台适配 —— 关键在于你项目的 pyproject.toml 是否声明了正确的构建要求。
- 确保
[build-system]指定了兼容的构建器，例如：requires = ["setuptools>=61.0", "wheel"]，否则 uv 可能 fallback 到不支持的旧逻辑 - 若依赖包使用
rust（如tokenizers），需提前安装cargo并确保$PATH可见；uv 不会帮你装 rust 工具链 - 想跳过某包的编译（比如只用纯 Python 子模块），只能靠包自身是否提供
--no-cython类开关 —— uv 不介入这个层级，那是包作者在setup.py或pyproject.toml里定义的行为
容易被忽略的坑：缓存污染导致编译行为不一致
uv 的全局构建缓存默认启用，且按 hash 区分二进制/源码构建结果。但如果你先用 UV_NO_BINARY=0 装过 numpy，再切到 UV_NO_BINARY=1，uv 可能仍复用旧缓存 —— 因为它认为“同一版本+同一源码”的构建结果可复用，不管是否禁用了 binary。
- 遇到编译行为未按预期切换，先清缓存：
uv cache clean - 临时绕过缓存测试编译逻辑：
UV_NO_BINARY=1 uv add --no-cache numpy - 注意：清除缓存会影响所有项目，不是按 project 隔离的；生产环境中慎用
uv cache clean
