tensorflow 2.x 默认启用 eager execution，tf.executing_eagerly() 返回 true 是正常状态；关闭它会破坏原生代码运行，@tf.function 是优化手段而非替代方案；频繁使用 .numpy() 会导致同步开销。
因为Eager Execution是TensorFlow 2.x的交互式开发基础，不是可选特性，而是设计前提。
tf.executing_eagerly() 返回 True 是正常状态，不是 bug 或配置错误
调用 tf.executing_eagerly() 得到 True，说明一切按预期运行。这不是“意外开启”，而是 TensorFlow 2.x 启动时自动完成的初始化行为。只要你没显式调用 tf.compat.v1.disable_eager_execution()，它就该是 True。
常见误解是把它当成一个“开关”——其实它更像一个运行时标识：就像 Python 的 sys.version_info 显示版本一样，tf.executing_eagerly() 只是告诉你当前执行模式，不参与控制逻辑。
关闭 Eager Execution 会立刻破坏多数 TF 2.x 原生代码的运行
一旦执行 tf.compat.v1.disable_eager_execution()，以下情况会立即发生：
-
print(tf.constant(1) + 2)不再输出数值，而是Tensor("add:0", shape=(), dtype=int32) -
if x > 0:中的x是张量，Python 无法直接判断布尔值，会报错Attempting to use a tensor as a Python boolean -
tf.GradientTape()失效——它依赖 eager 下的即时记录，静态图中必须改用tf.gradients()配合tf.Graph -
model(x)不再返回结果，而是返回一个未执行的Operation对象，后续必须手动构建Session才能运行
@tf.function 是性能优化手段，不是 Eager 的替代方案
有人误以为“关掉 eager 就快”，实际真正提速靠的是 @tf.function 编译：
-
@tf.function把一段 eager 写法的函数（含for、if、甚至print）转成优化图，首次调用有 tracing 开销，之后复用 - 输入 shape/dtype 变化会触发新 trace，变长序列需用
input_signature约束，否则反复 retracing 反而更慢 - 训练循环里只应包裹最内层（如单步前向+反向+更新），而不是整个
train_step都包——那样会锁死动态逻辑
真正容易被忽略的点：eager 下的张量与 NumPy 互操作是默认行为，但有隐含代价
.numpy() 看似方便，但它会同步设备（GPU/CPU），强制等待计算完成，频繁调用会严重拖慢训练速度：
- 调试时用
print(x.numpy())没问题，但训练循环里写loss.numpy()记 log，等于每步都做一次 GPU→CPU 拷贝 - 用
tf.print()替代print()可避免同步，但输出在日志中而非 stdout，且不支持格式化字符串 - 想检查 shape/dtype？直接读
x.shape和x.dtype，无需.numpy()
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
