根本原因是未调用 tf.train.start_queue_runners() 启动后台线程，导致队列为空、sess.run() 死等；tf.data 方案需正确配置 prefetch、cache 位置、shuffle 缓冲区大小及 repeat 行为。
为什么 tf.train.string_input_producer 和 tf.train.shuffle_batch 会卡住？
根本原因不是“异步”本身，而是 TensorFlow 1.x 的输入流水线依赖 tf.train.QueueRunner 和后台线程，但这些线程不会自动启动——你得显式调用 tf.train.start_queue_runners()，否则队列永远空着，sess.run() 在取数据时就死等。
常见现象：程序停在 sess.run([images, labels])，CPU 占用低，GPU 空转，日志无报错。
- 必须在
tf.Session()创建后、首次sess.run()前调用tf.train.start_queue_runners(sess=sess) - 如果用了
tf.train.Coordinator，还要配套调用coord.join(threads)（训练结束时），否则子线程不退出 -
num_threads设为 0 或负数会导致无声失败，实际只启用 1 个线程；设太高（如 >8）在小数据集上反而因上下文切换拖慢
用 tf.data 替代老式队列的实操要点
tf.data 是 TensorFlow 1.4+ 官方推荐路径，彻底绕过 QueueRunner 线程管理，也避免了阻塞陷阱。但它不是“开箱即用”，几个关键配置漏掉照样卡：
-
dataset = dataset.prefetch(buffer_size=tf.data.AUTOTUNE)（TF 2.x）或tf.data.experimental.AUTOTUNE（TF 1.15）必须加，否则 CPU/GPU 无法重叠预处理和训练 -
dataset = dataset.cache()要放在map()之后、shuffle()之前，否则每次 epoch 都重新读磁盘+解码 -
shuffle(buffer_size=1000)的buffer_size太小（如 10）会导致打乱不充分；太大（如 100000）吃光内存，尤其图像路径多时 - 用
dataset.repeat(count=None)控制是否循环数据集，不写默认无限循环——训练 loop 不设终止条件就会跑飞
调试阻塞时该看什么日志和指标？
别猜，直接查两个地方：
立即学习“Python免费学习笔记（深入）”；
- 运行时加环境变量
export TF_CPP_MIN_LOG_LEVEL=1（TF 1.x）或tf.debugging.set_log_device_placement(True)（TF 2.x），看数据是否真被送到了 GPU 设备 - 用
tf.profiler（TF 1.x）或tf.summary.trace_export（TF 2.x）抓 trace，重点观察 “IteratorGetNext” 节点耗时是否突增——如果是，说明tf.data流水线某环节（如map中的 PIL 解码）成了瓶颈 - 监控系统级指标：
nvidia-smi看 GPU 利用率是否长期 htop 看 Python 进程 CPU 占用是否卡在单核——大概率是数据加载没跟上
从 TF 1.x 迁移到 tf.data 最容易漏的兼容点
迁移不是改几行 API 就完事，有些行为差异不报错但结果诡异：
-
tf.train.batch(..., dynamic_pad=True)对应dataset.padded_batch()，但后者要求所有样本字段都声明padding_values，漏一个就 runtime error - 老代码里
tf.image.random_flip_left_right()返回 float32，而tf.data默认保持原始 dtype（uint8），不做.map(lambda x: tf.cast(x, tf.float32))可能导致后续层数值溢出 -
tf.train.string_input_producer自动处理文件名 shuffle，而tf.data.Dataset.list_files()默认不 shuffle，必须显式加.shuffle(buffer_size=1000)
异步数据流的“阻塞”本质是 CPU/GPU/IO 三者节奏没对齐，问题不在某一行代码，而在整个 pipeline 的 buffer 大小、线程数、预取层级这些参数组合是否匹配你的硬件和数据特征。调参前先确认你在用哪套 API，因为两套机制的故障表现相似，修复路径完全不同。
