瑶瑶宝训练集总共800张图，验证集刷到98%，换一批真实场景的测试图直接掉到不足70%——如果你也遇到过这种“虚假繁荣”，多半是模型把背景细节和光照模式背下来了。这时候最直接的解法就是数据增强。上一篇文章我把数据增强的整体逻辑和常见策略梳理了一遍，这篇作为系列第二篇，专门落到TensorFlow的API层面，把最常用的一批基本变换操作逐个拆开讲清楚：翻转、旋转、裁剪、缩放、颜色调整、加噪，每个函数的参数、适用场景、容易翻车的位置都尽量标出来。适合正在用TensorFlow做图像分类、检测、分割实验，想摆脱ImageDataGenerator黑盒、自己搭增强管线的读者。
1. 三套API并存的局面：tf.image、Keras预处理层和ImageDataGenerator怎么选
1.1 官方至少给了三套方案，别一上来就蒙头写代码
TensorFlow里做数据增强从来不止一条路。最老牌的是tf.keras.preprocessing.image.ImageDataGenerator，大家习惯直接叫ImageDataGenerator，配合flow_from_directory加载目录图片做分类训练，确实省事。但它把rescale、rotation_range、zoom_range这类参数一股脑封装在类内部，处理流程对用户几乎是个黑盒，遇到增强效果不符合预期时很难定位是哪一步出了问题。
第二套是Keras预处理层，像tf.keras.layers.RandomFlip、RandomRotation、RandomZoom这一类。它们最大的特点是可以直接嵌进模型结构里，训练阶段执行随机增强、推理阶段自动关闭，适合不想手动管理数据管道的场景，部署时模型本身也自带预处理逻辑。不过它的随机行为是用层内部状态控制的，想精细控制每张图的变换过程不太顺手。
第三套才是本篇的主角：tf.image下面的函数族。它们分散在不同模块里，每个函数完成一种像素级或几何级的操作，自由度最高，但需要自己组织调用逻辑。我的结论是：三套方案各有适用场景，不存在绝对优劣。想做快速原型又不想写太多代码，ImageDataGenerator可以用；想嵌入部署图，预处理层很方便；想完全掌控增强过程、扩展自定义逻辑，tf.image配合tf.data是最踏实的一条路。
1.2 为什么我最终落到了tf.image + tf.data的组合
原因很朴素，两个字：调试。在tf.data的map函数里，每一步输出是什么shape、什么dtype，都可以直接打印出来验证。ImageDataGenerator三行代码就能跑起来，但一旦发现增强逻辑有问题，你想在pipiline中间插一个断点看数据状态，会非常别扭，因为数据流被封装在迭代器内部。
另一个原因是我经常要处理检测、分割这类带标签的任务，图像和bbox坐标、mask掩码必须同步做变换。ImageDataGenerator对这类标签的扩展支持很基础，而tf.data的map函数里我可以写完全自定义的变换逻辑，图像怎么动，标签就在同一个函数里跟着怎么动。至于Keras预处理层，我一般只在模型结构已经稳定、不需要额外调试的时候才用，把它当作部署阶段的一个内置前处理组件。
1.3 数据流向清晰了，增强放在哪个位置才不会出错
不管最终选哪套工具，数据进入模型之前基本都要经过这条链路：文件名列表 -> 读取文件 -> 解码 -> 尺寸调整 -> 数据增强 -> shuffle -> batch -> prefetch -> 喂给model.fit。增强操作放在解码和尺寸调整之后、shuffle和batch之前，是我个人最推荐的顺序。
原因有几个。其一，shuffle要在增强之前做，确保模型看到的是打乱的样本；其二，batch之后再增强，很多tf.image函数不认batch维度，需要额外写循环，不仅慢还容易写错；其三，解码和resize是纯计算密集型操作，可以用cache缓存结果，而增强因为带随机性，每次epoch重新执行，反而能持续给模型提供新样本。如果训练集不大，建议在cache之前先把原始图解码好，之后每次epoch增强都重新随机执行，既省了重复解码的开销，又保留了增强的多样性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 六大基本变换逐个拆解：翻转、旋转、裁剪、缩放、颜色、噪声
2.1 翻转：最安全的几何增强之一
左右翻转大概是所有增强操作里最不容易出错的。tf.image.random_flip_left_right(image)会以50%概率左右翻转，tf.image.random_flip_up_down(image)则负责上下翻转。两个函数都有确定性版本，tf.image.flip_left_right和`tf.i