在on_epoch_end中通过epoch参数获取当前轮次（从0开始），在on_train_batch_begin/end中通过batch参数获取当前批次索引（从0开始）；logs字典在对应方法中提供该阶段指标。
Callback里怎么拿到当前epoch和batch的数值？
TensorFlow的tf.keras.callbacks.Callback基类会在训练不同阶段自动触发方法，关键不是“怎么记录”，而是“在哪一刻能拿到什么数据”。on_train_batch_end里有logs字典，含loss、accuracy等指标；on_epoch_end里同样有logs，但还多一个epoch参数——这才是你真正需要的轮次编号。别试图在on_train_begin里预设计数器，TensorFlow自己维护着这些状态。
-
on_train_batch_begin(batch, logs)：batch是当前batch索引（从0开始），logs为空字典 -
on_train_batch_end(batch, logs)：batch仍是索引，logs已填入该batch的指标（如{'loss': 0.421, 'accuracy': 0.89}） -
on_epoch_end(epoch, logs)：epoch是整数轮次（从0开始），logs含本epoch平均指标
写日志时为什么不能直接用print或open()反复追加？
训练可能中断、重启，也可能多卡并行——print输出易丢失，open(..., 'a')在分布式训练中会因文件锁或缓存导致日志错乱或覆盖。正确做法是用tf.summary写入TensorBoard格式，或用logging模块配FileHandler并设delay=True。如果坚持用文件，必须在on_train_begin里打开一次句柄，存在实例属性中，所有回调方法复用它，最后在on_train_end关闭。
- 错误示例：
open('log.txt', 'a').write(...)——每次调用都新建文件句柄，缓存不刷新，多进程下崩溃 - 推荐方式：在
__init__里初始化self.log_file = open('train.log', 'a', buffering=1)（buffering=1启用行缓冲） - 务必在
on_train_end里调用self.log_file.close()，否则最后一段日志可能滞留内存
如何让自定义Callback兼容TensorBoard和命令行同时输出？
TensorBoard日志和文本日志本质不冲突，但得避免重复计算或写入竞争。最稳的结构是：Callback只负责收集数据（比如把每个batch的loss存进self.batch_losses = []），再由on_epoch_end统一处理——这时既调用tf.summary.scalar写Event文件，也用logging.info打到控制台和文件。
- 别在
on_train_batch_end里直接写TensorBoard：高频写入拖慢训练，且tf.summary默认每5秒flush一次，小batch下数据滞后 - 想看实时batch指标？用
tf.summary.experimental.set_step(batch + epoch * steps_per_epoch)手动设step，再写scalar - 命令行输出建议用
logging.getLogger().info(f'Epoch {epoch}, batch {batch}: loss={logs["loss"]:.4f}')，比print更可控
训练中断后怎么续写日志不覆盖旧内容？
续训本身不改变Callback行为，但日志路径若固定（如'train.log'），新训练会接着写——前提是没在on_train_begin里用'w'模式重开文件。真正的坑在于：TensorBoard的Event文件不能“续写”，它是按时间戳命名的独立文件，所以续训时tf.summary.create_file_writer必须指向同一个logdir，TensorBoard会自动合并读取。
- 文本日志安全做法：
open(log_path, 'a', encoding='utf-8')，永远追加 - TensorBoard安全做法：logdir路径不变，不要清空，让
tf.summary.FileWriter自动管理子文件 - 注意
on_train_begin里别做os.remove或shutil.rmtree，那是初学者最常踩的坑
日志路径和写入时机比内容格式更重要，尤其当模型跑几天才出结果时，漏掉某次epoch的记录可能让你无法判断性能拐点在哪。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
