邮箱迁移最容易丢的是什么：通讯录、日历还是文件夹

迁移里丢掉的很少是某一封邮件，而是邮件之外的那些结构——通讯录的分组、日历的权限与重复规则、文件夹的层级。 原因不复杂：搬家协议本来就不负责搬它们。

一、为什么丢的是「结构」而不是「邮件」

1.1 协议只搬邮件，其余的它不管

一封邮件的正文和附件在协议里是边界清晰的内容块，可以整体识别、整体搬运。而分组、权限、层级这类信息不在邮件里，它们描述的是邮件与邮件之间、人与人之间的关系。

这一点在官方文档里写得很直接：IMAP 类型的迁移只迁移邮件文件夹中的项目，不迁移联系人、日历项和任务 [1]。

所以「邮件搬完了但通讯录是空的」不是工具出了故障，而是协议本来就没打算搬它。把这三类数据的丢失当成事故来排查，方向从一开始就错了；正确的做法是在迁移方案里给它们各自单列一条路径。

阿里邮箱官方文档对搬家这件事的定性也是同一个意思：这是一个复杂的项目，对企业来说牵一发而动全身，需要谨慎对待 [2]。

1.2 三类数据各走哪条通道

数据	走什么通道	邮件搬家协议是否传输	中间格式的表达能力
邮件正文与附件	IMAP 等邮件协议	是 [1]	完整
通讯录	单独导出为 CSV 等格式再导入	否 [1]	CSV 是平面表格，没有表达多级分组与自定义标签的字段
日历	单独导出为 iCalendar 格式再导入	否 [1]	可表达重复规则与时区标识 [5]，但共享权限不属于该格式的范围
任务	与日历同路径	否 [1]	可表达截止时间与重复规则 [5]，指派关系与完成状态取决于两端系统的字段是否对应
文件夹层级	随邮件协议一起，但由目标系统重新解释	部分	取决于两端系统对层级的表达方式是否一致

这张表能解释一个常见困惑：为什么日历「导出成文件了」还是会错。因为导出格式能装下的东西和你在原系统里看到的东西并不等价——重复规则和时区在格式里有位置，共享给谁看这件事没有。

1.3 结构信息没有独立的备份入口

邮件可以整箱导出成一个文件留底，结构信息不行。分组关系、权限设置、层级路径分散在各自的管理界面里，没有一个「导出全部结构」的按钮。

后果是：一旦丢了，只能靠人照着记忆或截图重建。 所以唯一有效的办法是趁还能打开原系统时先留下基准，事后再追查，成本要高得多。

二、通讯录：分组、标签与去重

2.1 三种典型表现

第一种，分组层级被压平。 原来的多级分组（例如按「部门 → 区域 → 客户类型」三层维护）导入后常常变成一个平铺的列表，子分组成了平级标签，层级关系不见了。

根源在中间格式：通讯录通常以 CSV 这类平面表格导出，而 CSV 没有表达父子关系的字段。所以这不是导入环节出错，是导出那一刻信息就已经不完整了。

第二种，同名或多邮箱联系人被合并。 导入时按姓名或邮箱地址判重是常见做法，遇到两个同名的人、或同一个人有多个邮箱地址，就可能被并成一条。这类丢失最难察觉，因为联系人总数只少了一两个。

第三种，自定义标签丢失。 企业自己加的业务标签（客户等级、所属项目、供应商类型等）多数存放在原系统的扩展字段里，通用格式没有对应位置，转换后联系人退回无分类状态。

2.2 官方容量上限

阿里邮箱官方文档给出的通讯录相关上限如下。注意企业通讯录和员工的个人联系人是两套独立的额度，两者的数字恰好相同，容易被看成同一项：

适用范围	项目	标准版	AI 尊享版	出处
企业通讯录	联系人数	12000	30000	[3]
企业通讯录	分组数	200	800	[3]
员工个人联系人	添加限制	12000	—	[4]
员工个人联系人	分组数	200	—	[4]
导入操作	每次可批量导入联系人	500 条	—	[4]

最后一行值得注意：批量导入是按 500 条一批来的 [4]。上万条联系人意味着要分几十批，每批都是一次可能出错的机会——分批越多，越需要在导入后核对总数，而不是凭「导完了」的感觉收工。

