PyEMD因NumPy 2.0移除find_common_type而构建失败，需用np.result_type替代并升级构建工具链及依赖版本。
NumPy 2.0移除了find_common_type导致PyEMD等包构建中断
PyEMD 1.6.3及更早版本在CEEMDAN.py和EMD.py中直接调用numpy.find_common_type，而该函数在NumPy 2.0中被彻底移除。编译或导入时会立即报AttributeError: module 'numpy' has no attribute 'find_common_type'，不是警告，是硬性失败。
这不是“兼容性警告”，而是API断裂：NumPy 2.0用np.result_type和np.promote_types替代了旧逻辑，但老包没重写这部分代码。
- 检查是否命中：运行
python -c "import numpy; print(hasattr(numpy, 'find_common_type'))"，输出False即已升级到2.0+ - 影响范围明确：PyEMD
- 不能靠降级NumPy绕过：若其他依赖（如torchcam）强制要求
numpy，则必须统一协调版本约束
pip install时触发源码编译却找不到numpy/arrayobject.h
当你装一个依赖NumPy C API的包（比如自定义Cython扩展、torchcam、或从源码装numpy本身），而当前环境中只有运行时wheel、没有开发头文件，就会卡在预处理阶段，报fatal error: numpy/arrayobject.h: No such file or directory。
根本原因不是“没装NumPy”，而是pip install试图从源码构建时，编译器找不到C API头文件路径。NumPy wheel默认不带core/include目录，只有通过build_ext或meson-python参与构建的流程才需要它。
- 验证头文件是否存在：
python -c "import numpy; print(numpy.get_include())"，输出路径下应有numpy/arrayobject.h - conda用户注意：
conda install numpy通常自带头文件；pip用户若用--only-binary=all跳过编译，就绕不开这个检查 - Windows上尤其容易漏掉：即使
numpy能import，numpy.get_include()返回的路径也可能指向只读缓存区，需手动补全环境变量NPY_INCLUDE_PATH
torchcam安装失败时看到Could not parse vswhere.exe output
这是Windows上典型的MSVC工具链错配信号。日志里出现vswhere.exe失败 + Meson构建中断，说明numpy源码编译尝试调用Visual Studio定位脚本，但系统中要么没装Build Tools，要么装了但vswhere返回空或格式异常（常见于VS 2022 Build Tools安装不完整、或PATH里混入旧版VS路径）。
librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。
不是torchcam的问题，也不是numpy的问题，而是构建链路在找编译器时断了——Meson默认依赖vswhere查MSVC，而它查不到可用实例就直接退出。
- 快速验证：
vswhere -version应输出类似3.1.12+g570e145a98；若报command not found，说明没装Build Tools或未初始化PATH - 别指望PyCharm自动修复：PyCharm的Terminal不会自动加载
vcvars64.bat，必须手动执行或在终端启动前设置好环境 - 最稳解法：
pip install --only-binary=torchcam,torch,numpy torchcam，强制全部走wheel，避开所有本地编译环节
为什么pip install numpy>=2.0.0后反而触发更多编译错误
因为NumPy 2.0开始全面转向Meson构建系统，而很多旧项目（尤其是用setup.py或老版pyproject.toml）还没适配。当你执行pip install且目标包声明了requires = ["numpy>=2.0"]，pip会拉取numpy-2.0.0.tar.gz并尝试用Meson构建——但你的环境可能缺meson-python、scikit-build-core，或Meson本身版本太低（需≥1.2.0）。
典型表现是Preparing metadata (pyproject.toml) ... error，末尾报Unknown compiler(s): [['cl'], ['gcc']]，其实是Meson没找到可用backend，不是真的没编译器。
- 临时规避：
pip install --no-build-isolation --no-deps numpy==2.0.0，跳过隔离环境，复用当前已装的构建工具 - 长期建议：检查项目
pyproject.toml中[build-system]段，确保requires包含"meson-python>=0.15"等必要项 - 最易忽略的一点：升级NumPy后，必须同步升级
pip到≥24.0、setuptools≥68.0，否则PEP 660和动态元数据支持会失效
关键不在“升了NumPy”，而在“升了之后整个构建链路的隐式假设全变了”——头文件位置、C API可用性、构建工具链、元数据生成方式，全都换了底。任何一个环节没对齐，错误就立刻暴露。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
