图片压缩：怎样在目标体积内尽量保留画质
这是「光屿图片」技术系列的第一篇，介绍图片压缩功能。
体验地址：
这个功能的大部分代码由 AI 协作完成。我的工作重点是把“压到指定大小”描述成可验证的目标，并检查 AI 生成的搜索策略、内存边界和测试结果。
用户要的不是 quality，而是文件大小
很多图片压缩接口只提供 quality 参数，但普通用户真正关心的是：“能不能压到 500 KB 以内？”
质量值与文件大小并不是线性关系。照片的内容、尺寸和纹理不同，同一个质量参数可能得到完全不同的文件体积。因此，固定写一个质量值并不能稳定满足目标大小。
项目采用有限次数的二分搜索：
- 先用最低质量编码，判断目标体积是否能够达到；
- 在最低质量和最高质量之间取中间值；
- 文件过大就降低质量，满足目标就继续提高质量；
- 最多尝试 7 次；
- 保留所有合格结果中画质最高的一份。
它追求的不是精确等于 500 KB，而是：
文件大小不超过目标值 + 在可选结果中尽量保留画质
先控制内存，再开始编码
移动端处理大图时，真正危险的往往不是压缩算法，而是 Canvas 像素缓冲区。
一张 RGBA 图片的基础内存约为：
宽度 × 高度 × 4 bytes
实际处理中还可能同时存在原图、目标 Canvas 和编码缓冲。因此项目会在创建 Canvas 前估算工作内存，并同时限制最长边和总像素量。超过安全范围时先等比缩小，而不是等到设备崩溃后再处理异常。
为什么放在本地做
图片压缩在端内完成后，不需要：
- 上传原图和下载结果；
- 部署图片转码服务；
- 保存压缩任务状态；
- 承担与图片数量同步增长的存储和带宽费用。
压缩流程由少量纯函数和统一导出层组成，目标体积搜索也可以脱离微信页面进行单元测试。调整搜索次数、质量范围或尺寸策略时，不需要修改页面交互。
这是一个很典型的低成本功能：算法不复杂，但只要把内存边界和失败提示做好，就能在不增加后端的情况下稳定交付。
AI 在这里最有价值的地方，不是代写某一个 API，而是把需求拆成搜索算法、资源检查、导出流程和测试用例。功能边界清晰后，后续修改目标大小或质量策略也更容易继续交给 AI 维护。
