应使用sparsecategoricalcrossentropy，因其专为整数标签（如[0,2,1]）设计，而categoricalcrossentropy要求one-hot标签；设from_logits=true可避免重复softmax导致梯度消失或nan。

为什么用 SparseCategoricalCrossentropy 而不是 CategoricalCrossentropy

因为你的标签是整数（比如 [0, 2, 1]），不是 one-hot（比如 [[1,0,0], [0,0,1], [0,1,0]]）。用错会直接报错 InvalidArgumentError: logits and labels must have the same first dimension，或者训练时 loss 不下降——本质是维度对不上，模型在“猜”你传的是什么格式。

常见场景：分类任务中，tf.data.Dataset 从文件或 tf.keras.utils.image_dataset_from_directory 加载数据时，默认输出的 label 就是 int 类型索引；这时候必须配 SparseCategoricalCrossentropy。

• 标签是 int32 或 int64，且值域为 [0, num_classes)
• logits 输出形状是 (batch_size, num_classes)，不需要 softmax 激活（它内部已做数值稳定处理）
• 若手动加了 softmax 层，又设 from_logits=False（默认值），loss 会严重失真——这是最常踩的坑

SparseCategoricalCrossentropy 的关键参数怎么设

核心就两个参数：from_logits 和 reduction。其它如 name 基本不用动。

• from_logits=True（强烈建议显式写上）：告诉 loss 函数输入是 raw logits，它会自己做 softmax + log + cross-entropy。绝大多数情况该设为 True
• from_logits=False：要求输入已是概率分布（sum=1），但实际几乎没人这么用——容易因数值下溢出错，且多一道 softmax 计算，没好处
• reduction=tf.keras.losses.Reduction.SUM_OVER_BATCH_SIZE（默认）：返回标量 loss，适合 model.compile()；若你在自定义训练循环里需逐样本梯度，才考虑 None

示例初始化：

loss_fn = tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True)

和 model.compile() 配合时的典型错误

错误不是来自 loss 本身，而是前后不一致导致 silent bug：loss 算了，但梯度崩了、acc 卡在 0 或随机水平。

• 模型最后一层用了 activation='softmax'，但 loss 还设 from_logits=True → 重复 softmax，输出饱和，梯度消失
• 模型没加 softmax，但 loss 设 from_logits=False → 输入是大正负数，log(0) 或 log(负数) 触发 NaN
• 标签 dtype 是 float32（比如从 numpy array 直接转的），而 SparseCategoricalCrossentropy 只接受整数 → 报错 Expected integer arguments

检查方法：

print(y_true.dtype)  # 应为 <code>int32</code> 或 <code>int64</code><br>print(model.layers[-1].activation)  # 应为 <code><function linear...></function></code>（即无激活）

和 tf.nn.sparse_softmax_cross_entropy_with_logits 有什么区别

前者是 Keras 高阶封装，后者是底层 ops。日常用前者就够了；只有在写自定义训练步（@tf.function 内）、需要精细控制 reduction 或梯度裁剪时，才碰后者。

• tf.nn.sparse_softmax_cross_entropy_with_logits 返回 shape 为 (batch_size,) 的 tensor，需手动 tf.reduce_mean
• 它不检查 label 范围，越界（如 label=5 但只有 3 类）会静默返回 nan —— SparseCategoricalCrossentropy 默认会抛异常（可设 ignore_class=-1 来跳过无效 label）
• 性能差异微乎其微，别为了“底层更快”去换，维护成本高得多

真正要盯住的，是 label 的取值范围是否真落在 [0, num_classes) 内——这个边界检查在训练几轮后突然失败，往往是因为数据 pipeline 里混进了脏数据或索引偏移。