PyTorch/TensorFlow模型要求输入为Tensor且batch维明确，list会触发隐式转换或报错；逐个转Tensor再拼接导致内存拷贝多、无并行、GPU利用率低；应统一转CPU tensor后stack再一次性to(device)，尺寸不一致时优先pad或分桶而非硬resize。
为什么直接用 list 喂模型会报错或变慢
PyTorch/TensorFlow 的模型前向（forward）默认只接受 torch.Tensor 或 tf.Tensor，且要求 batch 维必须明确——比如 [B, C, H, W]。直接传入 list（如 [img1, img2, img3]）会触发隐式转换或报 TypeError: expected Tensor, not list；即使能运行（如某些封装接口），也会逐个转 tensor 再拼接，反复调用 torch.tensor()，内存拷贝多、无并行、GPU 利用率低。
用 torch.stack() 还是 torch.cat()？关键看输入结构
两者都要求所有元素 shape 一致，但语义不同：
-
torch.stack()：在新维度上堆叠，适合「同shape 单样本 list → batch tensor」。例如 3 张[3, 224, 224]图 →[3, 3, 224, 224]（batch 维=0） -
torch.cat()：沿现有维度拼接，适合已含 batch 维的 tensor list（如每个元素已是[1, 3, 224, 224]），拼成[3, 3, 224, 224]
绝大多数预处理后单图是 torch.Tensor，所以优先选 torch.stack()；若用 transforms.ToTensor() 后仍是 PIL 图，得先统一转 tensor 再 stack。
避免 CPU→GPU 多次搬运：提前移入 device
常见错误是先 torch.stack(list_of_tensors) 得到 CPU tensor，再对整个 batch 调用 .to(device)——这没问题；但若在 list 阶段就对每个 tensor 单独 .to(device)，会触发多次 kernel 启动，拖慢速度。
立即学习“Python免费学习笔记（深入）”；
- ✅ 正确：全部转好 CPU tensor →
torch.stack()→ 一次.to('cuda') - ❌ 低效：对每个 PIL 图做
transform(img).to('cuda')，再 list 推导 → 最后 stack → GPU 上拼接（实际已无效） - 注意：
torch.stack()不支持跨 device，所有输入 tensor 必须同 device（通常全 CPU）
遇到不规则尺寸怎么办？别硬 stack
真实数据常有不同宽高（如检测/分割任务的原始图）。强行 resize 会失真，而 torch.stack() 直接报错 RuntimeError: invalid argument 0: Sizes of tensors must match。
- 方案一（推荐）：用
torch.nn.utils.rnn.pad_sequence()（仅限 1D/2D 序列），或手动 pad 到 batch 内最大尺寸 + 记录真实长度 - 方案二：分桶（bucketing）——按尺寸聚类，同 batch 只塞相近尺寸图，减少 padding 浪费
- 方案三：改用动态 batch（如 Hugging Face
DataCollator），但需配合DataLoader的collate_fn参数，不能直接 stack
硬 resize 看似简单，但对定位类任务影响显著；pad 是更可控的妥协。
batch 构建本身不难，难的是和预处理链路对齐——transform 输出类型、device 分配时机、尺寸不一致时的 fallback 策略，这三个点漏掉任一个，都可能让“优化”变成负优化。
