uv通过pyproject.toml中[build-system]段指定的build-backend模块路径自动识别并调用自定义构建后端，按需拉取、缓存并执行其build_wheel等方法，构建依赖完整记录在uv.lock中。
uv如何识别并调用自定义构建后端
uv 默认使用 build（PEP 517 兼容构建器）作为构建后端，但它本身不实现构建逻辑，而是委托给项目中声明的 build-backend。只要你的 pyproject.toml 正确指定了后端（如 setuptools.build_meta、hatchling.build 或自定义模块），uv 就会自动加载并调用它。
关键点在于：uv 不要求你手动安装构建工具，它会在需要时按需拉取并缓存对应版本的构建后端依赖——前提是该后端已发布在 PyPI 上且满足 requires 声明。
-
build-backend必须是可导入的 Python 模块路径，不能是本地脚本路径（如./my_backend.py） - 若后端依赖未在
requires中声明完整（例如漏了tomli），uv 构建时会报ModuleNotFoundError，而非静默跳过 - uv 不支持通过环境变量或命令行参数覆盖
build-backend，修改必须落在pyproject.toml的[build-system]段内
uv build --installer=... 能否绕过标准构建流程
不能。uv build 的 --installer 参数仅控制「分发包安装方式」（比如用 pip 还是 uv 安装生成的 wheel），它不干预源码构建阶段。构建动作本身始终由 build-backend 驱动，uv 只负责调度和隔离执行环境。
如果你希望跳过 PEP 517 构建（比如直接打包已编译的二进制），应改用 uv export + 手动构造 wheel 目录结构，或配合 uv pip install --find-links 指向预构建的 wheel 文件。
立即学习“Python免费学习笔记（深入）”；
- 试图用
--installer=pip让 uv 调用 pip 来构建，会失败：pip 无权替代 build-backend -
uv build --no-isolation也不推荐：它禁用构建隔离，可能导致全局 site-packages 干扰构建结果，且不解决自定义后端缺失问题 - 真正可控的“自定义构建”入口是编写符合 PEP 517 的
build-backend，并确保其build_wheel()等方法返回标准 wheel 文件
自定义构建后端在 uv.lock 中如何体现
uv 会把构建后端及其全部传递依赖（包括 requires 中声明的间接依赖）写入 uv.lock，但不会记录构建过程产生的中间产物（如 build/ 目录）。这意味着：锁文件能保证「每次构建使用的后端版本一致」，但无法保证构建输出完全比特级相同——除非后端自身是确定性的（如 hatchling 默认启用 reproducible=True）。
- 若后端代码托管在私有 Git 仓库，需用 PEP 508 URL 形式声明：
"my-backend @ git+https://git.example.com/my/backend.git@v1.2" - uv 不解析
setup.py或setup.cfg，所以基于这些的老式构建流程在 uv 下不可用 - 锁文件中构建后端条目带
source = "registry"或"git"标记，便于审计来源
PyCharm 或 CI 中如何验证自定义构建后端生效
最直接的方式是运行 uv build --verbose，观察日志中是否出现类似 Using build backend my_custom_backend 的提示。如果只看到 Using build backend setuptools.build_meta，说明 pyproject.toml 未被正确读取，或文件位置不在当前工作目录根路径。
- CI 中常见坑：工作目录错误（如在子目录执行
uv build），导致 uv 找不到pyproject.toml - PyCharm 终端需确认是否继承了正确的
PYTHONPATH和UV_CACHE_DIR；否则可能复用旧缓存，跳过新后端安装 - 调试建议：临时在自定义后端的
build_wheel()函数开头加print("BUILDING WITH MY BACKEND")，再运行uv build -v看输出
requires 安装，但不会帮你检查这些依赖是否存在冲突或版本漂移。一旦后端内部用了硬编码的 importlib.metadata.version("rich") 且没声明 rich 在 requires 中，uv 就会在构建中途崩溃。 
