做视频转换工具时，“支持 1080p”很容易被写成一个醒目的按钮，但对工程实现来说，它不是一个静态布尔值，而是一段能力协商流程。
用户选择 MP4，真正关心的并不只是分辨率标签。他还需要知道：系统正在做什么、首选格式是否可用、发生回退时最终拿到的是什么、结果能否先预览，以及失败究竟来自时长、源媒体、格式还是上游服务。
如果这些状态没有被明确建模，1080p 很快就会从“优先尝试”变成用户理解中的“必然交付”，产品契约也会随之失真。
先区分“首选质量”和“实际质量”
一个更稳妥的接口至少要区分两个字段：
- requested quality：用户或产品策略希望优先尝试的质量；
- selected quality：上游实际返回、最终可以交付的质量。
当首选 1080p 不可用时，系统可以继续尝试 720p、480p、360p，但不能在界面上仍把结果写成 1080p。否则用户看到的是一个承诺，下载到的却是另一个结果。
回退本身并不是失败。真正的问题是回退不可见。只要前后端都能明确记录“请求了什么、最终选中了什么、为什么发生回退”，降级结果仍然可以被用户理解和判断。
把格式回退写成状态机
我会把这条链路拆成六个阶段。
第一步，解析并校验输入。系统只接受预期的 URL 或 video ID 形态，同时在产品层明确：用户只能处理自己拥有或获授权下载的内容。
第二步，读取可用元数据并检查时长。时长限制应该在真正进入重任务前判断，避免用户等待很久后才收到一个本可提前发现的错误。
第三步，建立候选格式队列。对于 1080p 首选请求，候选顺序可以是 1080p、720p、480p、360p；但候选列表代表尝试顺序，不代表每个来源都具备全部格式。
第四步，逐项请求上游能力。某一档格式不存在时进入下一档；上游暂时失败、来源不可用和格式不存在要保留为不同原因，不能全部压成一句“转换失败”。
第五步，拿到可用结果后记录 selected quality，并把任务转为可预览状态。前端此时展示真实分辨率，而不是继续显示用户最初请求的标签。
第六步，如果所有候选都不可用，则返回明确失败状态，不伪造空文件，也不把第三方错误包装成永久不支持。
这套状态机的重点不是代码复杂度，而是让每一个用户可见状态都有后端事实对应。
时长限制也应进入格式策略
分辨率和时长往往不是两个完全独立的参数。这个案例里，1080p 流程最长 90 分钟，较低分辨率流程最长 120 分钟。
这意味着后端不能只写一个全局 max duration。更合适的方式是让限制跟随候选格式：
- 先根据首选格式检查对应时长；
- 超出 1080p 限制时，不要暗示系统一定会成功回退；
- 如果产品允许尝试较低分辨率，再按较低分辨率的规则重新判断；
- 把最终采用的限制和分辨率一起返回给前端。
这些数字是当前产品策略，不是视频转换领域的通用标准，也不应被写成对未来永远不变的承诺。
进度和预览是结果校验的一部分
转换任务通常依赖异步处理。如果界面只有“开始”和“下载”两个状态，用户无法判断任务是在排队、处理中、重试上游，还是已经失败。
进度展示不一定要伪装成精确到百分之一的实时测量。更重要的是给出可信阶段，例如已创建任务、正在获取媒体、正在等待上游、结果已就绪或处理失败。
预览则解决另一个问题：格式成功不等于结果适合使用。用户应该先确认画面、声音和实际分辨率，再决定是否打开下载链接。对于发生过回退的结果，预览尤其重要，因为它让“可交付”与“符合预期”保持区别。
第三方结果链接不是永久存储
当转换由第三方提供商完成时，系统返回的通常是媒体下载或播放链接，而不是站点自己长期托管的一份用户文件。
因此前端和文案都不应该把它描述成永久文件库。更稳妥的做法是：
- 明确结果链接来自第三方处理链路；
- 不承诺永久有效；
- 允许用户在链接可用时预览和打开；
- 对过期、暂时不可用和上游失败给出可理解的错误；
- 不把“拿到 URL”误写成“文件已经永久保存到账户”。
这也解释了为什么此类产品即使不要求注册，仍然需要清楚说明任务状态、短期缓存、诊断日志和滥用防护边界。
失败分类决定后续能否排查
如果所有错误都叫 conversion failed，开发者无法判断该优化输入解析、时长检查、格式选择还是提供商切换。
至少可以区分：
- input invalid：输入无法解析；
- rights confirmation missing：用户没有确认处理权限；
- duration exceeded：超过当前候选格式的时长限制；
- format unavailable：该来源没有目标格式；
- provider unavailable：第三方暂时不可用；
- ready with fallback：任务成功，但最终分辨率低于首选；
- ready as requested：按首选格式成功交付。
这些状态既服务用户，也服务监控与故障复盘。它们能帮助团队看到回退发生在哪里，而不是只统计一个笼统的成功率。
一个可检查的实际页面
我把这套“1080p 优先、真实回退、进度、预览和第三方结果边界”落实在一个独立 MP4 页面中：
它当前先尝试 1080p，并可在不可用时回退到 720p、480p 或 360p。这里必须同时保留限制：1080p 不是对所有来源的保证：实际可用格式取决于源媒体和第三方提供商；1080p 流程最长 90 分钟，较低分辨率流程最长 120 分钟；任务可能失败、降级或暂时不可用，返回的媒体链接也不应被当成永久文件库。
小结
视频转换链路的可信度，不来自页面上写了多高的分辨率，而来自系统能否如实回答四个问题：首选是什么、实际拿到什么、为什么发生变化、用户如何检查结果。
把 requested quality、selected quality、fallback reason、duration policy、progress stage 和 result lifetime 分开建模，才能让回退成为可解释的产品行为，而不是隐藏在下载按钮后面的意外。
