用 breakpoint() 最省事但易忘删，推荐 if condition: breakpoint()、-m pdb 手动设断点；logging.debug 不输出因默认级别为 WARNING，需提前 basicConfig；print 线程不安全，应改用带上下文的 logging；生产环境 bug 多源于环境差异，需打全量日志并启用 faulthandler。
怎么用 pdb 在关键位置中断而不打断流程
直接在代码里插 breakpoint() 最省事，但容易忘删、上线出事。真正在复杂逻辑里调试，得靠条件断点和临时启用。
- 用
if condition: breakpoint()替代无脑插入，比如只在某次循环或特定输入时停住 - 启动时加
-m pdb（如python -m pdb script.py），再用b filename.py:42手动设断点，比硬编码更可控 - 别依赖 IDE 自带的图形断点——多进程、子线程、信号处理场景下，
pdb命令行反而更稳 -
breakpoint()在 Python 3.7+ 默认调用pdb.set_trace()，但环境变量PYTHONBREAKPOINT=0可一键禁用，上线前不用手动删
logging.debug() 为什么总不输出
不是日志没写对，大概率是根 logger 的默认级别卡在 WARNING，debug 消息直接被过滤了。
- 必须显式调用
logging.basicConfig(level=logging.DEBUG)，且得在任何logging.debug()调用之前执行 - 如果用了第三方库（比如
requests或sqlalchemy），它们可能有自己的 logger，需单独设级：logging.getLogger("requests").setLevel(logging.DEBUG) - 别在模块顶层写
logging.debug("x")—— 模块导入时就执行，但此时 logging 还没配好，消息永远丢失 - 调试期可临时加
force=True参数（Python 3.8+）：logging.basicConfig(level=logging.DEBUG, force=True)，避免被其他库提前初始化干扰
多线程/协程里 print 不可靠，该用什么替代
print 是线程不安全的，尤其在高并发或 asyncio 环境下，输出会错乱、截断甚至消失；它也不带上下文，看不出哪条日志来自哪个任务。
- 统一换成
logging，并开启%(threadName)s或%(name)s格式字段，一眼区分来源 - asyncio 场景下，避免在
async def里直接调用阻塞型 logger（极少见），但更常见的是忘记给每个 task 命名：asyncio.create_task(coro(), name="fetch_user")，然后用%(name)s记录 - 临时调试时，可用
sys.stderr.write(f"[{threading.current_thread().name}] msg\n")，比 print 少一层缓冲，也更轻量 - 别用
print(..., flush=True)应对乱序——能缓解但不治本，且在协程中可能触发 RuntimeError
怎么快速定位“只在生产环境出问题”的 bug
本地跑不出 ≠ 代码没问题，大概率是环境差异：时区、编码、文件权限、系统调用返回值、甚至浮点数精度。
立即学习“Python免费学习笔记（深入）”；
- 加一行
logging.info(f"sys.platform={sys.platform}, sys.version={sys.version}, locale={locale.getpreferredencoding()}")，上线前先看基础信息是否一致 - 把关键路径的中间值打到日志里，但别打敏感数据；用
repr(x)而不是str(x)，能看出None、空字符串、不可见字符等 - 检查
os.environ差异，尤其是LC_ALL、TZ、PATH—— 很多“本地 OK 生产炸”源于命令行工具找不到或行为不同 - 用
faulthandler.enable()开启崩溃堆栈捕获，SIGSEGV/SIGABRT 这类底层错误，普通 try-except 捕不到
真正难缠的，往往藏在环境变量、系统库版本、甚至 CPU 架构导致的整数溢出或内存对齐差异里——日志得多打几层，别只信最后一行报错。
