{expr=}语法需python≥3.8，写法为f"{x=}"（等号紧贴右括号），支持格式说明符与repr，但有副作用、兼容性及可读性边界限制。
f-string 中 {expr=} 语法怎么写才不报错
必须确保 Python 版本 ≥ 3.8，否则直接 SyntaxError: f-string: invalid syntax。这个语法是 3.8 新增的“自描述表达式”，不是所有 IDE 都能实时识别，PyCharm 2020.1+、VS Code + Pylance 可以高亮，但旧版可能标红误报。
写法很简单：f"{x=}" 等价于 f"x={x}"，但注意：等号必须紧贴右大括号，不能有空格 —— f"{x = }" 是非法的，会报错。
f"{x=}" → "x=42"-
f"{x!r=}" → "x='hello'"（带 repr） -
f"{x:.2f=}" → "x=3.14"（支持格式说明符） - 多个表达式可以并列：
f"{a=}, {b=}, {c**2=}"
为什么 {expr=} 有时输出结果和预期不符
本质是先求值再拼字符串，所以表达式里的副作用（比如函数调用、赋值、print）每次都会执行 —— 这和普通 f-string 一样，但容易被忽略，尤其在调试时反复触发。
常见陷阱：
立即学习“Python免费学习笔记（深入）”；
-
f"{print('hi')=}"会真的打印hi，然后输出print('hi')=None -
f"{x:=x+1=}"合法但危险：x被修改一次，且输出含原始值还是新值？取决于求值顺序（实际是先算右边再拼，所以x:=x+1先执行，再把新值代入） - 嵌套表达式如
f"{func(x).attr=}"，如果func(x)返回None，会立刻抛AttributeError
和手动拼接比，{expr=} 的性能与可读性取舍
性能上基本无差异，底层都是编译期解析 + 运行时求值；但可读性在调试场景下明显更好：省去重复写变量名，减少手误，也避免 f"x={x}, y={y}, z={z}" 这种冗余。
不过要注意适用边界：
- 适合快速调试、日志打点、单元测试失败信息（比如
assert x == y, f"{x=} != {y=}"） - 不适合生产环境敏感日志 —— 因为表达式可能含隐私数据或引发副作用
- 不推荐用于复杂逻辑表达式，比如
f"{[i for i in range(10) if i % 2 == 0]=}"，可读性反而下降，且不易调试中间状态
兼容性与工具链注意事项
Black、Ruff、pylint 默认支持该语法（最新稳定版），但旧版 linter 可能报 invalid syntax 或跳过检查。CI 中若用多版本 Python 测试，3.7 及以下会直接失败，不能靠 try/except 捕获 —— 语法错误发生在编译阶段。
真实项目中建议：
- 团队统一 Python 版本 ≥ 3.8 后再启用
- 配置
pyproject.toml中requires-python = ">=3.8" - 不要混用风格：同一文件里避免既有
f"x={x}"又有f"{x=}"，维护时易混乱
最常被忽略的是格式化精度控制 —— f"{x:.3f=}" 输出的是 x=3.142，但如果你本意是想对原始值截断再显示，得确认 x 本身是否已足够精确，否则只是“假装精确”。
