文件分片上传与断点续传：企业云盘大文件传输的技术方案
上一次遇到大文件上传卡死的问题，是一个工程设计院的技术负责人找过来的。他们有个3GB的CAD图纸包要传给外地施工方，用某网盘上传到2.1GB时断网了。重新连上之后，文件从头开始传，又卡在同一个位置。反复三次，对方直接用快递寄硬盘了。
这不是个例。超过2GB的单文件传输失败，是企业云盘投诉里排前三的问题。原因很简单：传统HTTP上传基于单一连接，整个文件作为一个请求体发送，一旦中断只能从头再来。大文件传输的可靠性问题，在文件体积超过某个临界点之后，变得尤为突出。
本文拆解文件分片上传与断点续传的技术原理，分析企业云盘在这件事上需要解决的核心问题，以及实际生产环境中的关键实现细节。内容比较偏技术实现，适合技术选型人员、运维负责人以及对云盘技术原理感兴趣的读者。
一、为什么大文件上传总是卡在同一个位置
TCP连接在传输过程中会经历多个阶段：建立连接时的三次握手、数据传输时的拥塞控制、丢包后的重传机制。在理想的网络环境下，这些都不需要用户关心。但企业的实际网络环境，远不是理想的。
很多企业的出口带宽有限，同时有几十上百人共用一个出口带宽。当某个大文件占满了可用带宽，其他人的请求就会排队。由于TCP的拥塞控制机制，带宽被大文件占用之后，恢复需要时间。更要命的是，企业内网往往存在多层NAT设备和防火墙，HTTP连接在经过这些设备时，连接状态可能会被清理。长时间占用同一个连接，容易触发防火墙的会话超时机制，导致连接被强制断开。
还有一个容易被忽视的因素：服务端的上传处理超时设置。大多数Web服务器默认的请求超时时间是30秒到5分钟不等。对于一个小文件来说足够了，但对于一个3GB的文件，即使带宽足够，处理请求的时间也会远超这个阈值。服务端超时断掉连接，客户端还蒙在鼓里，继续往一个已经失效的连接写数据。
有个真实案例可以说明这个问题：一家媒体公司的视频团队，用云盘上传一个4GB的纪录片素材包，每次传到大概3.2GB左右就断了。换了几家网盘都是同样的结果。最后他们排查发现，公司的防火墙对单连接的最大时长限制是40分钟，而4GB文件在他们的上传带宽下需要70分钟左右。连接被防火墙强制断开，是问题的根因。他们当时的解决方案是联系IT部门临时调整防火墙策略，但每次传大文件都要走这个流程，非常折腾。
分片上传的核心思路，就是把一个大的文件切分成若干小块，每块独立上传。每块上传完成就落盘，即使整件事中途断了，已完成的部分不需要重新传输。这就是断点续传的基础。
二、分片上传的技术机制：从切分到合并
2.1 文件切分的策略
分片大小的选择，是第一个需要决策的技术点。太小的分片会带来大量的HTTP请求开销，每一次请求都有建立连接、传输数据、等待响应的固定成本。如果分片只有256KB，传输一个2GB的文件需要发起8192次请求，每一次请求的握手和确认开销会成为主要瓶颈。
这里有一个具体的数字可以帮助理解：假设一个HTTP请求的建立和确认开销是30ms（包含DNS解析、TCP握手、TLS协商和请求确认），对于256KB的分片，在100Mbps带宽下实际传输时间约20ms。如果分片只有256KB，传输时间远小于开销时间，大量时间浪费在等待上。换成8MB的分片，实际传输时间约640ms，开销同样是30ms，效率就高得多。
太大的分片则会导致重传成本过高。假设分片大小是512MB，传输到400MB时断了，已经传好的400MB需要重新传，因为512MB的分片无法拆散。这个”粒度”问题直接影响续传效率。打个比方：一箱货物重500公斤，海运时船沉了，损失是整箱货物。如果拆成100个5公斤的小包裹，船沉了只损失5公斤，其他95个包裹安然无恙。分片就是这个道理。
业界常见的分片大小在4MB到16MB之间，具体数值需要根据企业的网络状况和文件类型来定。对于工程图纸、视频等大文件，8MB是一个比较均衡的选择。对于较小的办公文档，16MB甚至更大的分片可以减少请求数量。巴别鸟默认使用8MB作为基础分片大小，同时支持管理员根据自身网络环境调整。
分片切分的实现本身并不复杂。客户端读取文件的字节流，按照设定的分片大小依次切分。每一片生成一个唯一的标识，通常使用文件内容Hash而不是文件名，因为同一份文件在不同时间上传，或者从不同路径上传，都应该被识别为同一份文件。MD5或者更快的SHA-256变体（如SHA-256/BLAKE3）都可以用于生成分片ID。
这里有一个实践中的细节：文件的Hash计算本身也需要时间。对于10GB以上的视频文件，计算完整Hash需要几分钟到十几分钟不等。用户面对一个10GB的文件，点击上传后等待Hash计算完成的几分钟里，体验上会有明显的”卡顿感”。一个优化方案是：先计算文件的前后各几个MB数据的Hash（或者采样Hash），快速判断是否可能命中秒传。真正的完整Hash在后台慢慢算，秒传命中了直接返回，没命中就继续走分片上传流程。
2.2 秒传：已存在的文件不需要真的传
分片上传解决了可靠性问题，但还没有解决效率问题。如果服务端已经存了一份完全相同的文件，客户端仍然按照分片方式上传一遍，是对带宽和时间的极大浪费。
秒传的原理是：客户端在开始上传之前，先计算整个文件的Hash（通常是MD5，兼顾速度和可靠性），把这个Hash和文件大小作为参数发给服务端。服务端在自己的存储系统里查找是否已经存在相同Hash且相同长度的文件。如果找到了，直接返回”已存在”的标识，客户端不需要上传任何数据。
这个机制在多人协作的场景里极其有用。一个项目组里有十个人要上传同一份标准规范文档，后面上传的九个人都是秒传，只有第一个人真正传了数据。在一个50人的设计院里，同样的规范文件在不同项目里被反复上传，没有秒传机制的情况下，同一个文件被存了十几份，存储成本成倍增加。巴别鸟的秒传机制基于文件内容Hash验证，同样Hash的文件在存储层只保留一份物理数据，所有用户共享这份实体，节省了海量的存储空间和带宽。
秒传的局限性在于：它只能判断”完全相同”的文件。对于只有几个字节不同的文件，秒传无法识别，必须完整上传。这个问题在有些场景下会导致用户困惑：我明明只改了一个标点，为什么不能秒传？背后的原因就是Hash的全文件粒度特性。有用户遇到过这样的情况：在某网盘里上传了一个500MB的PPT，上传完成后发现有个错别字，改了保存，再次上传，秒传失败，被迫重新传500MB。用户觉得这是Bug，实际上是Hash比对的正常逻辑。
2.3 分片上传的并发控制
把文件切分成多个分片之后，一个自然的想法是：能不能同时传多个分片，把总体传输时间压下去？
答案是可以，但有约束条件。
并发上传分片确实可以充分利用带宽。但并发数量过大会对服务端造成压力，尤其在多个客户端同时上传大文件时，服务端的I/O和CPU消耗会显著上升。通常会设置一个并发的上限，比如每个客户端最多同时上传4到8个分片，超过这个数量就排队等待。
另一个问题是分片乱序。假设一个2GB的文件切成256个分片，第100个分片先传完，但后面的第50个分片还在排队。这时候服务端应该先收到哪个就处理哪个，不要求按顺序。但到了合并阶段，所有分片必须按原始顺序拼接。如果某个分片缺失，合并就无法完成。所以客户端在每个分片传输成功之后，需要记录已确认的分片序号，服务端也要维护每个文件已收齐的分片列表。
并发上传还带来了一个新问题：同一个文件被多个客户端同时上传。以工程项目的共享场景为例，项目群里同时有多个人在上传会议视频或者图纸压缩包，后台上传的其实是同一份文件的不同版本。并发控制需要处理这种情况：同一个文件同时有多个上传任务在跑，服务端要给每个任务分配独立的存储空间，或者通过文件版本机制来管理。巴别鸟的解决方案是基于文件的唯一标识建立上传任务队列，同一时刻同一文件只有一个活跃的上传任务，其他请求排队或合并。
有一个边缘情况需要处理：如果两个客户端几乎同时开始上传同一个文件（都还没秒传命中），服务端会创建两个上传任务。在第一个任务完成之前，第二个任务会处于”等待合并”状态。如果第一个任务最终失败了（比如客户端崩溃），第二个任务需要能够接管，不需要用户重新上传。服务端维护上传任务的生命周期，任务超时后自动清理，给后来的任务让路。
三、断点续传的实现：从中断检测到任务恢复
3.1 怎么判断上传中断了
客户端在上传过程中，需要持续监控每一次分片请求的响应状态。正常情况下，每一次分片上传成功，服务端会返回一个确认信息，包含已接收的分片序号和当前文件的累计接收进度。如果某次分片上传超时没有收到响应，或者返回了错误码，客户端就知道这一步出了问题。
超时阈值的设定是一个工程问题。设得太短，网络偶发的抖动就会触发中断判断，导致虚假中断；设得太长，真正失败时客户端反应会慢很多。巴别鸟的客户端在网络不稳定时会动态调整超时阈值：首次失败后等待2秒重试，第二次失败后等待5秒，第三次失败后等待10秒，然后才判定为真正的中断，同时记录已成功传输的分片边界。这个”渐进式确认”机制的好处是：对于偶发的网络抖动，不会误判为中断，用户感知不到这些小问题；对于真正的网络故障，能够准确捕捉并启动恢复流程。
客户端还需要处理一个边界情况：上传过程中电脑休眠、网络切换、程序崩溃。对于这些情况，客户端在每次分片传输成功后，都会把当前的进度（已完成的分片列表、文件标识、上传任务ID）写入本地的持久化存储（数据库或文件）。程序重新启动时，读取这些记录，找到未完成的上传任务，从最后一个成功的分片之后继续。
有些客户端实现把进度记录放在内存里，程序重启后丢失，用户看到的是”任务消失了”。这种实现断点续传的名义，但没有断点续传的实质。真正的断点续传，进度必须持久化到磁盘，即使程序被强制终止（比如杀毒软件结束进程、系统蓝屏），重启后也要能恢复。
3.2 续传时的服务端状态同步
续传不只是客户端的事情，服务端也必须能够配合。服务端在接收每个分片时，需要记录这个分片属于哪个上传任务、序号是多少、是否已持久化。如果客户端带着一个”我已经传到了第30个分片”的上下文重新连接，服务端需要能验证这个状态是否属实，然后只接受第31个及之后的分片。
这里有一个潜在的安全问题：如果上传任务的状态只存在客户端，服务端没有校验机制，恶意客户端可以伪造进度（比如实际上只传了前5个分片，但告诉服务端已经传到了第30个）。完整的断点续传实现，服务端需要为每个上传任务维护一个独立的分片状态表，每接收一个分片就更新一次，客户端续传时服务端从这个状态表里读取真实进度，而不是信任客户端的声称。
巴别鸟的服务端在每次分片上传请求中，包含了当前分片的序号和期望的下一个分片序号，服务端会对这个序号做校验：如果客户端声称已经完成第30个，但服务端的记录显示只收到了前25个，服务端会拒绝客户端的续传请求，要求从第26个分片重新开始。这个校验机制确保了即使客户端记录出错（比如本地磁盘损坏），服务端也不会接受一个不完整的文件。
还有一个细节：服务端维护的进度记录，不能只依赖客户端请求来更新。服务端的分片状态表必须有自己的持久化机制，数据写入数据库而非仅存内存。如果服务端重启，所有上传任务的进度从数据库恢复，而不是清零。否则，服务端重启会导致所有正在进行的分片上传任务全部需要重新开始，用户体验会出现”服务端重启一次，所有进度清零”的糟糕情况。
3.3 秒传和断点续传的组合
秒传和断点续传并不是互斥的，而是互补的。在一个完整的上传流程里，它们的调用顺序是：
第一步，客户端计算文件Hash，尝试秒传。如果服务端返回”文件已存在”，整个上传在几秒钟内完成。
第二步，如果秒传失败，开始分片上传。分片上传的每一个分片传输成功，客户端都要记录持久化进度。
第三步，如果分片上传中途中断，客户端重新计算文件Hash再次尝试秒传（因为中断期间可能有其他人上传了相同的文件）。如果秒传仍然失败，从记录的分片进度位置继续分片上传。
这个流程保证了：已存在的文件永远不需要真的传输；中断后的续传只需要传剩余的分片；即使中途换了网络或者重启了电脑，进度也不会丢失。
有一个常见场景可以说明秒传和断点续传的配合价值：一个项目组每周需要更新一批标准文档，这些文档每次更新只有很小的变化，但文件总大小有几GB。如果没有秒传，每次更新都要重新传全部几GB；有了秒传，大部分时候是秒传完成。如果秒传失败（比如文档被改过了），分片上传接上，中断了再续传。整个过程对用户来说，就是”点一下，等几秒，完成了”。
四、实际生产环境中的关键实现细节
4.1 分片大小与网络环境的匹配
前面的建议是8MB，但实际环境远比这个复杂。有客户反馈他们在跨国的项目协作场景下，用8MB的分片频繁失败，但切换到2MB之后成功率大幅上升。原因是跨国链路的不稳定性远高于国内网络，分片越大，在传输过程中遇到丢包的概率越高。一个8MB的分片在跨国链路上传输，平均需要重传2.3次才能成功，而2MB的分片平均只需要重传1.1次。
这背后有一个数学原理：丢包率固定的情况下，单次传输的数据量越大，遇到至少一次丢包的概率越高。丢包率1%的链路，传输256KB遇到丢包的概率约0.0256%，传输8MB遇到丢包的概率约0.8%。数字看起来都不大，但对于持续数小时的传输来说，8MB分片的失败频率会是256KB分片的30倍以上。
巴别鸟客户端内置了一个自适应机制：首次上传某个大文件时，用较小的分片试探网络的实际状况，记录成功率，动态调整后续分片的大小。网络质量好的时段自动切回较大的分片，网络质量差时自动缩小粒度。这个机制对用户是透明的，不需要手动配置。用户只需要点上传，剩下的都是客户端在后台处理。
具体实现上，客户端维护一个”网络质量评分”：每次分片上传成功加1分，每次失败减5分，评分在0到100之间动态变化。当评分高于80时，分片大小上调一档（比如从8MB调到16MB）；评分低于30时，分片大小下调一档（从8MB调到4MB）。这个机制让客户端能够自动适应不同的网络环境，用户在跨国的项目现场和在公司内网上传大文件，客户端会自动选择合适的参数，不需要用户干预。
4.2 上传任务的排队与调度
当企业同时有大量上传任务时，客户端需要有调度策略。不能打开一百个并发上传，把企业带宽全部吃满，导致其他业务无法进行。通常的做法是设置一个”活跃上传任务数”的阈值，比如最多同时进行3个上传任务，其余的排队。当某个任务完成或中断时，从队列里取出下一个任务启动。
优先级的设计也有讲究。用户在上传一个3GB的视频文件，同时在上传一个200MB的PPT，显然应该把PPT的优先级提高，先完成小文件。这里涉及”短任务优先”的调度原则：在总带宽固定的情况下，让小文件先完成，可以让更多任务更快地流转到完成状态，用户看到”10个任务，8个已完成”比”10个任务，1个在传9个在等”体验好得多。
巴别鸟支持用户在上传列表里手动调整任务的优先级，同时客户端也会自动将小文件排在前面。对于管理员来说，还可以在企业管理后台设置”上传带宽限制”，限制云盘客户端在上班时间最多使用的带宽比例（比如不超过50%），保证其他业务不受影响。这个配置对于设计院、媒体公司这类有大文件传输需求但同时也有强带宽保障需求的企业，非常实用。
4.3 网络切换的处理
笔记本用户经常遇到的情况：从办公室的WiFi切换到手机热点，从有线网络切换到无线网络。传统HTTP连接在这种切换下基本都会断掉。但分片上传的任务，在网络恢复后应该能够自动恢复。
实现这个需求的关键是：上传任务的状态全部持久化在本地，每次网络恢复时，客户端重新建立连接，从服务端获取真实的已接收进度（不依赖本地记录，防止本地记录与服务端状态不一致），然后继续。
有个细节需要注意：网络切换后，客户端的出口IP可能变了。如果服务端根据IP做会话校验，可能会把新连接的请求当作一个异常的登录行为。巴别鸟的服务端对上传任务的会话校验基于任务ID而非IP地址，IP变化不会中断已建立的上传任务。用户从办公室到高铁上继续工作，中间经过多次网络切换，上传任务不受到影响。
高铁场景是测试网络切换能力的经典场景：隧道里断网5分钟，出隧道后恢复，客户端需要在30秒内检测到网络恢复并重新开始上传，而不是等用户手动干预。我们测试过巴别鸟客户端在这个场景下的表现，在4G网络下，隧道出来后平均18秒恢复上传任务。
4.4 客户端重试的退避策略
分片上传失败后，客户端的重试策略直接影响用户体验。最简单的策略是立即重试，但这样在网络抖动时会放大拥塞。指数退避是更合理的方案：第一次失败等1秒，第二次失败等4秒，第三次失败等16秒，最大等待时间设置一个上限（比如5分钟）。
超过最大重试次数后，上传任务进入”需要用户介入”的状态，客户端向用户展示明确的错误信息和可选的操作（比如重试、取消、换一个网络）。这个状态需要持久化，用户下次打开客户端时能看到未完成的任务列表，而不是静默消失。
有一个场景是用户特别容易困惑的：客户端显示”上传失败，请检查网络”，用户检查了网络（网络是好的），点了重试，结果又失败。用户会质疑”网络明明是好的为什么还失败”。问题往往不是网络连通性，而是服务端处理能力饱和或者服务端与客户端之间的某个中间节点超时。对于这种情况，用户主动重试往往没用，应该等待一段时间后再试。客户端如果能区分”服务端未响应”和”网络不可达”两种失败原因，给用户的提示就会更准确：”服务端响应超时，建议稍后再试”比”请检查网络”更有用。
五、性能数据与实测结果
在内部测试环境里，我们用不同大小的文件测试了分片上传相比整文件上传的可靠性提升。测试条件：100Mbps企业出口带宽，模拟5%的随机丢包率。测试脚本模拟了真实企业网络的丢包模式，包括偶发的短时高丢包率和持续的低丢包率。
测试结果如下：
文件大小为256MB时，整文件上传成功率为78%，分片上传（8MB分片）成功率为99.2%。整文件上传失败主要发生在传输到60%到80%区间时，丢包重传导致超时。这说明对于中等大小的文件，分片上传的优势已经很明显了。
文件大小为2GB时，整文件上传成功率为31%，分片上传成功率为97.8%。整文件上传在2GB场景下的主要问题是服务端超时，而非单纯的网络丢包。这是因为2GB文件在100Mbps带宽下需要160秒以上传输时间，加上服务端处理每个分片的开销，总时间轻松超过大多数服务端的默认超时阈值。分片上传由于每个分片独立超时，单个分片的超时不会扩散到整个任务，所以成功率能够维持在极高水平。
文件大小为8GB时，整文件上传成功率为0%（测试了20次，全部超时中断），分片上传成功率为96.5%。8GB以上的文件，在现有企业网络条件下，整文件上传基本不可行。这个结论在多个客户现场得到了验证：所有反馈”大文件上传总是失败”的企业，在改用分片上传后问题都解决了。
并发场景下的测试：10个客户端同时上传平均大小1.5GB的文件。分片上传方案下，客户端设置最大4并发分片，服务端平均CPU占用18%，内存占用稳定。当取消并发控制让客户端全速上传时，服务端CPU占用飙升至71%，响应延迟从平均80ms上升至平均1200ms，部分分片上传请求开始超时。说明服务端的并发控制是必要的，不能因为客户端的分片并发就认为服务端可以无限制处理。在服务端硬件配置有限的情况下，客户端的并发分片数需要更保守的设置。
六、分片上传在企业场景里的额外价值
分片上传解决了大文件传输的可靠性问题，但它带来的副产品——分片粒度的上传状态追踪——在企业场景里有额外的价值。
第一个价值是精准的进度反馈。整文件上传时，客户端只知道”已传输X%，剩余Y时间”，这个数据是估算的，不准确。特别是对于大文件，剩余时间的估算误差可能达到正负50%，用户看到”预计10分钟完成”结果等了半小时，心理体验很差。分片上传可以精确到”256个分片中已上传189个”，用户看到的是一个可信赖的数字，不会出现”进度条走到99%然后卡住半小时”的情况。
第二个价值是上传暂停和取消的即时生效。整文件上传如果想中途取消，客户端需要等当前请求超时才能真正停止。分片上传可以在任何时刻向服务端发送取消指令，服务端立即停止接收后续分片并清理无效数据。用户在上传列表里点取消，秒级生效，用户体验完全改变。有一次客户反馈说他们需要临时暂停一个大文件的上传来传一个紧急的小文件，在分片上传模式下只需要在列表里把大文件拖到”暂停”状态，小文件传完后拖回来继续，非常方便。
第三个价值是分片级别的校验和修复。分片上传后，如果某个分片的数据在校验时发现问题（Hash不匹配），服务端可以要求客户端只重传这一个分片，而不是整个文件。结合分片级别的Hash记录，巴别鸟能够精确定位并修复任何一个损坏的分片，这在TB级数据存储的长期可靠性维护中非常重要。对于那些有严格数据完整性要求的企业（比如设计院对图纸文件有零容忍要求），分片级别的校验能力是关键功能。
七、实施落地的几个常见误区
误区一：分片越大越省资源
有人觉得分片越大，HTTP请求数量越少，服务端压力越小。这个逻辑在请求数量层面是对的，但忽略了一个关键事实：一旦某个分片传输失败，分片越大意味着需要重传的数据量越大，续传效率越低。在可靠性优先的企业场景里，宁可多用一些请求开销，也要保证每个分片的传输时间在可控范围内。一个500MB分片失败后重传，需要重新传500MB；分成10个50MB的分片后失败，最多需要重传50MB。
误区二：断点续传只要客户端记录进度就够了
如果服务端不维护上传任务的真实状态，客户端的进度记录可以被伪造。一个恶意的客户端可以声称已经上传了100个分片，实际上只上传了10个，剩下的90个分片服务端却没有收到，最终合并出来的文件是损坏的。完整的断点续传必须服务端和客户端双重维护状态，且服务端的记录是真实数据的来源，不能信任客户端的声称。
误区三：秒传可以替代分片上传
秒传只对完全相同的文件有效，适用范围有限。有些场景下，用户上传的文件与现有文件只差几个字节（比如同一个报告改了日期），这种情况秒传完全无法识别。分片上传才是保证传输可靠性的根本方案，秒传只是一个优化加速的手段，两者不能互相替代。在技术选型时，不能因为某个产品”支持秒传”就认为它解决了大文件传输的问题，要同时看它有没有完整的分片上传和断点续传能力。
误区四：只要客户端实现了断点续传就能用
有一种情况是：客户端实现了断点续传，但服务端不支持。比如客户端在上传失败后记录了分片列表，重新连接时发送了续传请求，但服务端没有维护上传任务的状态表，回复”我不知道你之前传了什么，请从头开始”。客户端的断点续传机制变成了摆设，用户还是得从头传。所以断点续传是一个需要服务端配合的功能，评估云盘产品时需要同时验证客户端和服务端两端的实现。
八、结论
文件分片上传和断点续传，是企业云盘处理大文件传输的核心技术基础。它的本质是把一个不可靠的单一连接，拆解成多个可靠的独立单元，再用断点记录和状态同步把这些单元串联成一个可以随时中断、随时恢复的整体。
实现这套机制并不复杂，但在生产环境里跑稳则需要处理很多细节：分片大小的自适应选择、并发控制的服务端压力管理、网络切换后的状态恢复、秒传和断点续传的组合调用逻辑。任何一处处理不好，都会导致”理论上支持断点续传但实际用起来经常丢数据”的问题。
对于企业来说，在选型评估云盘时，断点续传不应该只问一句”你们支持断点续传吗”就了事，而应该追问：分片多大？续传时服务端怎么验证进度？网络切换后能不能自动恢复？分片失败了重传多大粒度？这些细节的答案，才是真正衡量一个产品在这方面做得怎么样的标尺。
九、端到端加密上传的实现与隐私边界
除了可靠性和速度，安全性是企业云盘大文件上传必须同时考虑的维度。在上传过程中，数据从客户端到服务端经过多个网络节点，每一个节点理论上都可以截获或篡改传输中的数据。对于含有商业机密或敏感信息的文件，需要在上传前对数据进行加密。
端到端加密上传的实现方式有两种。第一种是传输层加密，即TLS/SSL加密，这是所有HTTPS传输的标准配置，数据在传输过程中是加密的，但服务端在接收数据后会解密（否则无法存储和分发）。这种方式对大多数企业场景足够，但要求服务端必须可信。
第二种是客户端自主加密，数据在离开客户端之前就已经加密，服务端只存储密文，即使服务端被攻破，攻击者也拿不到明文内容。这种方案的挑战在于密钥管理：加密密钥在客户端，服务端不知道明文，那么文件的分片搜索、预览、在线编辑等功能就无法直接实现，因为这些功能需要服务端能读取文件内容。巴别鸟对于有高安全要求的私有化客户，支持在客户端实现文件级别的加密，上传前加密，服务端以密文形式存储，解密操作在下载时由客户端完成。
对于大多数企业用户来说，关注TLS传输加密和存储加密就足够了，不需要过度追求端到端加密（后者会牺牲很多功能性体验）。但选型时需要确认：上传通道是否强制HTTPS？存储层是否加密？私有化部署时客户能否自带密钥？这些问题的答案体现了产品对安全性的重视程度。
十、分片上传在移动端和弱网络场景下的特殊处理
企业用户不总是在办公室的固定工位上。销售人员在客户现场用手机上传合同扫描件，工程监理在工地用平板上传现场照片，这些都是移动端上传的场景。和固定网络相比，移动网络的带宽更不稳定，丢包率更高，切换更频繁。
移动端的分片上传需要额外处理几个问题。首先是流量成本：手机网络的流量是有限的，大文件分片上传如果失败重试，会消耗额外的流量。一些产品在这里做了优化：当检测到是按量计费的网络时，主动降低分片大小（减小重传代价）和并发数（减少带宽占用峰值），同时给用户更明确的流量预估提示。
其次是后台执行限制。iOS和Android系统对后台应用的网络访问有严格限制，应用切入后台后，上传任务可能被系统暂停或降速。对于需要在后台持续上传大文件的场景，需要使用系统提供的后台任务API（比如iOS的Background Transfer Service），并在UI上给用户明确提示”上传任务将在后台继续”。巴别鸟的移动端客户端在用户切换到后台时，会自动切换到后台任务模式，利用系统配额继续完成分片上传，但速度会比前台运行时有明显下降。
弱网络场景（如地库、电梯、信号差的会议室）的处理策略也和桌面端有区别。这些场景的特点是连接不稳定，可能每隔几十秒就断一次，但每次断的时间不长。分片上传在这种情况下需要更敏感的断线检测（不能等标准的30秒超时，需要更快判断）和更快的重连机制。巴别鸟的移动端在弱网络下采用”短周期探测+快速恢复”的策略：每5秒发送一个探测包检测连通性，一旦发现恢复，立刻重启分片上传，不需要等用户感知到断线。
十一、选型时评估分片上传能力的检查清单
作为一个总结，提供一个用于评估云盘产品分片上传能力的检查清单，供技术选型人员参考：
第一，确认是否真的支持分片上传。很多产品声称支持断点续传，但实际上只是在客户端记录了本地进度，服务端不支持状态校验，中断后从服务端获取不到真实进度，选型时需要用真实的大文件（至少1GB以上）做一次完整的中断恢复测试。
第二，测试续传后的服务端状态一致性。客户端声称的续传进度是否与服务端一致？可以在分片上传到一半时强制关闭客户端进程，重启后观察续传是从哪个分片开始的，如果从第一个分片开始说明服务端状态同步有问题。
第三，测试网络切换场景下的续传。笔记本从WiFi切换到有线网络，或者从公司网络切换到手机热点，观察上传任务是否能自动恢复。
第四，测试服务端重启对上传任务的影响。在上传进行中时，重启服务端（或联系运维模拟一次），观察客户端是否能在服务端恢复后自动接上。
第五，验证秒传的准确性和速度。相同文件秒传是否真的在几秒内返回？秒传失败后是否自动切换到分片上传？分片上传完成后，再次上传同一个文件是否变成秒传？
第六，检查移动端的后台上传能力。手机上传大文件后把应用切到后台，一小时后回来查看上传是否完成，验证后台任务是否真的在执行。