IPykernel 辅助线程日志总出现在初始化单元格，检查输出上下文

在第二个 notebook 单元格初始化队列日志器，第三个单元格写日志，输出却一直出现在第二个单元格下方。若日志由长驻辅助线程写到 sys.stderr，应检查 IPykernel 的输出归属，而不是先改日志格式或文件路径。

IPykernel 6.29.0 的线程输出路由曾把输出与线程创建时的单元格关联。7.1.0 恢复了默认采用最近单元格的行为；当前正式 7.4.0 仍会优先使用线程或任务上下文中的 parent header。自由线程 Python 默认继承调用者上下文时，旧的单元格归属仍可能随日志线程一起被带入。

先确认日志真正在哪里写出

主线程里的 logger.log() 可能只是向队列放入字符串，实际 sys.stderr.write() 发生在另一个线程。初始化日志器的单元格与提交日志的单元格因此不是同一个写入现场。关闭日志排队或换成直接写出，可以用于判断差异，但也会改变阻塞、并发和日志处理方式，不能未经评估就改所有应用日志。

普通 CPython 环境使用较旧 IPykernel 时，可以评估升级到含 7.1.0 输出路由变更的兼容版本；当前 7.4.0 要求 Python 3.11 及以上。安装后要重启实际 notebook 内核，并确认它使用的环境已经更新。只更新 Jupyter 前端所在环境，不会自动替换另一个环境中的内核。

如果项目显式为线程设置过 parent header，就需要按原有绑定逻辑检查，不能要求升级取消应用主动指定的输出归属。

自己创建日志线程时，明确初始上下文

Python 3.14 起，threading.Thread 支持 context 参数。独立的队列写入线程若不应继承创建者的单元格上下文，可以在创建它时使用新的空 Context。下面只展示线程入口，drain_queue 代表应用已有、能按停止信号正常结束的队列消费函数：

from contextvars import Context
from threading import Thread


def make_log_thread(drain_queue):
    return Thread(target=drain_queue, context=Context(), daemon=False)

由调用方启动、发送停止信号并 join()。空上下文会同时移除其他 ContextVar 的继承，包括项目可能需要的追踪信息；这些上下文应按业务需要显式传递，不能为了修单元格位置而悄悄丢掉所有请求标识。第三方日志器内部创建的线程，也不会因为应用另建一个空上下文线程就自动改变。

这个参数不能直接用于 Python 3.13 及更早版本。自由线程与常规构建的默认继承设置不同，还要核对是否有库主动使用 copy_context()；不能仅凭 Python 版本推断线程一定为空或一定继承。

最近单元格也不等于最初触发日志的单元格

取消固定归属后，延迟日志可能出现在输出时最近执行的单元格，而不是最早提交任务的那个。需要严格的任务来源时，应在日志事件里保存任务或请求标识，或使用专门的日志面板；流式输出无法从一个普通字符串反推原请求。

核对时分开执行初始化、第一次写入、再次写入三个单元格，并等待辅助线程消费队列。还要检查切换到其他单元格后才产生的延迟输出，以及线程关闭时是否清空队列。单独在一个单元格里完成初始化和写入，无法区分这些归属行为。