导出 Redux slice 报 WritableNonArrayDraft cannot be named

导出带递归状态的 Redux slice，普通开发运行没有异常，生成类型声明时却报 WritableNonArrayDraft 无法命名。错误通常包含 has or is using name 与 cannot be named，要检查 Immer 的声明导出，不应先把递归状态改成 any。

Immer 11.1.3 在 WritableDraft 的实现中引入 WritableNonArrayDraft，但正式 d.ts 的公开导出列表没有包含它。声明生成器展开 slice 类型以后，需要写出这个内部名字，却找不到可公开引用的入口。

源文件加了 export，不代表发布声明已有它

11.2.2 的类型源曾增加相关导出，但正式 dist/immer.d.ts 仍没有在最终 export 列表公开这个名称。只看源码或版本更新说明，容易误以为这一版已经完整解决。

截至 2026 年 10 月 26 日，正式 11.2.9 的 d.ts 已在最终导出列表包含 WritableNonArrayDraft。可沿工程兼容范围采用包含完整声明导出的版本，并检查实际失败工作区解析到的文件。

npm ls immer @reduxjs/toolkit

工作区、包管理器提升规则和 Redux Toolkit 的依赖副本都可能影响结果。根项目安装了新 Immer，不保证声明生成器在子包里看到同一份；应结合锁文件与错误中的真实路径判断。

仍要运行原来的声明生成任务

这个问题常见于导出 slice 且状态包含自引用的组合。仅重新启动 Vite、浏览器页面正常，不能覆盖 unplugin-dts 等工具生成 d.ts 的失败路径。

更新后执行项目既有的类型检查和声明构建，再检查生成包是否能被另一个真实消费者解析。不要只加 skipLibCheck：错误可能发生在为本项目导出生成声明的阶段，并不是单纯检查依赖内部代码。

无法立刻更换依赖时，可评估按已有公共 API 明确声明对外类型，避免让内部推导细节泄漏，但必须保留 slice 的 reducer、action 与状态类型关系。随手断言 any 或删除递归字段，会牺牲本来要交付的类型约束，不是等价修复。

也不建议手工复制另一个版本的 d.ts 进 node_modules。声明、源码与运行时版本需要对应；补丁若确实不可避免，应通过工程原有的包补丁流程保存、审校，并保留原锁文件供恢复。

验收保留递归状态、导出的 slice 和原来失败的声明打包入口，确认生成文件不再引用不可导入的内部名称，消费者仍能获得正确状态与 action 参数检查。它不同于整个发布物没有声明文件的情况，本题是文件存在、内部名称也存在，但缺少公开导出。