本文记录公司自研系统的工程实践，非对外客户案例。
一句话结论
我们在网站后台加了一步"上传时先裁剪"：运营传什么尺寸的图，系统都会按页面要求裁好、缩到固定大小再存进去。结果是页面不再出现图片变形、被裁掉半个主体这类问题。实测一张 1200×2000 的手机竖图，裁剪后是 1600×1067；换成一张 2058×2912 的原图，同样裁成 3:2，输出仍是 1600×1067、约 192KB，而且不放大。
技术摘要
技术问题：图片上传尺寸不统一，导致前端展示异常。
解决方案：上传阶段按槽位比例裁剪，并用 canvas 重绘到固定像素。
新闻封面与首页卡片：3:2，输出 1600×1067。
商品封面：4:3，输出 1200×900。
输出格式：JPEG，质量 90。
数据治理：按文件指纹（sha256）识别重复上传，不产生副本。
验证方式：实测输出图片的宽高与体积，而不是只看代码是否执行成功。
放大说明：裁剪区小于输出尺寸时会被放大，例如 1200×800 → 1600×1067，约 1.33 倍；建议上传清晰原图。
我们遇到的问题
同一个网站，不同位置要的图片比例不一样：新闻封面是 3:2，商品图是 4:3，首页卡片又是 3:2。运营手上只有手机拍的原图，直接传上来，网页只能硬按框塞进去，主体经常被裁掉一半。
看起来像"图没选好"，其实是尺寸没人管：没有哪一步规定过"传上来的图必须多大"。
现在怎么做的
我们把要求写死在上传这一步：新闻封面和首页卡片按 3:2 裁，输出 1600×1067；商品图按 4:3 裁，输出 1200×900。传图的人只管选图、拖一拖位置，尺寸由系统处理。
为什么不能直接用现成的裁剪组件
第一次我们直接用了裁剪组件给的图，结果存进去只有 192×128——比目标小了一大截。原因是它出图时按裁剪框当前在页面上占多少像素来取图：弹窗刚打开、容器还没量到宽度，它就用一个很小的尺寸出了图；换台机器、换个显示缩放，出来的尺寸也会跟着变。
后来改成自己按目标尺寸重画一遍：先从原图上取出选中的那块，再画到一张固定 1600×1067 的画布上，最后存成 JPEG。这样不管在什么屏幕上操作，出来的图都是同一个尺寸。
裁剪框拖不动这件事
第一版做完，裁剪框拖不动。我们自己的配置把框设成了固定、并且铺满整个容器，图片没有可移动的余地。改成让框比容器小一圈、允许拖动之后才正常。
判断它到底动没动，不能靠眼睛看。我们的做法是拖之前和拖之后各取一次画面像素做对比，第一次测出来只变了 0.1%，说明确实没动过。改了配置以后再测，变化量才对得上。
工具使用说明
这个组件是用 AI 编程工具辅助实现的。这里记录的是工具怎么用，和我们对客户交付的服务是两件事。真正起作用的不是"AI 会写代码"，而是我们提的三条要求：
第一，不许自己发明界面，一律照搬后台现有的样式；第二，输出必须是固定尺寸，不接受"差不多就行"；第三，尺寸必须实测，不接受"应该没问题"。
第三条最关键。上面那个 192×128 的错误，代码看起来完全正确，是跑起来量了尺寸才发现的。
AI 也有不靠谱的时候：它第一版按常规写法出图，没考虑屏幕尺寸会影响结果。这类错误不报错、不崩溃，只会安静地生成一张尺寸不对的图。
现在的结果
一张 1200×2000 的原图，裁剪后是 1600×1067，比例 1.4995（接近 3:2，不是严格的 1.5）。裁剪区最大只有 1200×800，放大下限是 1.33 倍；实测默认取景下取到的是 1015 像素宽，实际放大 1.58 倍。换成 2058×2912 的原图，裁剪区是 1741×1161，输出 1600×1067 反而属于轻微缩小（0.92 倍），体积约 192KB——原图越大，出图越锐利。同一张图重复上传会被认出来（按文件指纹比对），不会存成两份。
业务侧的数字：上线后运营因图片尺寸不合规导致的返工次数——该指标尚未统计，统计口径定下来再补。
常见问题
传上去的图会被放大吗？ 会，取决于原图够不够大。3:2 的槽位要输出 1600×1067；一张 1200 宽的图裁成 3:2 后只剩 1200×800，补到 1600×1067 至少要约 1.33 倍放大（取景没占满原图宽度时还会更高）。4:3 的商品图输出 1200×900，同样的 1200 宽原图刚好够用。所以建议上传分辨率足够的原图，输出质量 90。
以前传的图要重传吗？ 不用。新规则只对以后上传的图生效，存量图不动。
尺寸是谁定的？ 按页面版式定的，写在后台上传组件里，不是口头约定。改版式才改尺寸。
我们在做的
把尺寸要求从"大家记得按规范来"，变成"不合规的图传不进来"。写在文档里的规范会被忘掉，写在程序里的不会。