企业官网建设流程全解析

看到标题只剩一个tensorflow，我猜不少人的反应是先愣一下：深度学习框架的新鲜劲儿早过了，怎么还绕回来聊它？但说句实在话，在我日常的工程实践里，TensorFlow 依然是最常被点名的那个名字。无论是传统行业里要求严格离线部署的视觉质检项目，还是需要稳定跑上几个月的在线推理服务，它都还在扛大梁。这篇内容我不打算讲教科书式的基础教程，而是想以一个摸爬滚打多年的从业者视角，把 TensorFlow 里最值得搞懂的原理、最容易踩的迁移坑、以及从训练到部署的全链路经验一次说清楚。不论你是刚入门的初学者，还是被遗留代码折磨过一阵子的开发者，这篇都可以当作一份能直接参照的实操笔记。

TensorFlow 真正难的地方，从来不是记住某个函数怎么调用，而是理解这套框架看待数据的底层方式和它的设计取舍。只有把这些想明白了，后面跑模型、调性能、上生产环境才会顺，不然你只是跟着教程敲代码，换个数据集就寸步难行。

1. 为什么在一个满是新框架的时代，我还坚持用 TensorFlow 做事

先说个可能有些反直觉的结论：框架的新旧和项目能不能平稳落地，关系并没有想象中那么大。身边不少同行这几年切到别的框架，确实爽了一阵子，因为动态图调试起来直观。但等真到上线阶段，又要开始折腾部署组件、处理模型格式转换、考虑服务版本兼容，绕了一圈发现又回到了 TensorFlow 擅长的区域。这也就是为什么它到现在还被大量工业级项目作为基座。

从个人经验看，TensorFlow 最稳的三个优势分别在工程完整度、部署生态和团队协作习惯上。

• 工程完整度：从数据管道、模型构建、训练策略到分布式，再到校验、导出、上线，官方都给了完整方案，不依赖第三方拼凑。
• 部署生态：TensorFlow 在服务化推理和端侧部署上的积累很深，SavedModel 格式能够做到一次训练、多处运行。
• 团队协作习惯：很多较早接触深度学习团队的代码仓库里，沉淀的底层工具类、图像处理流水线都是基于 TensorFlow 写的，后来的开发者已经习惯了这套语法风格。

当然，我不是说它对所有任务都是最优解。在研究型项目里，需要频繁改网络结构、做快速实验，想用更轻便的写法，完全可以选择自己舒服的工具。但如果你追求的是"一个框架走到底，训练完能顺手部署出去"，TensorFlow 到今天依然是值得认真考虑的第一梯队。

1.1 从一段张量计算看框架的底层角色

很多人把框架理解成"一个写模型的库"，这个印象太浅了。它的本质是一套张量计算与自动求导的运行时。所谓张量，你可以朴素地理解为多维数组：标量是零维、向量是一维、矩阵是二维，而图像数据通常就是四维——批次、高度、宽度、通道。这个抽象和 NumPy 很像，但关键差异在于，TensorFlow 会自动追踪运算过程并解析出梯度。

来看最基础的一段代码：

import tensorflow as tf x = tf.constant([[1.0, 2.0], [3.0, 4.0]]) w = tf.Variable([[1.0, 0.0], [0.0, 1.0]]) with tf.GradientTape() as tape: y = tf.matmul(w, x) loss = tf.reduce_sum(y) grad = tape.gradient(loss, w) print(grad.numpy())

tf.GradientTape是 2.x 版本里最核心的自动微分工具。它像一台录音机，把with块内的所有可微分运算全部录下来，然后反向播放，计算出loss对w的导数。没有这套机制，你就要手动推导每个算子梯度的链式法则，深度学习就沦为一场噩梦。

用一个生活化的类比：把 TensorFlow 想象成一家现代化物流仓库，张量是货物，计算图是货物流转路径，自动微分则是快递单号追踪系统。你不用关心货物在哪个货架之间怎么搬运，只要告诉系统"这批货从 A 到 B 再到 C"，它就能随时告诉你每段路程的运输损耗是多少。

1.2 自动微分、设备调度和模型管理：三个隐形支柱

很多人以为框架核心只有"计算图+自动微分"，实际上工程落地时，还有另外两个支柱同等关键：设备调度和模型管理。

设备调度解决的是"你的运算跑在哪儿"的问题。同样是tf.matmul，在有 GPU 环境下，框架会自动把张量放到显存里执行；而在纯 CPU 环境下，则使用底层的高性能矩阵计算库。开发者不需要手写 GPU 内核，只需要通过tf.device或环境变量控制可见设备。我经常和新人说，把框架理解成"一个自动帮你决定去哪个车间生产的调度员"会更准确。

