优先用.to_numpy()，它比.values更明确、更安全，官方推荐且类型保真；.values已不推荐，易导致dtype降级，且返回视图或副本行为不固定，可能意外修改原DataFrame。
直接用 .values 还是 .to_numpy()？
优先用 .to_numpy()。它比 .values 更明确、更安全，且在 pandas 1.0+ 中是官方推荐方式。.values 返回的是视图或副本的行为不固定（取决于数据类型和内存连续性），而 .to_numpy() 默认返回副本，语义清晰，避免意外的原地修改。
常见错误：用 df.values 后直接修改数组，结果意外影响原始 DataFrame（某些情况下会，尤其当数据是连续 int/float 且未经过 dtype 转换时）；.to_numpy() 则彻底切断引用关系。
-
.to_numpy()支持dtype参数强制转换，比如df.to_numpy(dtype=np.float32) -
.to_numpy(copy=False)可尝试返回视图（仅当底层内存连续且 dtype 兼容），但需自行承担风险 - 含缺失值（
pd.NA或np.nan）的列，.to_numpy()会自动升为object或float64，注意 dtype 意外变化
处理含混合类型或缺失值的 DataFrame
混合类型（如一列 str、一列 int）的 DataFrame 调用 .to_numpy() 会返回 object dtype 数组，后续无法向量化运算，性能暴跌。
解决思路不是“硬转”，而是提前筛选或拆分：
立即学习“Python免费学习笔记（深入）”；
- 只取数值列：
df.select_dtypes(include=np.number).to_numpy() - 对特定列显式转换：
df[['col_a', 'col_b']].astype(np.float32).to_numpy() - 含
pd.NA的整型列（如Int64）必须先 fillna 或转为 float：df['col'].fillna(0).to_numpy()，否则.to_numpy()会报错或返回 object
别依赖 .values “自动处理”混合类型——它只是把所有东西塞进 object 数组，掩盖了类型问题。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
需要保留索引或列名信息时怎么办？
NumPy 数组本身不存索引或列名。如果运算后还要映射回原结构（比如做归一化后再写回 DataFrame），别急着全量转 array。
更高效的做法是：用 pandas 内置向量化方法先行处理，只在瓶颈处切出纯数值块。
- 例如标准化：直接用
(df.select_dtypes(include=np.number) - df.mean()) / df.std()，无需转 NumPy - 真要调用 NumPy 函数（如
np.linalg.svd），只提取所需子集：arr = df[['x','y','z']].to_numpy()，而非整个 DataFrame - 若必须带索引参与计算（如按行加权），先重置索引：
df.reset_index(drop=True).to_numpy()，避免 index 被误当作数据
性能差异到底有多大？
单纯调用 .to_numpy() 和 .values 的开销几乎可以忽略，真正耗时的是后续 NumPy 运算本身，以及转换前的数据清洗成本。
容易被忽略的瓶颈点：
- 字符串列未过滤就调用
.to_numpy()→ 返回 object 数组 → 后续np.sum()等操作退化为 Python 循环 - 频繁在 DataFrame 和 array 之间来回转换（比如循环中每次取一行转 array）→ 内存拷贝叠加，远慢于直接用
df.iloc[i].values或向量化操作 - 使用
copy=False却没验证内存连续性，结果仍触发隐式 copy，白忙活
实际优化重点不在“怎么转”，而在“转什么”和“为什么转”——先确认是否真需要脱离 pandas 生态，再决定切哪一块、用什么 dtype、要不要预处理缺失值。
