北京
你正要提交一个大型视频时，Wi‑Fi突然断了。页面显示“离线模式，可继续上传”，让你松了一口气。可当你重新打开浏览器，发现那个上传了80%的进度条干干净净——文件还在本地吗？这背后是一套容易被过度包装的能力。
“离线工作”是上传页面很有吸引力的卖点，但实际实现要远比这个口号复杂。浏览器的真实局限在于：它无法在没有网络的情况下发送媒体，也很可能在一个页面重启后不再保留已选择的文件，更无法依赖跨移动平台的后台执行。一个靠谱的离线设计，就是老老实实承认这些限制。
围绕离线上传，产品侧常打出的牌是“即使没网也能继续上传”，但工程侧看到的现实完全不同。正方的愿望是：页面可打开、断网期间继续选择文件、早已开始的传输能在恢复网络后接着传。反方看到的是：Service Worker 能缓存的只是 HTML、CSS 和 JS 这些应用壳，并不能缓存私有专辑的回复，更无法缓存那些有时效且每次不同的签名上传 URL。如果连身份都来不及校验，任何离线态的数据展示都必须以失败封闭。
解决这个矛盾的第一步，是把“离线”拆成一串更具体的子能力，而不是用一个徽章掩盖所有差异。原文列出的可测试维度包括：页面壳能否从缓存打开、文件元数据能否在临时断掉时存活、一个正在传输的块能否在网络恢复后重试、完整的原始文件能否在页面重载后存活、甚至上传能不能在浏览器关闭后继续。这些维度彼此独立，不能混为一谈。严格的做法是：逐一测试，并分别记录支持情况。
为了保住连接中断前的进度，IndexedDB 可以存储上传 ID、已提交的分片、文件大小和类型，甚至设置过期时间。但它通常无法保证在浏览器重启或页面重载后，还能访问到原来的 File 对象。因此界面上的文案需要区分两种状态：页面还活着只是暂时没网时，可以说“重新连接以继续上传”；如果页面试图从一次完全的重启中恢复，就只能提示“选择相同的文件来恢复上传”。
当你真的去选文件时，系统必须用不止文件名来验证二者是否一致。名称之外，还要比对文件大小、修改时间，并建议辅以局部指纹；绝不能仅仅因为文件名相同，就把一个完全不同的文件塞进旧的会话里。这避免了用户手滑造成的覆盖风险。
另一个容易被误解的地方是 connectivity 事件。navigator.onLine 状态变成 true，并不代表你的上传主机真的可达。这里面可能横着强制门户、DNS 劫持，甚至是被运营商屏蔽的存储域名。频繁的网络失败后最好暂停，用有限超时去探测控制 API。网络刚一恢复时，先别急着重传，先拉取服务器已经确认的已提交分片——很可能某个响应丢失了，但服务器那边已经存好了对应的字节。
Background Sync 也曾被寄予厚望，但它既不是所有平台都支持，也不会保证按时触发。更要命的是，在页面关闭后将巨大的 File 对象传递给 Service Worker 非常不可靠。所以它只能作为一个小型控制消息的优化手段，绝不能成为关键媒体的唯一上传路径。更安全的做法是：只在用户主动选择继续等待时，才让页面保持唤醒，并避免在后台搞出耗尽电池的循环。
前端 UI 应该是文件级的状态机，展现每个文件的等待连接、可恢复、需重新选文件、已过期或已接纳状态，并明确告知下一步动作。一个全局的红色横幅远不如每个文件旁的恢复入口有用。如果活动在离线期间结束，不要立刻丢弃本地记录，而是提示用户保留原始文件，必要时提供组织者的支持渠道。
最后，真正的离线鲁棒性不是靠埋预设，而是靠真实中断测试跑出来的。原文提醒用飞行模式、强制门户、屏幕锁定、标签页清理，乃至浏览器受限内存被系统抹掉的情况去验证。只有经历过这些，你才知道哪些承诺是真实的，哪些只能停留在宣传页上。绕开虚假希望，诚实地分段兑现，才是对用户真正有益的设计。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