2.3 怎么验证有没有丢

迁移前后各做一次，三个数字对上就基本没问题：

核对项	怎么取数	判断标准
联系人总数	通讯录界面的统计数字	前后一致；差 1–2 条也要查，通常是判重合并
分组数量	数分组列表的条数	前后一致
分组层级	迁移前把分组树截图留存	逐层展开对照，确认子分组还在原来的父级下

抽查时优先挑同名联系人和一个人多个邮箱的记录，这两类是判重合并的高发位置。

三、日历：权限、时区与重复规则

3.1 三种典型表现

第一种，共享权限被剥离。 部门共享日历原本设了「仅查看」或「可编辑」，迁移后可能变成谁都能看，也可能变成谁都看不到。前者是信息外泄，后者是协作中断，而共享权限恰恰不在日历导出格式的表达范围内——它属于原系统的权限体系，不属于日历数据本身。

第二种，时区错位。 iCalendar 格式里，事件时间需要配合时区标识才有确定含义 [5]。如果导入时把时间当成了另一个时区的值，整份日历会整体偏移几小时——会议还在，时间错了，而日历界面上看不出任何异常。

第三种，重复规则失效。 「每周一上午十点、法定节假日除外、到年底结束」这样的安排，在格式里是一条重复规则加若干例外规则 [5]。规则没被完整保留时，两种结果都可能出现：周期性会议变成一次性事件，或者被展开成大量独立条目、原来的结束日期和例外全部失效。

3.2 为什么日历是三类里最脆弱的

因为它同时依赖三套彼此独立的信息：共享权限、时间与时区、重复规则与例外。后两项在导出格式里有位置 [5]，共享权限没有——所以后两项的风险是「转换时出错」，共享权限的风险是「根本没被带走」。

而三项里任何一项出问题，日历都不会报错，它照样显示得整整齐齐。这就是「迁移成功、数据已错」最典型的场景，也是三类数据里最需要人工抽查的一类。

3.3 怎么验证有没有丢

核对项	怎么查
共享权限	迁移前把每个共享日历的权限设置截图；迁移后逐个对照，尤其确认原本受限的日历没有变成全员可见
时区	挑几个跨时区的会议，对照原系统看开始时间是否一致；有夏令时地区的更要单独看
重复规则	挑一个复杂的周期会议（带例外或结束日期），确认它仍是一个周期事件、不是一堆独立条目，且结束日期与例外还在
会议附属信息	抽查参与者列表、会议地点、备注和附件是否还在

权限那一项必须在迁移前截图。它不在导出文件里，也没有别的地方能查到原值——没有截图就只能靠记忆恢复。

四、文件夹：层级与大附件

4.1 两种典型表现

第一种，多级嵌套被压平或改名。 一个四级路径（例如 项目文档/2024年度/华北区/已结项）迁移后可能变成同级的四个文件夹，或者被拼成一个长名字的单层文件夹。原因是两端系统对层级的表达方式不一定一致，中间转换时只能取一种近似。

第二种，自建文件夹并入系统目录。 自己建的归档文件夹，如果名字与目标系统的默认文件夹相近，可能被并进去，邮件混在一起无法再按原分类区分。命名规则差异较大时，还存在被误判为系统回收目录的风险。

4.2 官方容量与大小上限

项目	标准版	AI 尊享版	出处
单账号可创建文件夹数	800 个（不含系统文件夹）	3000 个	[3][4]
自定义文件夹子级数	10 级	—	[4]
账号每个邮件夹可存邮件数	100 万封	—	[4]
单账号可存储总邮件数	200 万封	—	[4]
大附件中转站容量	10G	32G	[3]
发信单个超大附件大小	4G	—	[4]
发信普通附件大小	默认 50MB，域管可在 1–60MB 之间配置	—	[4]

这里要纠正一个流传较广的说法：大附件中转站的 10G 是中转站的总容量，不是单个文件的上限。 单个文件受的是另一条限制——发信单个超大附件上限 4G、普通附件默认 50MB [4]。所以超过 4G 的单个文件不存在「被截断」的问题，它根本发不出去。

另外，用 PST 文件做本地留底时还有一层容量天花板：微软官方文档说明 PST／OST 的默认大小上限是 50GB，可通过注册表项调整 [6]。邮箱数据超过这个量级时，一个 PST 装不下，需要分卷。

