NumPy 2.0未增加运行时标准库依赖，但强化了与typing、collections.abc、memoryview等标准库模块的语义绑定；类型注解需显式导入NDArray，Windows整数默认改为np.intp以匹配LLP64，C扩展须适配PEP 3118 memoryview协议。
numpy 2.0 并没有改变对 Python 标准库 的依赖范围——它仍只依赖 sys、os、math 等内置模块，不引入新标准库依赖。所谓“依赖变化”，实际是 构建时工具链和类型检查生态的耦合增强，而非运行时标准库调用变更。
为什么有人觉得“依赖变了”？
根本原因在于：NumPy 2.0 把原本隐式、松散的类型契约，显式绑定到了 Python 3.12+ 的类型系统规范（PEP 698）上。这不是加了新 import，而是让 numpy.typing 模块的行为深度依赖标准库的 typing 和 collections.abc 实现细节。
NDArray 注解必须显式导入，否则类型检查直接失效
在 NumPy 2.0 中，np.ndarray 不再是 typing.Generic 子类，因此：
-
def f(x: np.ndarray) -> np.ndarray:→ mypy/pyright 直接报错，不是警告 - 必须写
from numpy.typing import NDArray，再用NDArray[np.float64] - 而
NDArray内部大量使用typing.Sequence、typing.SupportsIndex等——这些在 Python 3.12 中有语义调整，旧版本标准库无法提供等价行为
Windows 上默认整数变更暴露了 stdlib 与平台 ABI 的隐含绑定
NumPy 2.0 在 Windows 64 位系统上将默认整数从 np.int_（映射 C long）改为 np.intp（匹配 Windows LLP64 模型）。这导致：
立即学习“Python免费学习笔记（深入）”；
- 与 ctypes、
array.array('l')或标准库struct.unpack()交互时，np.intp可能不再自动对应'l' - 不是 NumPy “依赖”了 struct，而是它现在更严格遵循 Python 标准库在该平台上的整数宽度定义
C API 移除旧缓冲区接口，迫使扩展依赖 stdlib 的 memoryview 协议
旧函数如 PyArray_GetBuffer 被移除后，C 扩展必须改用 PyArray_GetArrayParamsFromObject + PyArray_FromAny。这套新路径要求输入对象支持标准库 memoryview 协议——这意味着你传入的任何自定义 buffer 类，必须实现 __buffer__，且其行为需与 memoryview 的 PEP 3118 规范一致。
真正容易被忽略的点是：这些变化不报 ImportError，但会在类型检查、跨平台打包或 C 扩展加载时静默失败。你得主动验证 from numpy.typing import NDArray 是否能 import，以及 memoryview(np.array([1])) 是否能构造成功——而不是等 CI 跑到 Windows 上才崩。
