在维护我自己的图片处理项目图片猫（PicCat）时，我重新检查了快速编辑器的裁剪逻辑。一个容易混淆的现象是：裁剪框已经被限制在图片内，拖到边缘时却仍会“滑走”。原因可能不是少写了一个判断，而是把移动整个框和拖动某一条边，当成了同一种约束。
项目出处：图片猫（PicCat）
这篇聚焦自由比例裁剪：先确定图片的四条边，再分别处理整体移动和边缘缩放。项目当前有四个角点，没有独立的四边拖拽手柄；下文把每个角点拆成横、纵两个方向计算，额外给出的单边分支属于可复用的建议算法。所有代码都是关键片段，不是完整 Vue 组件。
1 先判断是哪一种越界
当前 ImageEditor.vue 在每次 applyCropDrag 后调用 clampCropDisplay，松手回写逻辑选区前还会再调用一次。在有效的显示尺寸和有限数值下，它先把宽高收进图片尺寸，再限制左上角位置，已经能够保证显示矩形留在图片范围内。不能把当前实现描述成“完全没有边界保护”。
排查时我会先区分三个问题：选区的数值真的超出图片；数值没有越界，但被动一侧跟着移动；角点控件伸出了图片，看起来像越界。只有第一种能单靠矩形包含关系判定，第二种还要检查固定边，第三种则要检查 CSS。
2 用四条边表达包含关系
统一使用裁剪叠加层内的 CSS 像素。图片显示矩形的左、上、右、下记作 L、T、R、B；裁剪框对应的小写字母为 l、t、r、b。包含关系是 l≥L、t≥T、r≤R、b≤B，同时要求 r>l、b>t。右边界是 x+w，不是 w；图片居中或平移后，L 和 T 也不一定为零。
教学整理｜由项目 getCropDisplayMetrics 的返回值定义四边
const L = metrics.offsetX;
const T = metrics.offsetY;
const R = L + metrics.renderW;
const B = T + metrics.renderH;
这些 offset 来自 Canvas 与编辑区域的 getBoundingClientRect() 位置差。该 API 返回视口坐标和包含边框的矩形，不能把它与 pageX、图片自然像素直接混用。[1] 这里沿用当前结构的相对定位前提；如果父层增加缩放、边框或内部滚动，应重新核对叠加层原点和单位。
例子中图片范围为 (30,40) 到 (630,440)，宽 600、高 400。裁剪框 x=130、y=100、w=200、h=120，因此右边是 330、下边是 220。后面的数值都来自这套坐标，不需要读者先理解整套旋转矩阵。
3 整体移动时 限制左上角的可行区间
整体移动保持宽高不变。向左最多到 L；向右最多到 R−w，否则右边会超过 R。纵向同理，y 的范围是 T 到 B−h。对应到本例，x 可落在 [30,430]，y 可落在 [40,320]。一次移动跨过整个图片，也可以直接夹到端点，无需逐像素判断。
项目代码摘录｜clampCropDisplay 的位置限制，仅调整换行
displayCropX.value = clamp(
displayCropX.value, metrics.offsetX,
metrics.offsetX + metrics.renderW - displayCropW.value
);
displayCropY.value = clamp(
displayCropY.value, metrics.offsetY,
metrics.offsetY + metrics.renderH - displayCropH.value
);
项目在这段之前把宽高分别限制到 [min(20,renderW),renderW] 和 [min(20,renderH),renderH]。这个顺序很关键：如果框比图片还宽，R−w 就小于 L，区间已经不存在。clamp 不负责修复一个上下限反转的区间。
建议纯函数｜用于已在边界内的合法选区
type Rect = { x: number; y: number; w: number; h: number };
const clamp = (v: number, lo: number, hi: number) =>
Math.max(lo, Math.min(hi, v));
function moveRect(s: Rect, dx: number, dy: number, b: Rect): Rect {
return { ...s,
x: clamp(s.x + dx, b.x, b.x + b.w - s.w),
y: clamp(s.y + dy, b.y, b.y + b.h - s.h)
};
}
s 必须是按下时的快照，dx、dy 必须是相对按下位置的总位移。项目 onCropMouseDown 保存 cx、cy、cw、ch，onCropMouseMove 使用 clientX/clientY 的差值，已经遵循这个方式。不要在每一帧的新坐标上继续加“总位移”，否则会重复累计。
4 缩放时 先固定对边再限制活动边
向右拉伸时，左边应固定。正确的上限是“从固定左边到图片右边还剩多少空间”，不是整张图片的宽度。其他三个方向也遵循同样的原则。设最小宽、高分别为 mw、mh，下表中的 l₀、r₀、t₀、b₀ 都取自按下快照。
活动边 | 固定边 | 活动边的计算 |
左 w | 右 r₀ | l = clamp(l₀ + dx, L, r₀ − mw) |
右 e | 左 l₀ | r = clamp(r₀ + dx, l₀ + mw, R) |
上 n | 下 b₀ | t = clamp(t₀ + dy, T, b₀ − mh) |
下 s | 上 t₀ | b = clamp(b₀ + dy, t₀ + mh, B) |
最后统一还原为 x=l、y=t、w=r−l、h=b−t。nw 组合左和上，ne 组合右和上，sw 组合左和下，se 组合右和下。自由比例下，横纵方向互不耦合，因此既能覆盖四个角点，也能扩展为单边操作。
建议改进代码｜自由比例计算的前半段，尚未接入项目
type Handle = 'w' | 'e' | 'n' | 's' | 'nw' | 'ne' | 'sw' | 'se';
function resizeFree(
s: Rect, handle: Handle, dx: number, dy: number,
b: Rect, minSize = 20
): Rect {
let left = s.x, right = s.x + s.w;
let top = s.y, bottom = s.y + s.h;
const minW = Math.min(minSize, b.w);
const minH = Math.min(minSize, b.h);
调用前要保证数值有限、边界与选区为正尺寸、选区完全在边界内，minSize>0，且初始宽高已达到 minW、minH。这样各 clamp 区间才有效。若图片比 20 像素小，就以图片尺寸作为有效最小值；若只是初始框太小，则应先规范化选区或拒绝开始手势。
建议改进代码｜接续前段，四条边分别限位
if (handle.includes('w'))
left = clamp(s.x + dx, b.x, right - minW);
if (handle.includes('e'))
right = clamp(s.x + s.w + dx, left + minW, b.x + b.w);
if (handle.includes('n'))
top = clamp(s.y + dy, b.y, bottom - minH);
if (handle.includes('s'))
bottom = clamp(s.y + s.h + dy, top + minH, b.y + b.h);
return { x: left, y: top, w: right - left, h: bottom - top };
}
这段复用上一节的 Rect 和 clamp。合法 Handle 不会同时含 w、e 或 n、s，所以一侧更新不会改变同轴的固定对边。拖过对边时选区停在最小尺寸，不自动翻转手柄身份；如果产品需要穿越后反向拉伸，应另行设计切换规则。
5 两个源码反例 没越界也可能不符合手势
先看右下角向右拖 dx=500、dy=0。起始左边 130、宽 200，候选宽度为 700。当前逻辑先限制宽度到图片宽 600，再把 x 限制到唯一可行的 30；选区虽然留在图片内，左边却从 130 移到了 30。按四边算法，左边保持 130，右边停在 630，宽度应为 500。
再看左下角向右拖 dx=250。项目 sw 分支保留了下面这组计算，宽度被最小值截住后，x 仍直接跟随 dx：
项目代码摘录｜applyCropDrag 的 sw 分支中的相关语句
let newW = Math.max(20, cw - dx);
// 此处省略高度和固定比例分支。
displayCropX.value = cx + dx;
displayCropW.value = newW;
本例得到 x=380、w=20，右边成为 400，偏离了原来的 330。后续 clamp 认为这个小框仍在图片内，因此不会修复固定边。四边算法把左边限制到 330−20=310，得到 x=310、w=20，右边仍然是 330。注释为本文补充，计算语句来自项目。
这两个结果来自提取当前源码函数后的执行，不代表已经在浏览器中复现全部视觉行为。它们说明边界验证至少要有两类断言：框是否被图片包含，以及非活动边是否保持原位。单测只写“没有越界”，会漏掉第二类问题。
6 数值边界之外 还要核对这些条件
首先是显示范围。getCropDisplayMetrics 使用 Canvas 的显示矩形作为边界，不能因此断言它就是任意编辑状态下的非透明图像轮廓。增加画布留白或偏移后，“不能超出画布”和“不能超出图片内容”是不同约束，需要先明确业务规则。任意角度旋转后的内容也不是轴对齐矩形，本篇公式不能直接约束其真实轮廓。
其次是 CSS。项目 crop-box 有 2px 边框，全局 main.css 对元素设置了 border-box，因此声明宽高包含边框。[2] 四个 12px 手柄使用 −6px 的边缘定位，本就会跨在选区边缘两侧。看到控件外伸，不能直接认定裁剪数据越界；若要求控件也完全可见，应调整命中区或显示布局，而不是悄悄缩小裁剪范围。
最小尺寸的单位也要明确。这里的 20 是显示像素，不是原图像素。若业务要求最少保留 N 个逻辑像素，需通过当前 totalScale 转为显示阈值，再检查可用空间。拖动期间保留小数，提交逻辑坐标时统一取整；项目 updateCropFromDisplay 已在取整后再次按剩余逻辑宽高限制尺寸，避免右边、下边因取整超出。
这套独立四边算法只适用于自由比例。固定比例会把宽高耦合，应同时求解比例与边界；把本函数直接用于 16:9 会改变比例。手势过程中若缩放、平移或容器尺寸发生变化，也必须取消当前手势或同步重建起始框和指针快照，不能混用新边界与旧坐标。
7 已验证什么 还需要验证什么
提取 ImageEditor.vue 的 applyCropDrag 及其依赖，以模拟显示尺寸和状态执行，复现了两个反例。建议算法覆盖 3 种起始框、8 种方向、横纵各 9 种位移，共 1,944 组缩放用例，验证包含关系、最小尺寸和非活动边不变。
整体移动覆盖同样的起始矩形与位移组合，共 243 组，验证宽高不变及边界包含。另有 3 个补充用例：两个反例的改进结果，以及 8×6 小图片的最小尺寸退让。以上均通过，建议 TypeScript 文件也通过严格类型检查。测试包含负位移、超大位移、小数和贴边满幅框，但不覆盖所有浮点数或非法输入。
建议浏览器验收 | 需要观察的结果 |
四角快速拖动与反向拖动 | 碰边后固定对角不动；拖过对边时停在最小尺寸 |
缩放与容器变化 | 边界来自当前画面；手势重建或取消策略一致 |
鼠标离开与触摸取消 | 没有残留拖动状态，事件生命周期完整 |
提交和真实导出 | 取整后的逻辑范围合法，导出内容与选区一致 |
这些浏览器项目是待验收清单。本次未运行页面自动化、移动端实机或导出像素测试。当前模板使用四角鼠标操作，触摸起点在框内时只进入 move；不要因为纯函数支持八种方向，就宣称项目已经提供八个手柄或完整触摸缩放。
结语
裁剪框的边界计算可以拆成两个明确的问题：整体移动时，为左上角求可行区间；改变大小时，固定对边，只限制活动边。把左、右、上、下写成显式坐标，再检查包含关系和固定边，比到处补 width、height 的上限更容易发现交互错误，也更容易写出有意义的测试。
源码与参考资料
源码位于 webClientVue/src：components/ImageEditor.vue 的 getCropDisplayMetrics、clampCropDisplay、applyCropDrag、updateCropFromDisplay 与裁剪样式；assets/main.css 的盒模型重置。建议纯函数未接入业务组件。
[1] MDN getBoundingClientRect
[2] MDN box-sizing
