tf.convert_to_tensor 默认复制数据，不共享内存；仅当指定 copy=False 且满足 C-contiguous、dtype 兼容、生命周期足够长时才可能复用内存。
tf.convert_to_tensor 会复制数据还是共享内存？
它默认复制。NumPy 数组传入后，TensorFlow 会创建新的设备内存（CPU/GPU）副本，原 ndarray 修改不影响张量，反之亦然。这是安全设计，避免意外的内存竞争或生命周期问题。
如果你明确知道数据不会被修改、且想省掉拷贝开销（比如大数组初始化阶段），可以加 copy=False 参数——但仅当 NumPy 数组是 C-contiguous、dtype 兼容、且生命周期长于张量时才真正生效；否则 TF 仍会悄悄复制。
- 常见错误现象：
tf.convert_to_tensor(arr, copy=False)后发现内存没省下来 → 检查arr.flags.c_contiguous和arr.dtype是否匹配目标张量类型（如np.float32对应tf.float32） - 使用场景：模型输入预处理中反复转换同一份只读特征数组，可考虑
copy=False+ 显式.astype(np.float32) - 性能影响：对 >100MB 的数组，复制可能引入几毫秒延迟；GPU 上首次上传还涉及 PCIe 传输，更明显
dtype 不一致导致 silent 转换或报错
NumPy 默认 int64、float64，而 TensorFlow 多数算子默认用 tf.int32、tf.float32。不显式指定 dtype，tf.convert_to_tensor 会按 NumPy 类型映射（np.int64 → tf.int64），后续可能触发 dtype 不匹配错误，比如喂给 tf.nn.embedding_lookup（要求 tf.int32）。
- 常见错误现象：
InvalidArgumentError: indices[0] is not in [0, 10000)→ 实际是索引数组为int64，但 embedding 层只接受int32 - 实操建议：始终显式声明
dtype，例如tf.convert_to_tensor(arr, dtype=tf.float32) - 兼容性注意：
np.bool_映射到tf.bool没问题，但np.uint8若未指定dtype，可能被当成tf.uint8，而某些图像操作（如tf.image.resize）内部要求tf.float32
高维数组或 object-type 数组直接转会失败
tf.convert_to_tensor 只支持数值型、字符串型或嵌套 list/tuple 构成的规则结构。遇到 dtype=object 的 NumPy 数组（比如存了不同长度的 list），会抛出 TypeError: Failed to convert object of type <class> to Tensor</class>。
立即学习“Python免费学习笔记（深入）”；
- 常见错误现象：从 pandas DataFrame 用
.values拿到 object 数组，直接转张量失败 - 解决路径：先用
arr.astype(str)或np.stack()/np.concatenate()拉平结构；若含缺失值，np.nan在 object 数组里无法自动转，得先填充值 - 使用场景：NLP 中 batch 的变长 token IDs，别用 object 数组存，改用
tf.ragged.constant()或 pad 后的np.array
在 @tf.function 内部调用 convert_to_tensor 的陷阱
图模式下，tf.convert_to_tensor 的输入必须是常量或已知 shape 的张量。如果传入的是 Python list 或刚生成的 NumPy 数组（尤其 shape 动态），TF 会在 trace 阶段尝试把该数组“固化”进图——一旦下次输入 shape 不同，就会触发 retracing，严重拖慢性能。
- 常见错误现象：函数执行速度越来越慢，日志出现
Retracing occurred→ 检查是否在@tf.function里频繁用np.random.rand()生成数组再转张量 - 实操建议：把 NumPy 预处理提到函数外部；若必须动态生成，用
tf.random.*算子替代，它们原生支持图模式 - 容易被忽略的点：即使你传的是
np.array([1,2,3])这种小数组，在@tf.function里也会被当作常量打包进图，后续无法 runtime 改变 length —— 所以变长输入一律走tf.TensorSpec(shape=[None], ...)声明
