to_numpy() 是官方推荐的零拷贝路径，values 已不推荐；to_numpy(copy=false) 复用内存，而 values 遇 nullable 类型会隐式转 object dtype 并触发拷贝。
to_numpy() 与 values 的性能差异
values 是 Pandas 旧版惯用写法，但它返回的是一个可能带类型转换开销的 ndarray 视图，且在 Pandas 2.0 中已明确不推荐；to_numpy() 才是官方推荐的零拷贝路径。关键区别在于：to_numpy(copy=False) 能真正复用底层内存，而 values 在遇到 nullable 类型（如 Int64[pyarrow] 或 string[pyarrow]）时会强制转为 object dtype，触发隐式拷贝和类型降级。
常见错误现象：df['col'].values.dtype 返回 object，但 df['col'].to_numpy().dtype 仍是 int64 或 string —— 这说明 values 已悄悄把数据“软化”了。
- 始终优先用
to_numpy(copy=False)，尤其在循环或高频计算中 - 若需确保不修改原 DataFrame，加
copy=True，但会多一次内存分配 - 对 PyArrow 后端的列，
to_numpy()默认返回 NumPy 兼容类型（如str→object），如需保留字符串语义，应配合dtype=str显式指定
PyArrow 后端启用后与 NumPy 交互的隐式转换开销
Pandas 2.0 支持 pyarrow 作为 dtype backend，但 NumPy 并不原生理解 int64[pyarrow] 这类类型。一旦你调用 to_numpy()、np.array() 或任何接受 ndarray 的函数（如 scipy.stats），Pandas 就必须执行一次完整的数据拷贝 + 类型映射（例如将 Arrow string 列转为 Python object 数组，再转为 NumPy Uxx unicode 数组）。
这个过程不是轻量视图切换，而是逐元素解包 + 内存重分配，尤其在字符串列上损耗极大——测试显示百万行字符串列的 to_numpy() 耗时可比等价 NumPy 原生数组慢 5–8 倍。
- 避免在 PyArrow backend 下频繁进出 NumPy：先批量处理完 Pandas 逻辑，再一次性转出
- 读取 CSV 时若后续全用 NumPy 计算，直接用
pd.read_csv(..., engine='pyarrow')+to_numpy()不一定更快；不如改用np.loadtxt()或polars.read_csv().to_numpy() - 检查类型是否“干净”：
df.dtypes中出现[pyarrow]后缀，就意味每次to_numpy()都有潜在转换成本
广播运算中因索引对齐引发的额外开销
NumPy 的广播（broadcasting）是纯内存操作，无索引参与；而 Pandas 的 Series / DataFrame 运算默认按 index 对齐。当你把 Pandas 结构转成 NumPy 数组后做广播（比如 arr - arr.mean(axis=0)），看似高效，但如果原始数据是从 Pandas 衍生而来且 index 未重置，容易误以为“对齐已完成”，实则丢失了业务维度信息，导致结果错位。
更隐蔽的问题是：如果在 Pandas 环境中混合使用 df.values 和 df.iloc，index 顺序可能不一致（例如 df.sort_values() 后未 reset_index()），此时 .values 返回的仍是原顺序数组，但 .iloc 按位置访问——两者物理顺序脱节，结果不可复现。
- 做广播前，确认数组来自同一逻辑视图：用
df.to_numpy(copy=False)+df.index.equals(other_df.index)校验 - 若需保留索引语义，别急着转 NumPy；用
df.sub(df.mean(), axis=1)更安全 - 对齐开销本身不体现在 NumPy 时间里，但会拖慢整体 pipeline——因为你要额外花时间 debug 错位结果
dtype 不一致导致的 silent 拷贝和精度损失
NumPy 要求同质类型，Pandas 却支持 nullable int（Int64）、string（string）、boolean（boolean）等扩展类型。当你对含 pd.NA 的列调用 to_numpy()，默认会转成 float64（int 列）或 object（string 列），既浪费内存又丢失类型信息。更麻烦的是，这种转换不报错，只静默发生。
例如：df['x'] = pd.array([1, 2, pd.NA], dtype='Int64')，执行 df['x'].to_numpy() 得到 array([ 1., 2., nan]) —— 整数列变浮点，且 pd.NA 变成了 np.nan，后续传给需要整数输入的 C 扩展库（如 numba.jit）会直接崩溃。
- 显式声明目标 dtype：
df['x'].to_numpy(dtype=np.int64, na_value=-1) - 对含
pd.NA的列，优先用df['x'].array（返回 ExtensionArray）而非急着转 NumPy - 用
df.convert_dtypes()统一为扩展类型后再决定是否导出，避免混用Int64和int64
实际中最容易被忽略的，是 PyArrow backend 下的字符串列与 NumPy 的交互——它不像数值列那样能“假装兼容”，每一次 to_numpy() 都是实打实的逐元素 decode，且无法通过 copy=False 规避。如果你的 workflow 依赖大量字符串正则、切片或拼接，又同时想用 Pandas 2.0 的新特性，得提前把这部分逻辑留在 Pandas 层完成，而不是指望转成 NumPy 后加速。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
