直接用tf.data可提速3–5倍，但需严格遵循正确pipeline顺序：shuffle→map(num_parallel_calls=AUTOTUNE)→batch→prefetch(AUTOTUNE)，且cache仅用于小数据集并置于shuffle前；任一错配均致GPU空转。
直接用 tf.data 能把数据加载速度提 3–5 倍，但前提是 pipeline 顺序、并行配置和缓存策略都对；错一处，GPU 就干等。
map() 不加 num_parallel_calls 就是单线程堵点
图像解码、归一化、随机翻转这些操作默认在 1 个 CPU 核上串行执行，哪怕你有 32 核，map() 也只用 1 个。GPU 拿到 batch 后立刻空转，显存利用率掉到 30% 是常态。
-
num_parallel_calls=tf.data.AUTOTUNE是最稳妥的选择，TensorFlow 运行时会根据当前 CPU 负载和 batch 大小动态分配线程数 - 若需手动控制（比如固定环境调试），从
num_parallel_calls=2开始试，每次 +2 观察 step time；超过物理核心数通常无收益，还可能因线程竞争拖慢 -
map函数体内不能含cv2.VideoCapture、全局变量、print()或其他不可序列化/带副作用的操作——多线程下行为不可预测 - 避免在
map()中嵌套tf.py_function：它会退回到 Python GIL，性能断崖式下跌
shuffle() 放错位置或 buffer_size 设错，数据就“假打乱”
shuffle() 并不真正打乱整个数据集，而是维护一个滑动缓冲池：每次从中随机取一个样本，再用新样本补位。buffer_size 决定了“随机性深度”和内存开销。
- 训练集 5 万样本，
buffer_size=1000→ 前 1000 个样本高频出现，后期样本几乎不会进入前几个 epoch，loss 曲线抖动剧烈 -
buffer_size=len(dataset)→ TFRecord 流式读取时根本不知道总长，强行估算易 OOM；即使能算准，也极易挤占系统内存 - 经验起点：
buffer_size=10000；已知总量时，设为样本数的 1–3 倍（如 8 万样本 →buffer_size=240000） - 必须在
repeat()之前调用shuffle()，否则每个 epoch 都从同一顺序开始，shuffle形同虚设
prefetch() 必须放在 pipeline 最末端
prefetch() 的作用是让“数据预处理”和“GPU 训练 step”重叠执行。但它只对后续操作生效——放错位置等于没开。
立即学习“Python免费学习笔记（深入）”；
- 错误写法：
dataset.prefetch().map().batch()→ 此时prefetch的是原始字节流，还没解码，毫无意义 - 正确顺序：
shuffle().map().batch().prefetch(tf.data.AUTOTUNE) - 别写
prefetch(1)或prefetch(2)：硬编码值在不同 GPU 显存、batch_size、CPU 核心数下极易失配 - 即使用了
tf.distribute.MirroredStrategy，AUTOTUNE依然有效，无需额外修改
别滥用 cache()，小数据才适合，且必须放 shuffle 前
cache() 把数据全加载进内存，对 GB 级图像路径列表有用，但对原始图像文件或大尺寸特征矩阵反而拖慢启动和训练。
- 仅适用于：内存能装下全部预处理后数据的小数据集（如 CIFAR-10 经
map解码+归一化后的结果） - 必须放在
shuffle()之前：否则每个 epoch 缓存的是不同打乱顺序，起不到加速效果 - 如果数据源是
TFRecordDataset或TextLineDataset，cache()一般没必要，IO 已经足够快 - 用
from_tensor_slices加载 NumPy 数组时，cache()无意义——数据早已在内存里
最容易被忽略的一点：所有优化都依赖于你是否用了真正的延迟加载。如果你从头就用 tf.data.Dataset.from_tensor_slices(big_numpy_array)，那后面加多少 prefetch 和 AUTOTUNE 都救不回初始化卡顿——因为数据早就全塞进内存了。
