sys.monitoring 比 sys.setprofile() 更高效，因其绕开全局解释器钩子，采用 c 层事件驱动模型，支持多工具共存、粒度可控的条件监听，但需注意 tool_id 唯一性及回调轻量化。
sys.monitoring 比 sys.setprofile() 更高效，核心在于它绕开了全局解释器钩子机制，改用事件驱动的轻量级注册模型——不是每行都“拦截”，而是只在你明确订阅的事件点上触发回调。
sys.monitoring 的事件分发机制不经过 Python 字节码解释主循环
传统 sys.setprofile() 本质是让解释器在每次函数调用、行执行、异常抛出时，强制跳转到你的 Python 回调函数，这会打断指令流水线，引入大量栈帧开销和对象创建（比如每次都要构造 frame 对象）。而 sys.monitoring 的监听逻辑实现在 C 层，事件由解释器内部直接派发，回调函数只在真正需要时被调用，且支持条件过滤（如仅监听特定函数名或代码对象）。
多工具共存时不会互相覆盖或冲突
旧方式下，多个 profiling 工具（如 line_profiler 和 APM SDK）同时调用 sys.setprofile() 会导致后者被覆盖，只能有一个生效；sys.monitoring 允许每个工具申请独立 tool_id，并分别注册回调，事件会广播给所有已注册监听器。这意味着：
- APM 工具可以监听
sys.monitoring.events.CALL做函数级耗时统计 - 调试器可以同时监听
sys.monitoring.events.LINE实现断点 - 两者互不干扰，也不需要协调谁先设钩子
事件粒度可控，避免无意义采样
sys.monitoring.set_events() 支持按需开启/关闭具体事件类型，不像 sys.setprofile() 一旦启用就全量捕获。例如：
- 只关心函数进入退出？只设
sys.monitoring.events.CALL和sys.monitoring.events.RETURN - 想做行级热点分析？再加
sys.monitoring.events.LINE，但注意这仍比旧 profile 开销低得多 - 完全禁用某类事件？调用
sys.monitoring.set_events(0)即可，无需卸载回调
这种开关能力让生产环境下的动态启停成为可能，而不是“开就全开、关就全关”。
容易踩的坑：tool_id 必须唯一且不能复用
sys.monitoring.use_tool_id() 的第一个参数是整数 ID，必须全局唯一。重复使用同一 ID 会导致前一次注册被静默覆盖，且不会报错。常见错误包括：
- 多个模块都硬编码
use_tool_id(1, ...)，结果只有最后一个生效 - 在子解释器中未重新调用
use_tool_id()，导致监听失效 - ID 超出范围（0–255），引发
ValueError
建议用 hash(__name__) & 0xFF 生成模块级 ID，或直接用 random.randint(1, 254) 避免冲突。
sys.monitoring 开销压到 10% 以下，如果回调里做了 print()、JSON 序列化或网络上报，整体性能照样崩。别把底层优化当万能解药。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