4.3 怎么验证有没有丢

核对项	怎么查
文件夹树	迁移前截图完整目录树；迁移后逐层展开对照，重点看三级以上的嵌套
每个文件夹的邮件数	迁移前按文件夹记录条数；迁移后逐项对照，而不是只看总数
自建归档文件夹	单独确认它们还是独立目录，没有被并进系统默认文件夹
大附件	抽查带大附件的邮件能否正常下载；超过单封上限的文件应改走其他通道

第二行是最容易省掉也最不该省的一步：只核对邮件总数，无法发现「邮件都在但跑到别的文件夹里去了」这种情况。

五、三类数据的恢复成本对照

数据	丢了之后靠什么恢复	能不能自动恢复	原始信息还在吗
通讯录	迁移前导出的 CSV（分组与标签需人工重建）	联系人条目可以重新导入；分组层级与自定义标签只能手工重建	条目在，结构不在
日历	迁移前导出的日历文件 + 权限截图	事件可重新导入；共享权限只能逐个手工设置	权限没有留底就不在了
文件夹	源邮箱（若仍可访问）或本地 PST	层级需按截图重建后再归位邮件	邮件内容通常在，位置关系要重建

这张表想说明的是同一件事：三类数据丢的都不是内容，是关系；而关系没有任何一种自动恢复途径。

也正因如此，迁移期间源邮箱的可访问性要保住。阿里邮箱官方文档提醒过两点相关的：搬家应当先搬完再切换域名解析；如果先切解析、再陆续搬家，必须确保原邮箱的 IMAP 服务不停止，而原邮箱一旦到期就无法再搬 [2]。

六、常见问题（FAQ）

因为搬家协议不负责搬它。微软官方文档明确，IMAP 类型的迁移只迁移邮件文件夹中的项目，不迁移联系人、日历项和任务 [1]。通讯录需要单独导出为 CSV 等格式再导入，这是一条独立的路径。看到通讯录是空的，不必按故障排查，应当检查迁移方案里有没有给这三类数据各自安排通道。

分组结构在多数情况下保不住，原因在中间格式：通讯录通常以 CSV 这类平面表格导出，而 CSV 没有表达父子关系的字段，所以导出那一刻层级就已经不完整了。可行的做法是迁移前把分组树截图或制表留存，迁移后按记录手工重建，并核对联系人总数与分组数量是否与迁移前一致。

因为共享权限不属于日历数据本身。iCalendar 格式能表达事件时间、时区标识、重复规则与例外规则 [5]，但「这个日历共享给谁、对方能看还是能改」属于原系统的权限体系，不在导出文件里。所以权限必须在迁移前单独截图留存，迁移后逐个手工恢复——没有留底就只能靠记忆。

先对照上限：阿里邮箱标准版单账号最多可创建 800 个文件夹（不含系统文件夹），AI 尊享版为 3000 个，自定义文件夹子级数为 10 级 [3][4]。接近上限时建议先清理或合并冗余目录再迁移。更实际的建议是把层级控制得浅一些，并在迁移前留一份完整目录树截图，作为迁移后逐层对照的基准。

不够。只看总数无法发现「邮件都在但跑到别的文件夹里」这种情况。应当按文件夹逐项核对条数，并单独确认自建归档文件夹没有被并入系统默认目录。通讯录和日历同理：总数对上不代表分组、权限、重复规则也对上了，这三项要单独抽查。

结语

三类数据丢失的共同点在于：丢的不是内容，是关系——分组的父子关系、日历的权限关系、文件夹的层级关系。而协议不搬关系，导出格式装不下全部关系，也没有任何一种自动恢复途径。

所以真正有效的动作只有一个，而且必须在迁移之前做：趁还能打开原系统，把分组树、权限设置、目录树各截一份图，把联系人数、分组数、每个文件夹的邮件条数各记一次。 迁移后逐项对照，这是唯一能在第一时间发现结构偏差的办法。

对缺少专职运维的企业，这类迁移前的结构盘点与迁移后的逐项校验也可以交由本地授权服务商承接。以官方授权的阿里邮箱西南服务中心-大成云为例，其服务范围包含邮箱迁移实施与相关的校验支持 [7]。

References