xarray 连开两个内存流后 pickle 失败：先结束懒文件状态

同一进程里用两个 BytesIO 等类文件输入先后打开 SciPy 后端 Dataset，再把第一个仍打开的对象交给 pickle.dumps() 或作为进程池结果返回，报 flush_only_netcdf_file 的 not the same object。先确认输入是内存流等带 seek() 的类文件对象，再处理懒数据与文件生命周期，不要只把 worker 函数移到模块顶层。

xarray 2026.4.0、SciPy 1.16.3、Python 3.13 的组合有这条具体失败路径。SciPy 后端在打开时创建一个内部文件类，并把它登记到同一限定名称；第二次打开换成另一个类对象，第一次打开所持对象仍属于旧类。pickle 按模块名称找回类型时，发现登记对象与实例类型不一致。

普通字符串文件路径使用 CachingFileManager，而带 seek() 的类文件输入会以 flush_only=True 打开，使用上述子类并由 DummyFileManager 持有。两者的序列化资源路径不同，不能把所有磁盘路径连开数据集都概括为同样的失败。

数据量可控时，先加载并关闭后端

如果任务只需把数据带到另一个进程，可以在提交之前将需要的范围加载到内存，并结束文件关联：

import io
import xarray as xr

first = xr.load_dataset(io.BytesIO(payload), engine="scipy")
second = xr.load_dataset(io.BytesIO(payload), engine="scipy")
detached = first

payload 代表已有、可信、大小可控的 NetCDF3 字节，不是待加载的 pickle。这段保留了内存流输入：load_dataset 每次完成打开、加载与关闭，第一次返回的对象不会保持原先的活跃后端状态。随后再把 detached 交给原来的可信进程通道。这里为了说明两次读取而使用同一份字节，实际任务仍按自己的输入组织。

大型数据不应仅为序列化方便而无条件全量读入。需要的范围更小时，应在受控读取流程中先选范围、再加载，并在传输前关闭对应读取对象。

只调用 .close() 却没有先加载，可能使后续首次读取失去必要资源；只调用 .load() 却让后端状态继续附着，也未覆盖这里完整的处理条件。不要篡改 _PickleWorkaround 或动态类的 __qualname__ 来迁就一次序列化，那会影响同进程其他已打开对象。

需要惰性处理时，传递输入描述更合适

任务如果本来应该在 worker 中读取文件，可以传文件路径、所需变量及选择参数，由 worker 自己打开、使用和关闭。这样不必让父进程持有的懒文件对象跨过进程边界，但工作进程必须能够访问同一输入，且不能让文件在读取中被替换。

数据库 blob 或内存流应按既有协议传递稳定字节，再由目标进程创建自己的读取对象。不要把一个正在被其他代码 seek 的共享 BytesIO 当作独立输入。传字节也有复制和内存成本，需要按实际大小评估。

同进程先后打开两个对象，才能覆盖触发顺序

验收保留“两次打开、再传较早对象”的顺序，并覆盖真实进程池返回路径。检查接收方读取到的数据、坐标和属性，而不是只看 pickle.dumps() 是否完成。不同进程的 xarray、SciPy 和应用模型版本也应一致。

正式 xarray 2026.9.0 的 SciPy 后端仍在打开函数内建立并重新登记该类，类文件输入仍采用上述持有方式；不能把某个后续版本号直接当作已消除这条身份问题。加载关闭或进程内重新读取的安排仍需按原负载验证。

pickle 继续只用于应用原有的可信数据通道，不为排错增加加载外部不可信 pickle 的入口。若之前已经有部分导出完成，应按输出记录处理重试，不能因主进程拿到异常就重复执行整个写入批次。