Whizi聊天导入报错：ChatGPT或Claude导入为什么被拒绝

简短答案

如果Whizi拒绝了你的导入，先检查你选的文件：Whizi只读取ChatGPT或Claude导出包里的conversations.json，所以要先解压导出包，选中那个文件本身，而不是直接选中压缩包。除此之外，导入失败只会出在两个环节之一，报错的措辞会告诉你是哪一个：读取你导出文件的浏览器解析器，或者接收解析器产出的对话内容的导入接口。文件类报错说的是你选的文件本身。上传类报错说的是网络或登录状态。中间没有含糊地带，因为每一条报错信息都是绑定单一条件的固定字符串。

在重试之前还要知道第二件事：重新运行一次导入，绝不会让聊天记录重复。每一段导入的对话都以账号、来源和来源ID作为唯一标识，所以不管是把同一个导出包导入两次，还是在连接中断后恢复导入，或者连续点两次“导入”，最终落地的都是同一批聊天，只会出现一次。

你看到的现象	失败发生在哪一步	该怎么做
一条关于导出格式或conversations.json的报错	读取你的文件时，还没有任何内容上传	从导出包里换一个文件试试，具体做法见下表
一条关于登录状态或网络连接的报错	上传过程中途	重新登录或重新连接网络，再运行一次导入
一个“有多少段对话未能导入”的计数	部分批次重试后依然失败	再运行一次导入，它只会补上缺失的部分
什么提示都没有，但耗时很长	触发了限流，这是设计好的行为	耐心等待，导入程序会自动重试

读取导出文件时出现的报错

这些报错来自浏览器，此时还没有一个字节离开你的设备。导出文件本身从不会被上传：浏览器会先解析它，只把标准化后的对话内容发出去，所以这一类报错意味着文件根本还没走到能被发送的那一步。

信息	触发条件	解决办法
该文件不是ChatGPT或Claude导出文件，请在导出压缩包内查找conversations.json。	解析器无法识别任何一种导出格式，或者压缩包解出的内容无法识别	打开导出压缩包，专门选中conversations.json这个文件
该压缩包内没有conversations.json，请解压后直接选中这个文件。	你选中的压缩包里没有匹配的文件	自己先解压，找到conversations.json，再选中这个文件
该文件不是有效的JSON，因此没有任何可读取的内容。	选中的文件无法按JSON格式解析	重新从ChatGPT或Claude下载导出包，再从里面选中conversations.json
该导出包中没有包含文本内容的对话。	导出包能被解析，但对话数量为零	这份导出包本身就没有文本记录，Whizi这边没有需要修复的地方
该文件对浏览器来说太大，无法打开。请改用导出的.zip压缩包，它会被逐个文件读取。	选中的原始.json文件超过了浏览器的读取上限	改选.zip压缩包。原始.json导出文件最多支持300MB，而.zip路径本身没有上限，因为只有conversations.json这一项会被解压
无法读取该文件，请重试。	文件读取因其他原因失败	这是真正需要重试的情况。如果同一个文件反复出现，请改选导出的.zip压缩包，它会被逐条读取

第一条信息范围最广，因为一个字符串涵盖了两种情况：解析器无法识别的导出格式，以及压缩包解出无法识别的内容。这两种情况的解决办法相同，都是解压导出包，直接选中conversations.json。

上传环节本身出现的报错

文件解析完成后，导入程序会分批把对话上传出去。这个环节可能出两种问题，而且都可以恢复。

信息	触发条件	解决办法
你的登录状态已过期，请重新登录后再开始导入。	导入进行到一半时，令牌获取没有返回结果	重新登录，再重新开始导入。已经导入成功的部分会保留，重新运行时会跳过它们
导入未能完成，请检查网络连接后重试。	导入过程中出现的其他上传失败	检查网络连接，再运行一次

还有第三种结果，它根本不是报错，而是一份汇总：{count}段对话未能导入，请再次运行导入以补齐。这是重试多次仍然失败的批次数量。这条信息里的指示本身就是完整的解决办法，简短答案里提到的去重机制正是第二次运行不会产生任何额外成本的原因。

导入接口返回的报错