模型管理则是容易被低估的一块。训练得到的权重参数散落在各个Variable里，如何统一保存、恢复、迁移，直接决定项目能不能交接。TensorFlow 用Checkpoint和SavedModel两层机制解决：前者偏向训练中间态备份，后者是完整的可部署模型包。关于部署格式，后面章节我会仔细展开，这里先建立一个整体认知。

2. TensorFlow 真正难懂的不是 API，而是它背后的三个抽象

如果你直接翻开老教程，很可能会撞上一堆历史遗留概念，然后陷入"每个单词都认识，合起来不知道在干嘛"的窘境。这不怪你，因为 TensorFlow 1.x 和 2.x 之间的设计理念差异太大，几乎像两个框架。与其一个函数一个函数地记，不如先把三个核心抽象彻底吃透：张量、变量、计算图。

2.1 张量和变量：数据与模型参数的边界

学 TensorFlow 第一天就该分清楚：tf.Tensor是只读的数据对象，而tf.Variable是可被优化器更新的参数容器。

a = tf.constant([1, 2, 3]) # 不可变张量 b = tf.Variable([1, 2, 3]) # 可变变量 b.assign_add([1, 0, 0]) # 原地更新，OK # a.assign_add([1, 0, 0]) # 报错，Tensor 没有 assign_add

模型里的卷积核、偏置项都是Variable；输入图片、中间特征图则是Tensor。优化器本质上做的事情，就是不断计算loss对各个Variable的梯度，再调用assign_sub之类的方法更新它们。如果你用 NumPy 的思维模式，把参数放在普通数组里，那梯度根本无法传导，框架会直接丢给你一个晦涩难懂的报错。这个边界必须在心里刻牢。

2.2 Eager 模式与 Graph 模式：动态调试与静态提速的取舍

TensorFlow 2.x 默认开启动态图（Eager Execution），你写一行执行一行，直接拿到数值结果，调试体验接近原生 Python。这在现代开发里非常友好，但它也带来了性能开销，因为每一步 Python 和底层运行时之间都有反复的桥接损耗。

这时就轮到@tf.function出场了。它做的事情很有意思：把一段 Python 函数里的 TensorFlow 运算抽取出来，编译成一张静态计算图，然后以图的方式整体执行。你可以把它理解成"把菜谱先完整记下来，再一次性进厨房，而不是看一步做一步"。

@tf.function def forward(x): return tf.nn.relu(tf.matmul(x, w) + b)

但这里藏着一个经典陷阱：如果函数内部混入了 Python 原生逻辑，比如if x > 0:，而x是 Tensor，那么这段逻辑不会按你直觉执行。因为图编译时，Python 的if是在构建图阶段判断的，它不是动态分支。想要根据张量数值做分支，必须用tf.cond。类似的还有for循环对应tf.while_loop。我见过不少同学在这里被搞到崩溃，明明同样的代码，直接执行没问题，一加装饰器结果就完全变了。

2.3 自动微分与优化器的配合逻辑

前面提到GradientTape，它和优化器的配合也有讲究。很多人只会照着范本写optimizer.apply_gradients(zip(grads, vars))，却不明白为什么要多这一步。

梯度计算出来后，优化器还要做很多事情：按学习率缩放、应用动量、做梯度裁剪、处理稀疏更新。apply_gradients就是把这些后处理逻辑和参数更新打包在一起。如果你跳过优化器，直接手动做var.assign_sub(lr * grad)，那就丢失了动量等优化机制，模型收敛效果会明显变差。

为什么会这样设计？因为框架要同时满足简单用法（直接用model.fit）和灵活研究（自定义训练循环）。理解了自动微分和优化器之间的分工，你才能真的读懂每一行自定义训练代码，而不是只会复制粘贴。

3. TF1 到 TF2 的迁移断层：旧代码到底是怎么一步步失效的

如果你维护过三年以上的深度学习项目，大概率会遇到那种"当时能跑、现在一开就是一堆异常"的老代码。这不全是环境依赖的问题，而是 TensorFlow 2.x 对 1.x API 做了非常彻底的清理。官方提供了自动迁移脚本，但它处理不了所有情况，尤其处理不了你对旧范式理解不深的问题。

3.1 Session、placeholder 和静态图时代的思维模式

TensorFlow 1.x 的标准写法是这样的：

