Windows autoreload 读 UTF-8 源码报 cp1252 解码错误

模块本来可以导入，开启 autoreload 后却在读取源码时报 UnicodeDecodeError: 'charmap' codec can't decode byte 0x81，堆栈指向 IPython/extensions/deduperreload 和 Windows 的 encodings/cp1252.py。先确认错误是在重新读取 .py 源码，还是业务自己打开的数据文件。

Python 3.11、3.12 的 Windows 环境在未启用 UTF-8 模式时，普通 open(path, "r") 可能使用默认代码页。Python 导入系统能按源码编码规则读取的文件，autoreload 若走普通默认编码读取，仍可能失败。UTF-8 编码的下标字符等内容就能触发这一差异；错误字节本身不证明文件损坏。

采用与解释器兼容的源码读取修正

IPython 9.10.1 的正式实现已经在相关读取处明确指定 UTF-8。9.17.1 则使用 tokenize.open()，遵守 Python 源码编码声明并在没有声明时按 UTF-8 处理。版本选择还需满足当前解释器和项目依赖，不能只因较新版本有修正就忽略它的 Python 要求。

更新的是实际内核使用的 IPython 环境；Jupyter 前端与内核可能来自不同虚拟环境。保留当前工作和依赖锁文件，更新后重新启动对应内核，再从头加载模块与 autoreload。已有进程保留的旧实现不会自动换成新代码。

不要把合法源码改成二进制读取

把文件以 rb 打开能取得字节，只说明没有发生文本解码，不代表 autoreload 可以直接拿字节替代源码文本。修改 site-packages 的读取模式，也容易让后续语法分析收到错误类型。

如果文件本来按 UTF-8 保存，不需要为了迁就 cp1252 把注释里的中文或 Unicode 字符删掉，也不应把所有源码转成系统代码页。对于有有效编码声明的非 UTF-8 源文件，应使用遵守该声明的读取实现，不能一律强行 UTF-8 后忽略错误。

errors="ignore" 会改变源码文本，可能删除标识符或字符串的一部分；严格读取失败应保留异常，而不是让修改后的内容继续参与重载。

UTF-8 模式只能作为有范围的环境选择

在确实统一使用 UTF-8 文本的进程中，启动前设置 PYTHONUTF8=1 可以改变普通文本读取的默认编码，但它影响的不只有 autoreload。原任务若还读依赖本地代码页的旧文件，这个变化可能引入另一类解码问题。对已经运行的内核，仅在单元格中修改变量不会重新初始化 Python 的启动模式。

有明确源码读取修正可用时，优先修正对应 IPython 环境，不以进程级默认值掩盖第三方读取路径。

重新编辑一次实际模块再验收

用已知编码、含原先触发字符的受控模块，先正常导入，再按应用原来的 autoreload 模式修改与重载，核对函数行为确实更新。只确认 %load_ext autoreload 不报错，还没有覆盖之后真正读取变更源码的步骤。

如果仍失败，保留新的文件路径、编码声明及完整解码器名称；读取截断文件或业务 GBK 文本，与本题源码重载默认编码不一致应分别处理。