Hatchling 1.32.3 构建时报 Too few arguments，先看 BuildHookInterface

安装项目时，PDM 或其他构建前端报 BuildError，堆栈最后停在自定义 hook 的类定义上：

TypeError: Too few arguments for <class 'hatchling.builders.hooks.plugin.interface.BuildHookInterface'>; actual 1, expected at least 2

若刚解析到 Hatchling 1.32.3，而插件继承了 BuildHookInterface[Any]，应先核对构建后端版本。这一版把接口的泛型参数从一个增加到两个，旧插件会在导入阶段失败，甚至还没有进入构建方法。1.32.4 已撤回这项类型变更。

错误发生在导入时，不是类型检查任务里

下面是旧插件可能采用的继承形式，仅展示触发位置：

from typing import Any
from hatchling.builders.hooks.plugin.interface import BuildHookInterface


class CustomBuildHook(BuildHookInterface[Any]):
    PLUGIN_NAME = "custom"

基类表达式要在定义这个类时求值。即使项目没运行 mypy，运行时也会检查泛型实参数量。from __future__ import annotations 不会把类的基类表达式变成延迟求值的类型注解，因此给文件加这一行不能消除该错误。

对照失败日志里的实际 Hatchling 版本、插件版本以及具体基类。只有末尾明确指向这个接口和 actual 1, expected at least 2，才适用这里的处理。普通函数参数不足、其他泛型类报错，不应一起归到这次回归。

修改构建环境真正使用的约束

优先让隔离构建环境采用包含修复的 1.32.4。若项目希望先固定这次修复版本，可以在原有构建配置中调整 Hatchling 那一项：

[build-system]
requires = ["hatchling==1.32.4"]
build-backend = "hatchling.build"

片段假设项目本来就使用 Hatchling，且没有其他构建依赖。真实项目应保留 requires 中原有的 hook 包和必要工具，只修改后端约束；不要用这两行覆盖完整列表。若约束由统一的构建锁定流程提供，应修改那个实际入口，并检查插件声明的版本范围是否允许 1.32.4。

只升级运行 PDM、pip 或 Hatch 的外层环境，未必改变隔离环境里解析到的后端。查看新构建日志中实际安装的版本，比外层执行一次版本查询更有用。

不要为适配 1.32.3，把所有插件统一改成 BuildHookInterface[Any, Any]。这样的写法在原有单参数接口下又会失败，而且 1.32.4 已恢复旧接口。确实需要跨版本维护插件时，应明确插件支持范围并分别验证，而不是让一处临时修改同时承担所有版本兼容。

构建成功后，还要确认 hook 确实执行

保存改动前的构建约束、插件版本和产物。按项目现有流程在干净、隔离的构建环境重新生成 wheel 与 sdist，确认导入错误消失，并检查 hook 应当生成或修改的文件是否实际进入产物。仅看到 wheel 文件出现，不能证明自定义 hook 的结果正确。

若插件还有其他兼容问题，可以恢复此前已知可用的完整构建组合，并保留当前失败记录；不要只降级外层安装器。已经生成或发布的包不会随约束回退而自动替换，需要按原发行流程确认该用哪一份产物。