优先排查是否进入调试器、是否命中断点、是否被异常设置拦截；按ctrl+alt+e启用python异常捕获，勾选“当异常抛出时”；在“工具>选项>python>调试”中启用“始终显示输出窗口”；确认启动项配置、cpython环境及断点位置有效性；子进程需用debugpy显式监听并附加。
Visual Studio 中 Python 代码运行异常，优先排查是否进入调试器、是否命中断点、是否被异常设置拦截——不是所有报错都会立刻弹窗或中断，很多异常默认被静默吞掉或仅输出到 输出 窗口。
异常没中断？检查“异常设置”是否禁用了对应类型
Visual Studio 默认只在“用户未处理的异常”时中断，而像 KeyError、ValueError 这类内置异常，如果出现在 try/except 块里，调试器通常不暂停。你得手动打开异常拦截开关：
- 按
Ctrl+Alt+E打开“异常设置”窗口 - 展开
Python 异常节点（不是 .NET 或 C++ 的） - 勾选你要捕获的具体异常，比如
KeyError、AttributeError；或者直接勾选顶层的Python 异常（慎用，会频繁中断） - 确认“当异常抛出时”复选框已启用（不是仅“当异常未处理时”）
注意：该设置是会话级的，重启调试后仍生效，但切换项目或环境时可能需重新核对。
报错信息只在“输出”窗口闪一下就消失？固定输出窗口行为
默认情况下，Python 脚本执行完，输出 窗口会自动关闭，导致你看不到 traceback。这不是 bug，是 VS 的默认策略：
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
- 菜单栏选择
工具 > 选项 - 展开
Python > 调试 - 取消勾选
进程正常退出时等待输入 - 改设为
始终显示输出窗口（该选项实际位于同一页面，名称为始终显示输出窗口，非“等待输入”）
改完后，即使脚本跑完也保留 输出 窗口，错误堆栈完整可见。若仍看不到，可手动按 Ctrl+Alt+O 唤出它，并在下拉菜单中选 Python Debug 或 Debug 类型。
断点根本没命中的常见原因
断点灰色、不生效、或调试启动后直接跑完——大概率不是代码问题，而是环境或配置错位：
- 确认当前活动 Python 环境是基于
CPython的（IronPython不支持断点调试）；在Python 环境窗口中检查解释器路径是否含python.exe，而非ipy.exe - 确保文件是以“启动项”方式运行：右键文件 →
设为启动项，否则 VS 可能用全局默认环境启动，且不加载项目级调试配置 - 检查代码是否被优化跳过：比如函数内联、
if False:块、或__debug__ == False下的断言——VS 不会在不可达代码行设有效断点 - 避免在
import行、空行、注释行设断点；断点必须落在可执行语句上（如print()、for、def定义后的第一行等）
远程或子进程异常无法捕获？补上 debugpy 显式监听
VS 默认只能调试主进程。如果你的代码启动了子进程（如 multiprocessing）、或调用了外部脚本（subprocess.run），异常不会回传到主调试会话：
- 在子进程入口处（如
target=...函数开头）插入：
import debugpy debugpy.listen(5678) # 端口需与 VS 远程附加配置一致 debugpy.wait_for_client() # 阻塞直到 VS 附加
- 然后在 VS 中使用
调试 > 附加到进程，选择Python 调试器类型，连接localhost:5678 - 注意：子进程需与主进程共用同一解释器路径，且防火墙允许本地端口通信
真正难定位的异常，往往藏在没被 VS 控制的执行上下文中——别只盯着主文件，要主动把调试权“借给”子流程。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
