好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 截图和相机照片常远大于展示需求，但重编码会损失质量、改变色彩并消耗 CPU。应用应保留“发送原图”选择并在压缩前给出预计大小。
性能优化先定义用户等待的完整区间，再拆分 CPU、队列、网络和持久化阶段。平均值会掩盖真正流失用户的尾延迟，优化必须比较 p95/p99 与资源成本。
先定义系统契约
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 读取方向后按最长边限制像素，照片优先 WebP/JPEG、透明图保留 alpha；Worker 中分块处理并默认剥离 GPS 等 EXIF。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“发送图片前压缩：画质、元数据、CPU 与省流量怎么取舍”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 无条件转 JPEG 会破坏透明截图和文字锐度；超大图直接 drawImage 可在移动端瞬间分配数百 MB 导致崩溃。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
如何逐条验证契约
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 用相机照、透明 PNG、长截图、广色域和带 GPS/旋转 EXIF 样本比较大小、SSIM 近似、峰值内存、耗时与元数据。
- 连续执行一百次开始、失败、重试和取消，检查句柄、监听器、队列及临时数据回到基线。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。