import tensorflow.compat.v1 as tf tf.disable_v2_behavior() x = tf.placeholder(tf.float32, shape=[None, 784]) W = tf.Variable(tf.zeros([784, 10])) b = tf.Variable(tf.zeros([10])) y = tf.nn.softmax(tf.matmul(x, W) + b) with tf.Session() as sess: sess.run(tf.global_variables_initializer()) result = sess.run(y, feed_dict={x: batch_x})

这套流程对新手特别不友好：你构建了一大堆符号，然后必须通过sess.run和feed_dict把真实数据"喂"进去，才能得到结果。它的问题在于，调试时你没法直观看到中间变量的值，出了 NaN 只能靠到处加打印。当时的日报、脑图、花在"让模型跑起来"上的时间，估计每个老开发者都能写出一部血泪史。

3.2 Eager 模式下，这些概念都去哪儿了

到了 TensorFlow 2.x，上面的代码可以简化成：

import tensorflow as tf w = tf.Variable(tf.zeros([784, 10])) b = tf.Variable(tf.zeros([10])) y = tf.nn.softmax(tf.matmul(x, w) + b)

没有Session，没有placeholder，没有global_variables_initializer。变量在定义时就完成了初始化，数据直接作为函数参数传入。整个心智模型从"构建图、喂数据、跑会话"变成了"写函数、传张量、得结果"。

但这里有个矛盾点：tf.compat.v1模块还保留着旧 API，能用，但它依然依赖静态图执行模式。你千辛万苦迁移到 2.x 之后，如果又为了省事把旧接口引进来，等于回到过去。我的建议很直接：长痛不如短痛，全量切换到 2.x 写法。旧的自动迁移脚本能把大部分v1代码改成compat.v1，但这只是治标，真正的存量债务还得靠重写核心训练循环去化解。

3.3 从tf.contrib到 Keras 化：生态整合的历史包袱

很多老项目崩溃的另一个重灾区是tf.contrib。这个模块当年是"实验性功能的杂货铺"，后来整个被移除，里面的上层 API 全部迁移到独立仓库或 Keras 体系。你要是还import tensorflow.contrib，在新版本里直接报ModuleNotFoundError。

替代方案往往是tf.keras。它把层、损失函数、优化器、指标、回调统一封装，成为 TensorFlow 2.x 官方推荐的高层接口。当年只会用底层 API 写tf.nn.conv2d的人，现在转向tf.keras.layers.Conv2D，认知负担反而小了很多，因为层的抽象更接近神经网络本身的层次结构。

4. 用 Keras 把图像分类模型跑起来：完整实操与背后的选择逻辑

理论知识铺垫完了，下面真正进入动手环节。这部分我会用 CIFAR-10 图像分类作为演示任务，从数据读取到训练调优，完整走一遍。CIFAR-10 包含 5 万张训练图和 1 万张测试图，每张都是 32×32 的彩色小图，共 10 个类别。它比 MNIST 真实得多，又不会大到让 CPU 训练等太久，是验证框架理解水平的好题目。

4.1 数据处理：为什么用 tf.data 而不是 NumPy 硬怼

新手容易犯的第一个错，是习惯先把所有图片读进内存变成一个大 NumPy 数组，然后一次性喂给模型。在小数据集上这没问题，但真实项目里数据集往往大到内存装不下，或者需要复杂的在线增强。这时候就该用tf.data构建数据管道。

import tensorflow as tf def normalize(image, label): image = tf.cast(image, tf.float32) / 255.0 return image, label train_ds = tf.keras.datasets.cifar10.load_data() # 这里简化数据读取演示 (x_train, y_train), (x_test, y_test) = train_ds x_train = x_train.astype("float32") / 255.0 y_train = y_train.astype("int32") dataset = tf.data.Dataset.from_tensor_slices((x_train, y_train)) dataset = dataset.map(normalize, num_parallel_calls=tf.data.AUTOTUNE) dataset = dataset.shuffle(5000).batch(128).prefetch(tf.data.AUTOTUNE)

这几个操作依次解释一下：

• from_tensor_slices：把数组按第一维切成样本，构成数据集对象。
• map(normalize, num_parallel_calls=tf.data.AUTOTUNE)：对每个样本做预处理。AUTOTUNE让框架根据 CPU 核心数自动决定并行线程数。
• shuffle(5000)：建立 5000 样本的缓冲区，随机打乱顺序，防止模型学到样本排列规律。
• batch(128)：把样本打包成 128 个一组。
• prefetch(tf.data.AUTOTUNE)：让数据预处理和模型训练重叠进行，GPU 不用干等 CPU 造数据。

