使用方法
- 点「选择本地图片」挑一张本机图片（jpg/png/webp 等），图片只会进入浏览器内存，不上传。
- 「目标大小」默认 100 KB，也可改成 1～5000 之间的任意值；本页主打 100KB 压缩。
- 点「开始压缩」：工具先用 JPEG 质量 0.92 输出，若仍超目标就逐级下调到 0.30，还超就缩小最长边到 80% 再压，直到达标。
- 结果区显示「原始尺寸 → 输出尺寸、质量、字节数」；预览区出现压缩后图片，并提供下载链接。
- 点「清除结果」可清空预览与统计，换一张图再压；对照表区可「加载更多」「导出 CSV」「复制 TSV」。
能解决什么问题
一是绕开「上传才能压」的隐私担忧。很多压缩站要把图传到自己服务器再返回，敏感截图、证件照、内部图都不该出门。压缩图片转100KB 全程在本地 Canvas 完成，图片字节不离开你的浏览器，省心也安全。
二是把「随便压小」变成「压到指定上限」。普通压缩只给一个模糊的「小/中/大」，你还得反复试。本页以「≤目标 KB」为硬约束，迭代到刚好达标，特别适合「附件不得超过 100KB」这类硬性限制。
三是质量与尺寸双调节。只降质量会让照片出明显块斑，只缩尺寸会丢细节。本页先降质量后缩尺寸，兼顾体积与观感，多数照片能在 100KB 内保持可用清晰度。
本页不做这些事：不做 PNG 无损压缩（输出为 JPEG）、不裁剪不加水印、不做批量文件夹处理。它只回答「这张图压到 ≤100KB 后长什么样、多大」。
压缩原理与变量说明
读取与解码在本机。用 FileReader 把文件读成 DataURL，再交给 Image 解码为位图；整个过程不出浏览器，也没有网络请求。
先降质量，再缩尺寸。JPEG 质量从 0.92 起，每档减 0.04 直到 0.30，用 canvas.toBlob(type, quality) 检查字节。若 0.30 档仍超目标，则把最长边乘 0.8 缩小后重来一轮质量循环，直到达标或边长缩到 40px 以下为止。
为什么从 0.92 而不是 1.0。质量 1.0 的 JPEG 几乎不省体积，且易暴露原图噪声；0.92 已是肉眼难辨的起点，往下才有明显压缩收益，符合「先保观感再压体积」的直觉。
目标与字节换算。目标以 KB 输入，内部乘以 1024 得字节上限。输出最终宽度 × 高度、实际质量系数与字节数，并附 KB 读数，方便你核对是否真的压到了线内。
数值只在本地计算。整条链路只有解码、绘制、toBlob 与字节统计，全部在当前页面执行，没有任何网络请求，也不写 Cookie 或 localStorage。
完整示例（以一张 2.4MB 的 4000×3000 照片为例）
示例说明算法对一张典型大图的真实走向（具体数值随原图内容变化，下面为示意量级）：
- 原始：4000 × 3000，约 2.4 MB；目标 100 KB；
- 过长边超 3000，先缩到 3000 × 2250，再进入质量循环；
- 质量 0.92 输出约 480 KB（仍超），逐档下调，到 0.60 约 210 KB（仍超）；
- 仍超则缩边到 2400 × 1800，质量回到 0.92 约 320 KB，继续下调到约 0.74 时首次 ≤ 100 KB；
- 最终：约 2400 × 1800、质量 0.74、96 KB，预览可见、细节尚可——这就是「压到 100KB」的结果。
这张图若内容更「平」（如截图），可能在更高画质就达标；若细节极多（如毛发、星空），可能要缩到更小边长。算法会自动在这两者间找平衡点，你无需手动估。
对照表
- 对照表用途：列出 14 种常见目标大小及其典型场景、建议最长边，帮你给不同用途挑一个合理的 KB 上限。
- 行数：共 14 行，前 12 行直接显示，后 2 行点「加载更多」展开，可导出 CSV 或复制 TSV。
- 仅供参考：建议最长边是经验值，实际能否压到取决于原图复杂度；真正的结果由上方算法按「质量+尺寸」迭代得出。
- 与工具关系：表是选参参考，工具是执行器，两者配合：先用表定目标，再用工具压到该目标。
对照表是「建议值速查」而非「你的压缩结果」，它与上方计算器是两个独立信息源：工具给你这张图的实际输出，对照表给你不同场景的推荐上限。
结果边界与舍入说明
- 必须选图片。没选文件、文件 0 字节、或类型不是图片，都会得到具体中文报错并停止，不会静默产出空文件。
- 输出为 JPEG。即使原图是 PNG（带透明），输出也是不透明 JPEG，透明区域变白。需要保留透明请另用 PNG 工具。
- 极小目标可能压到很模糊。若目标定到 5KB，算法会把边长缩得很小、质量压到 0.30，图片必然模糊——这是体积换清晰度的必然代价，非 bug。
- 质量系数显示两位。内部用更细步进，结果区把质量四舍五入到两位小数展示（如 0.74），不影响实际编码精度。
- 超大图先预缩放。原始最长边超过 3000 会先缩到 3000 再压，避免 Canvas 占用过多内存；这与「压到目标」的最终目标一致。
- 数值只在本地计算。整条链路只有图像解码与编码，全部在当前页面执行，没有网络请求，也不写 Cookie 或 localStorage，关掉页面即清空。
常见问题
图片会被上传吗？
不会。读取、解码、绘制、toBlob、下载全部在浏览器本地完成，页面不发起任何网络请求。你可以在开发者工具的 Network 面板里反复压缩，看不到任何对外请求。
为什么压出来是 JPEG 而不是 PNG？
因为按字节上限压缩主要靠有损的 JPEG；PNG 是无损、对照片几乎压不下来。若原图是透明 PNG，透明处会转成白色。需要保留透明请改用专门的 PNG 压缩工具。
目标 100KB 但结果只有 96KB，正常吗？
正常。算法以「≤目标」为停止条件，第一次达标就停，所以常会略小于 100KB（如 96KB）。它不会为了凑整而继续加码质量。
质量调到 0.30 还是超怎么办？
这时算法会缩小最长边到 80% 再重新走质量循环，直到达标或边长缩到 40px 以下。极复杂的原图在极小目标下确实会变得很小很糊，这是体积换清晰度的结果。
选了文件但提示「不支持的类型」？
说明文件的 MIME 不是 image/ 开头，可能是伪装成图片的非图像文件，或浏览器无法解码的格式。请换一张 jpg/png/webp 等常见图片再试。
为什么从 0.92 开始而不是 1.0？
质量 1.0 的 JPEG 几乎不压缩，还容易保留原图噪声，体积下降很小；0.92 是肉眼难辨的起点，往下才有明显收益，更符合「先保观感再压体积」的直觉。
对照表后两行为什么折叠？
前 12 行直接显示，第 13、14 行默认折叠，点「加载更多（还有 2 行）」即可展开；同时可「导出对照表 CSV」或「复制对照表」拿到全部 14 行 TSV。
结果会被保存或追踪吗？
不会。所有图像处理只在你当前浏览器里完成，页面不写 Cookie、不写 localStorage、不发任何请求。刷新或关掉页面，本次结果即清空。