pyproject.toml 中 build-backend 应与所选工具严格匹配：hatchling 需 "hatchling.build"，flit_core 需 "flit_core.buildapi"，setuptools 64.0+ 默认即 "setuptools.build_meta"；硬写死可能覆盖轻量构建逻辑或触发降级，且必须配全 requires 和 build-backend。
为什么 pyproject.toml 里写 build-backend = "setuptools.build_meta" 不一定对
因为默认值已变，盲目写死反而可能锁死行为或触发意外降级。PEP 621 后，setuptools 自身在 64.0+ 版本中把 build-backend 默认设为 setuptools.build_meta；但如果你用的是 hatchling 或 flit_core，硬写这个会覆盖原本更轻量的构建逻辑。
- 检查当前项目是否声明了
[project]段——有则优先走 PEP 621 元数据，此时build-backend应与所选工具一致 - 若用
hatchling，必须显式写build-backend = "hatchling.build"，否则pip build可能 fallback 到旧版setuptools -
flit_core要求build-backend = "flit_core.buildapi"，漏掉.buildapi后缀会报ModuleNotFoundError: No module named 'flit_core.build'
pip build 报错 Backend operation failed: AttributeError: 'module' object has no attribute 'build_wheel'
这是典型的构建后端模块导出不全问题：你指定的模块没实现标准接口函数。PEP 517 规定后端必须提供 build_wheel、build_sdist 等函数，但有些自定义 backend 或老版本只实现了部分。
- 先运行
python -c "import hatchling.build; print(hasattr(hatchling.build, 'build_wheel'))"验证函数是否存在 - 如果用自己写的 backend，确保顶层模块里直接定义了
build_wheel()函数（不能只在子模块里，也不能靠__all__导出） - 某些 IDE 或打包脚本会自动插入
setup.pyfallback，但 PEP 517 模式下它被完全忽略——别指望它救场
想用 setuptools 但禁用 setup.py，怎么配才不冲突
可以，但得彻底断掉旧路径。只要 pyproject.toml 存在且含 [build-system]，pip 就不会读 setup.py；但如果你在项目根目录留着空的或残留的 setup.py，某些 CI 工具或本地 python setup.py 手动调用仍可能误触发。
-
[build-system]必须包含requires和build-backend，缺一不可；只写build-backend会导致pip不知道要装啥依赖 - 若用
setuptools>=64.0，requires = ["setuptools>=64.0", "wheel"]就够，不用再加setuptools-scm等插件——它们属于[project]配置范畴 - 删掉
setup.py，连同setup.cfg——这两者和 PEP 621 元数据共存时，setuptools会尝试合并，结果常是字段覆盖或静默忽略
自定义 backend 性能差、反复重编译，怎么定位瓶颈
根本原因是构建后端每次调用都启动新 Python 进程加载模块，而你的 backend 如果在模块顶层做了重操作（比如扫描整个 src/ 目录、解析大量配置文件），就会被重复执行。
立即学习“Python免费学习笔记（深入）”；
- 把耗时初始化移到
build_wheel()函数内部，而不是模块级；或者用functools.lru_cache缓存结果（注意：跨进程不共享） - 用
pip build --no-isolation测试——它跳过虚拟环境创建，能快速判断慢是不是来自依赖安装环节 - 检查是否在
build-wheel中调用了subprocess.run(['python', 'setup.py'])类逻辑：这等于嵌套调用，不仅慢，还破坏 PEP 517 隔离性
真正难处理的是构建过程依赖外部状态（如 Git 提交信息、环境变量）又没做缓存，这种情况下每次 build 都得重新抓取，没法靠改 backend 代码省掉。