如果你不用tf.data，而是写个 Python 生成器配合fit，也不是不行。但generator的数据加载往往受 GIL 限制，CPU 和 GPU 之间很难形成流水线并行，大模型训练时每轮之间的空隙会非常明显。tf.data的设计目标就是把这套"生产者-消费者"模式做到极致，值得多花点时间掌握。

4.2 模型搭建：Sequential 和 Functional 到底怎么选

搭建模型有两种主流风格。一种是Sequential，适合线性的、一层接一层的网络：

model = tf.keras.Sequential([ tf.keras.layers.Conv2D(32, (3, 3), activation="relu", input_shape=(32, 32, 3)), tf.keras.layers.MaxPooling2D((2, 2)), tf.keras.layers.Conv2D(64, (3, 3), activation="relu"), tf.keras.layers.MaxPooling2D((2, 2)), tf.keras.layers.Flatten(), tf.keras.layers.Dense(64, activation="relu"), tf.keras.layers.Dense(10, activation="softmax") ])

这种写法直观，但一旦网络有分支结构，比如输入经过两个不同的卷积分支后再合并，Sequential就无能为力了。这时要换Functional：

inputs = tf.keras.Input(shape=(32, 32, 3)) branch1 = tf.keras.layers.Conv2D(32, (3, 3), activation="relu")(inputs) branch2 = tf.keras.layers.Conv2D(32, (5, 5), activation="relu")(inputs) merged = tf.keras.layers.Concatenate()([branch1, branch2]) out = tf.keras.layers.Flatten()(merged) out = tf.keras.layers.Dense(10, activation="softmax")(out) model = tf.keras.Model(inputs=inputs, outputs=out)

**我的判断标准是：能用 Sequential 表达的简单网络就直接用；一旦涉及多输入、多输出或层与层之间的信息拼接，果断用 Functional，别硬凑。**Functional 的 API 风格其实也是个"函数式编程"的思路——每一行都在调用上一层结果，然后把新的张量传给下一层。理解了这一点，你就能看懂绝大多数开源模型代码。

4.3 编译、训练与回调：run 起来只是第一步

模型装配完毕后，compile决定训练用的优化器、损失函数和评价指标。多分类任务通常用sparse_categorical_crossentropy，因为标签是整数；如果标签做了 one-hot 编码，则用categorical_crossentropy。这一对名称极度容易弄混，我自己刚学时也栽过跟头，报错之后才发现标签格式没对上。

model.compile( optimizer="adam", loss="sparse_categorical_crossentropy", metrics=["accuracy"] )

训练时，我最常挂的callbacks有四个：

• ModelCheckpoint：每个 epoch 结束按条件保存权重，通常监控验证集准确率，只保留最好的模型。
• EarlyStopping：验证集指标连续 N 轮不提升就提前停，省时间也防过拟合。
• ReduceLROnPlateau：验证指标停滞时把学习率降一个量级，让训练更细致地收敛。
• TensorBoard：把 loss 和 metric 曲线可视化，排查训练发散问题非常好用。

callbacks = [ tf.keras.callbacks.ModelCheckpoint( "best_model.keras", monitor="val_accuracy", save_best_only=True ), tf.keras.callbacks.EarlyStopping( monitor="val_accuracy", patience=5, restore_best_weights=True ), tf.keras.callbacks.ReduceLROnPlateau( monitor="val_accuracy", factor=0.5, patience=2 ) ] model.fit( dataset, epochs=30, validation_data=test_ds, callbacks=callbacks )

ModelCheckpoint生成的.keras格式是 Keras 3.x 之后的推荐格式，它把网络结构、权重和优化器状态打包在一个文件里，比单纯存h5更完整。小心一个常见误区：只存权重的checkpoint文件换网络结构后加载会报错，一定要配合原模型结构使用。

很多教程到这里就结束了，说"你看，跑起来了，准确率 75%"。但工程上不是这样收工的。你还需要在独立的测试集上计算最终指标，确认模型没有过拟合到验证集；你还要把模型导出成部署格式，才能在业务系统里真正调用。下一节就讲这件事。

5. 部署环节才是 TensorFlow 拉开差距的地方：SavedModel 与端侧落地

不少开发者训练完模型就松了一口气，觉得任务完成了。但真实项目中，训练只是三分之一，另外三分之二是把模型丢给业务系统去用。TensorFlow 在这一段积累的工程能力，是真刀真枪拉开差距的地方。

