一个被很多开发者忽略的边界是：Base64 编码会让文件体积膨胀约 33%，进而触发服务端或托管平台的大小限制。有博客记录了一个典型案例：某应用允许上传 5MB 图片，前端将其转为 Base64 后 POST 到 Vercel 的 serverless 接口。但 Vercel 对请求体有 4.5MB 硬上限，5MB 的原图经 Base64 膨胀后变成约 6.7MB，请求在到达业务代码之前就被边缘节点以 413 拒绝。更糟的是，前端代码无差别地对响应调用 res.json()，而 413 返回的是纯文本 Request Entity Too Large，导致 JSON.parse 抛出 Unexpected token 'R'，用户看到的是一串 JSON 解析错误，完全无法理解发生了什么。
这个博客给出的修复思路是：上传前用 Canvas 在浏览器端自动压缩（最长边限制 1600px，JPEG 质量 0.85），同时增加容错解析------先尝试解析 JSON，失败则根据 HTTP 状态码映射为可读提示。
图片上传的"像素炸弹"防护
另一个容易被忽视的边界是图片的像素总量，而不仅仅是文件大小。Mozilla 的 Kitsune 项目在 PR 中专门增加了像素上限检查：虽然已有 10MB 文件限制，但他们发现一张经过精心压缩的小文件图片，解压后可能占据巨量内存（例如一张 20000×20000 的 PNG 可能只有几 MB，但解码需要数百 MB 内存），足以拖垮服务器进程。因此他们增加了 20 百万像素的上限，并集中在一个工具函数中处理文件大小和像素两个维度的校验，同时捕获 Pillow 的 DecompressionBombError。
拖拽上传中的浏览器默认行为拦截
一篇知乎回答详细指出了拖拽上传的边界陷阱：dragover 和 drop 事件必须显式调用 preventDefault，否则浏览器会直接打开拖入的图片文件，整个预览逻辑根本不会执行。作者还提到一个容易被误判的细节------框的 dragleave 事件不可靠，经常在鼠标尚未离开时误触发，正确做法是在整个页面的 dragenter 事件中判断目标是否仍在拖放区域内，以此控制高亮状态的添加和移除
。
预览地址的内存管理
同一篇知乎回答还强调了 URL.createObjectURL 的内存释放问题：每次选择新图片生成预览地址后，如果不在替换前调用 URL.revokeObjectURL 释放旧地址，反复换图会导致内存持续占用、页面越来越卡。这是一个典型的"不报错但会累积成问题"的边界场景。
wangEditor 相关的边界场景
针对你之前使用的 wangEditor，搜索结果中有几篇值得注意：
v5 的静默失败：wangEditor v5 废弃了 v4 的隐式上传逻辑，如果初始化时没有配置 uploadConfig（包含 server 或 customUpload），点击插入图片后能本地预览但不会发出任何上传请求，控制台也无任何报错。CSDN 上有开发者指出，这个静默终止点位于源码 insert-image.ts 中的 if (!config.uploadConfig) return;，容易让人误判为跨域或后端问题而浪费时间排查。
样式与上传的分离：有博客讨论了将图片的上传逻辑与展示样式解耦的方案，指出在上传时通过 customUploadImg 直接注入内联样式会导致样式与内容耦合、数据库存储冗余；更工程化的做法是利用 registerElemToHtml 在渲染阶段统一转换，从节点数据中提取样式信息生成最终的 HTML。
一个值得关注的工程细节
有一篇博客提到，在 CUA（计算机使用代理）沙箱环境中，为了保持坐标 1:1 映射，输入图片被要求保留原始宽高不做缩放，但同时会在大图（约 5MB 以上）上传时记录警告日志，因为可能违反模型提供商的上传限制。这与常规的"上传前压缩"策略是相反的，说明边界策略高度依赖于具体使用场景。