Python 3.11 的 traceback 可精确到出错字符的列位置，如 SyntaxError 附带 ^ 指向具体字符；需原生解释器环境、未被 IDE/Jupyter 重写 traceback、动态执行时传入 filename 和源码，且自定义异常处理器须显式使用 exc_value.offset 渲染。
Python 3.11 的 traceback 精确到哪一行哪一列
Python 3.11 默认启用增强型 traceback，能定位到语法错误的**具体字符位置**（而不仅是行号），比如 SyntaxError: invalid syntax 会附带 ^ 指向出错字符。这依赖于新引入的 ast.PyCF_ALLOW_INCOMPLETE_INPUT 和底层解析器对错误偏移量的保留——但前提是没被上层工具吞掉原始异常。
为什么你的 IDE 或 Jupyter 里看不到精确列指示
常见原因不是 Python 本身失效，而是运行环境拦截并重写了 traceback：
- Jupyter 默认用
IPython.core.ultratb.VerboseTB渲染，需手动启用：在 notebook 单元中执行%config TerminalInteractiveShell.showtraceback = True并重启 kernel - 某些 IDE（如旧版 PyCharm）仍使用自己的语法检查器，绕过 Python 解释器的原生报错；确认设置中关闭「Use IDE’s parser for syntax errors」类选项
- 通过
exec()或compile()动态执行代码时，若未传入filename参数，lineno和offset会丢失，导致 traceback 退化为仅显示行号
手动触发并验证精确 traceback 的最小可复现实例
直接在终端运行以下命令，观察报错是否带列指示：
python3.11 -c "print('hello'; print('world')"正确输出应类似：
立即学习“Python免费学习笔记（深入）”；
File "<string>", line 1
print('hello'; print('world')
^
SyntaxError: '(' was never closed注意 ^ 准确指向分号前的左括号——这是 Python 3.11 新增的 AST 错误定位能力。若没看到 ^，说明当前环境未使用原生解释器或被包装过。
在自定义错误处理器中保留列偏移信息
如果你写了自己的 sys.excepthook，必须显式访问 exc_value.__cause__ 或 exc_value.__traceback__ 中的 tb_lineno 和 tb_lasti 不够，要读取 exc_value.msg 和 exc_value.text（后者是出错行原始字符串），再结合 exc_value.offset 手动渲染 ^：
import sys
def custom_hook(exc_type, exc_value, tb):
if issubclass(exc_type, SyntaxError) and exc_value.offset is not None:
print(exc_value.text)
print(" " * (exc_value.offset - 1) + "^")
else:
sys.__excepthook__(exc_type, exc_value, tb)
<p>sys.excepthook = custom_hook关键点：exc_value.offset 在 Python 3.11+ 中始终存在且可靠，但旧版本为 None；不要依赖 traceback.format_exception() 的默认输出，它会丢弃 offset。
真正容易被忽略的是：即使启用了 Python 3.11，只要代码经过任何一层字符串拼接、模板填充或动态 exec，且未显式传入 filename 和原始源码行，列定位就会失效——这不是 bug，是设计使然。