5.1 SavedModel：一次训练、多处运行的统一格式

SavedModel是 TensorFlow 推荐的模型交付格式。它不只有权重，还把网络结构、推理所需的预处理逻辑、签名函数全部打包在一个目录里。你可以把它理解成"给模型做了一次集装箱标准化，不管轮船、卡车还是火车，都能直接装卸同一个箱子"。

model.save("saved_model/cifar_demo")

导出后目录大概是这个样子：

saved_model/cifar_demo/ ├── assets/ ├── fingerprint.pb ├── saved_model.pb └── variables/ ├── variables.data-00000-of-00001 └── variables.index

在这个目录上调用加载接口，可以很轻松地做推理：

loaded = tf.saved_model.load("saved_model/cifar_demo") infer = loaded.signatures["serving_default"] result = infer(tf.constant(single_image_tensor))

为什么要关心这个目录结构？因为后续你要用的 Serving、TFLite 转换器，全都认这个格式。训练时的.keras文件更偏重开发调试，部署时还是要导出一份SavedModel。

5.2 用 TensorFlow Serving 提供稳定的推理服务

在线推理场景里，你当然可以自己写个 Flask 接口，加载模型算预测。但一旦并发上来、需要模型热更新、要监控请求延迟，手动方案会非常吃力。TensorFlow Serving 就是专门解决"模型服务化"这个问题的组件。

它的工作方式简单说就是：启动一个服务进程，指定SavedModel的根目录，然后通过 gRPC 或 HTTP 接口接收请求、返回推理结果。模型更新时，服务可以自动加载新版本，不用重启进程。我曾经在一个模拟项目里同时切换过三个版本的模型做灰度验证，正是依赖这个机制，整个过程没有中断过一次线上调用。

tensorflow_model_server \ --rest_api_port=8501 \ --model_name=cifar_demo \ --model_base_path=/workspace/saved_model

请求和响应的细节不在这里贴完整代码，因为不同环境配置差异较大。重点是建立一个概念：在你的产品和模型之间，应该有一层标准化的模型服务中间件，TensorFlow Serving 就是这个中间件里最成熟的选择之一。

5.3 端侧与边缘部署：TFLite 和量化瘦身

如果你要把模型塞进手机 App 或嵌入式设备，直接跑完整版模型通常不现实。一个 500MB 的模型在手机端既占存储又跑不动。这时需要通过TFLite转换器做格式转换，并配合量化压缩体积：

converter = tf.lite.TFLiteConverter.from_saved_model("saved_model/cifar_demo") converter.optimizations = [tf.lite.Optimize.DEFAULT] tflite_model = converter.convert() with open("model.tflite", "wb") as f: f.write(tflite_model)

量化后的模型往往能压缩到原来的四分之一以下，在支持硬件加速的设备上，推理速度不降反升。代价则是精度略有下降，通常在一个百分点以内。对于很多业务场景，这个精度损失完全可接受。

做端侧部署时还有个小细节：模型的输入尺寸往往是固定的，比如 32×32×3。如果业务图片尺寸不统一，不能直接塞进模型，需要在转换前把预处理逻辑（resize、归一化）一并放进模型里，或者客户端先完成预处理。我见过太多人忽略这个步骤，上线后发现手机构造的数据和模型期望的输入对不上，跑一个错一个。

6. 性能与显存的隐形坑：我从真实负载里总结的经验

框架用熟了之后，真正决定项目上限的往往是性能调优。这里的"性能"不是刷榜跑分，而是同一套模型在相同硬件上，你的吞吐量是否能比隔壁团队高一倍。以下几个坑，我几乎在每次实战里都要再强调一遍。

6.1 GPU 显存失控：一上来就吃掉全部显存

TensorFlow 默认行为是进程启动就抢占所有可见 GPU 的显存。这在服务器上问题不大，但在共享 GPU 的开发机上，会直接导致别人没法用。解决办法是让显存按需增长：

physical_devices = tf.config.list_physical_devices("GPU") if physical_devices: tf.config.experimental.set_memory_growth(physical_devices[0], True)

或者显式限制最大显存：

tf.config.set_logical_device_configuration( physical_devices[0], [tf.config.LogicalDeviceConfiguration(memory_limit=4096)] )

在多人共用一台开发机的场景里，显存按需增长几乎是保命配置。每次我接手新环境，第一件事先看显存策略，否则后面跑起大模型来各种莫名 OOM，查又查不出原因。