以下是导入路由本身产生的代码和字符串。网站端会镜像同样的上限，并在上传前先做校验，所以只有在有内容直接发往接口，或者某个批次格式有误时，这些信息才最重要。

代码	信息	触发条件
invalid_import	请求体必须是一个JSON对象。	导入的请求体不是一个对象
invalid_source	导入来源必须是chatgpt或claude。	source字段缺失，或者不属于这两个受支持的来源
empty_import	至少需要一段对话。	conversations数组缺失或为空
too_many_conversations	本批次包含{count}段对话，超过了每次请求25段的上限。	一次请求里的对话数超过25段
too_many_messages	对话{n}携带了{count}条消息，超过了每次请求400条的上限，请把其余部分作为追加内容发送。	一次请求里某段对话的消息数超过400条
invalid_import	对话{n}不是一个对象。	conversations数组中的某一项不是对象
invalid_import	对话{n}没有messages数组。	某段对话没有携带messages数组
invalid_import	对话{n}的追加目标无效。	appendTo字段既不是字符串也不是null
invalid_message	对话{n}的消息{m}不是一个对象。	某条消息不是对象
invalid_message	对话{n}的消息{m}需要一个“user”或“assistant”的角色。	某条消息的role不属于这两种之一
invalid_message	对话{n}的消息{m}没有文本内容。	该消息的content不是字符串
request_too_large	请求体过大。	JSON请求体超过了路由的字节上限，无论是按声明的Content-Length，还是按实际读取的字节数

这些报错背后的上限是：每次请求最多25段对话，每段对话每次请求最多400条消息，请求体最多2,000,000字节。网站端的导入程序会严格按25和400来切分，并把每次请求控制在1,200,000字节以内，刻意低于2,000,000字节的上限，为请求本身的其他部分留出空间。超过400条消息的对话不会被拒绝，而是会被切片：剩余部分会作为追加切片，接到第一个切片创建的那段聊天上。

大批量导入会每次暂停20秒

导入对话的限流规则是每位用户每分钟20次请求。数量大的导出包会触及这个上限，这是预期行为，不代表出了问题。

触及这个上限时你不会看到任何报错。收到HTTP 429的导入请求不会被展示出来：客户端会等待20秒后重试，每个批次最多重试4次。所以，一份大导出包看起来每次都要停顿二十秒，这正是它该有的表现，让它继续跑就好。

如果某些批次在这4次重试之后依然失败，它们会体现在{count}段对话未能导入，请再次运行导入以补齐。这条汇总信息里，再运行一次导入才是解决办法，不需要联系支持团队。

导入功能会刻意丢弃哪些内容

有些内容是被设计成丢弃的，所以一次“成功”的导入，和原始记录相比看起来仍可能不完整。

对于ChatGPT导出包，只有当时显示在屏幕上的那条分支会被导入。重新生成的回复和被丢弃的草稿不会被当作消息重放。非对话正文的内容也会被跳过：隐藏的推理过程、分析工具的代码与输出、浏览类草稿区、自定义指令区块，以及函数调用。

对于Claude导出包，思考区块、工具调用和附件都会被丢弃，只有文本区块会被导入。

文件中没有可读文本的对话，会被计数并报告为“已跳过”，而不是被悄悄丢弃，所以跳过计数是一种信息，而不是失败。

没有可用标题的对话会被命名为已导入的聊天，超过120个字符的标题会被截断。超过内容长度上限的导入消息会被截断，而不是被拒绝，所以一条超长消息不会连累整段对话的其余部分。

最后是时间戳：导入消息如果日期早于2015年1月1日，或者日期在未来，这个时间戳会被丢弃，该条记录会回退使用导入发生的时间。如果某段聊天落地后显示的是你运行导入那天的日期，而不是原始日期，就是触发了这条规则。

为什么再次运行导入是安全的

简短答案里提到的去重标识有一个兜底方案。当导出包没有给出稳定的对话ID时，标识会改用对话文本本身的哈希值，所以再次运行时依然能匹配到这些对话，而不会新增一份重复副本。

有一个后果需要知道：删除一段已导入的聊天，再重新导入同一份导出包，会让这段聊天重新出现，而不会被判定为重复。如果你是特意删除了某段已导入的对话，除非你希望它再回来，否则不要重新运行那份导出包。