升到 NumPy 2 后报 _ARRAY_API not found，定位出错的扩展包

升级 NumPy 后，执行 import pandas 就打印 AttributeError: _ARRAY_API not found，前面还出现“使用 NumPy 1.x 编译的模块不能在 NumPy 2 中运行”的提示。先沿 traceback 找到具体的二进制扩展，不要只看最外层的 pandas 导入语句。

这组信息指向依赖包的 C-API 或 ABI 与运行时 NumPy 不兼容。本文处理的是升级到 NumPy 2 后仍加载旧编译产物的分支；缺少动态库、Python 路径错误或 CPU 指令崩溃，需要根据各自的异常另查。

从栈尾往回找第一个 NumPy 之外的包

保存完整 stderr 和进程退出状态。从栈末向上读，找出进入 NumPy 之前的消费方，例如 numexpr、bottleneck，或项目自己的 .so、.pyd 扩展。日志中可能有两段相似 traceback，它们不一定指向同一个包。

在失败进程使用的解释器中核对环境，别用终端里另一套 pip 代替：

python -c 'import sys; print(sys.executable)'
python -m pip show numpy pandas numexpr bottleneck
python -m pip check

解释器应与原启动入口一致。pip show 提供安装位置和版本，即使某个包已经无法 import，也仍有机会读取它的发行信息。pip check 通过并不能验证扩展用了兼容的 NumPy ABI，不能据此排除这条故障路径。

例如 pandas 2.2.2 的官方 wheel 已支持 NumPy 1.x 和 2.x，但被它导入的旧可选扩展仍可能不兼容。只升级 pandas，或者仅因为它满足最低依赖版本就认定整套环境兼容，都不够。

更换的是已识别的兼容产物

若扩展包有支持目标 NumPy、Python 和平台的发行版，按项目的依赖策略升级那个包，保留其他约束并核对锁文件差异。必须确认目标环境有可用 wheel，或者具备该项目要求的源码构建条件；“版本号更大”并不自行证明当前架构和 Python 组合可安装。

不要不加区分地升级所有科学计算包。多个扩展分别失败时，需要逐个核对兼容组合，然后运行应用原有的相关功能。一个包的导入恢复，不证明另一个包或者后续计算路径也已恢复。

若暂时没有合适的扩展产物，可评估在这个项目中保留兼容的 NumPy 1.x 组合。numpy<2 是版本范围示例，不是对所有 Python 的可安装保证；同时检查其他依赖的上下界、目标 Python 和平台。使用现有锁定流程记录审定版本，避免把一次降级扩散成系统全局变更。

自己维护的扩展需要按 NumPy 2 的构建要求重新生成产物，并检查承诺支持的运行版本。重复安装同一个旧 wheel 不会改掉它编译时使用的 ABI，复制其他机器的二进制文件也不能代替合适的构建。

打印 traceback 与应用退出要分开判断

NumPy 的兼容检查可能主动向 stderr 打印说明和调用栈。上层代码如果捕获可选依赖的导入异常，程序可能继续运行。因此，看到这段日志不能直接断言 pandas 已完全不可用；反过来，进程没有退出也不表示应用所需的加速或计算功能正常。

检查退出状态、真正需要的功能以及后续错误，确认原任务有没有完成。不要为了消除日志就关闭 stderr，或者把未加载的扩展伪装成可用。可选依赖是否可以移除，应由实际功能和项目依赖约定决定。

修改前保存完整依赖记录和运行配置。在独立环境验证原导入、代表性运算和原业务入口，再决定切换。回退需要恢复整套兼容依赖及相应产物；只把 NumPy 版本文本改回去，不会自动替换已经安装的扩展。

如果 NumPy 和 pandas 已经能正常运行，错误出现在数据库写入时的 can't adapt type 'numpy.int64'，则应查SQL 参数边界的标量转换，它与这里的导入兼容问题不同。