6.2 数据管道瓶颈：map、shuffle、prefetch 的顺序影响

tf.data的操作顺序直接影响吞吐量。我见过一个项目，代码把shuffle放在map之前，导致每次 shuffle 都要先等所有图片做完归一化，缓冲区内全是加工后的数据，浪费了大量内存。标准的顺序应该是：先 map 做轻量预处理，再 shuffle 建缓冲区，然后 batch 打包，最后 prefetch 预取。

当然，如果预处理本身就是简单操作，map 和 shuffle 顺序差异不大。但遇到图像解码、随机裁剪这类重操作时，顺序的影响会被急剧放大。建议只把必要操作放进 map，避免在并行线程里做过于复杂的计算。

还有个细节是prefetch的缓冲区大小。初学者喜欢设一个很大的数，但prefetch(1)通常已经足够让 GPU 和下个 batch 的 CPU 处理重叠。设太大反而占内存。这里不用过度优化，tf.data.AUTOTUNE多数情况下就是最优解。

6.3 混合精度与显存占用：白嫖的加速

TensorFlow 2.x 原生支持混合精度训练，用float16计算、float32累积梯度，能在兼容硬件上获得明显加速，同时显存占用接近减半。开启方式很简单：

tf.keras.mixed_precision.set_global_policy("mixed_float16")

但这里有个容易忽略的点：混合精度下，模型最后一层分类层的输出通常要 cast 回float32，否则计算 loss 时可能因为精度截断导致结果不稳定。框架默认会有策略处理，但如果你自定义损失函数，一定要检查 dtype 是否正确。

在我做过的模拟项目里，开启混合精度后单次训练耗时减少了约 30% 到 40%，显存占用从 11GB 降到 6GB 左右。这意味着同一张卡可以塞进更大的 batch，或者同时跑两个实验。同样是这几行配置，性价比高得惊人。

6.4 学会用 TensorBoard 定位性能短板

遇到训练慢，先别急着怀疑框架。用 TensorBoard 的 Profile 工具看一眼数据管线耗时和计算耗时，问题往往一目了然。如果tf.data迭代耗时远高于 kernel 计算耗时，说明数据管道是瓶颈；如果 kernel 计算占大头，说明模型本身算力密集，得从网络结构或 batch size 下手。

tensorboard_callback = tf.keras.callbacks.TensorBoard( log_dir="./logs", profile_batch="10,20" )

profile_batch指定在第 10 到 20 个 batch 期间做性能剖析。这部分信息量很大，但很多开发者从不看，遇到性能问题就靠猜，浪费时间还找不到根因。

7. 写在最后：我的学习建议与易错点清单

如果这是你第一次系统接触 TensorFlow，我的建议是别急着把所有高阶 API 都学一遍。先把张量、变量、GradientTape这几个最底层的概念写明白，再用tf.keras跑通至少一个图像分类任务，然后完整走一遍"训练 → 导出 SavedModel → 加载推理"的链路。这一套走完，你对框架的理解已经超过大部分只会敲教程代码的人。

下面是我个人在实战中反复踩过、后来整理成清单的易错点，供你参考：

• 使用tf.Variable存模型参数，不要用tf.Tensor或 NumPy 数组。
• 多分类的标签若是整数，loss 用SparseCategoricalCrossentropy；若是 one-hot，则用CategoricalCrossentropy，两者的区别会直接改变训练行为。
• 显存策略要提前设置，最好在导入模型或 GPU 运算之前，否则不生效。
• tf.function内不要写依赖张量数值的 Pythonif/else，要用tf.cond代替。
• 保存模型前明确存储接口用途：开发调试用.keras，生产部署用SavedModel。
• 自定义训练循环里，梯度计算和优化器更新之间不能插入太多无关操作，否则可能破坏梯度流的稳定性。
• 数据管线一定要加prefetch，否则 GPU 空转是常态，训练速度上不去。
• 混合精度后注意损失计算与输出层的 dtype，必要时做tf.cast。

最后再分享一个我自己亲测很受用的学习方法：把官方关于"基础训练"的示例代码，从头到尾改一遍，每次只改一个结构，比如把Conv2D换成DepthwiseConv2D，把优化器从adam换成sgd，然后观察指标变化。这个过程要比背 API 文档有效得多。框架是工具，你对它的手感，来自一次次亲手修改和跑通，而不是来自收藏夹里吃灰的教程。希望这篇笔记能帮你少走几步弯路，把时间花在真正的模型和业务问题上。