Node.js 图片上传接口，先限制大小再谈体验

图片上传这类接口最容易在需求讨论里被说成一句话：选文件，传上去，返回地址。
可 2016 年我在做这类功能时越来越明显地感觉到，一个上传接口如果一开始只关注“体验顺不顺”，却没有先限制大小、类型和错误边界，后面出问题会非常频繁。

为什么“先能传上来”不等于接口已经稳

因为上传链路天生就会碰到很多不确定因素：

• 文件特别大
• 类型伪装
• 网络中断
• 重复提交

如果入口没有最基础的约束，后端就会被迫在更靠后的地方处理本来应该提早拦住的问题。

我后来会优先收哪些边界

哪怕功能还很早期，我也会先明确：

• 单文件最大体积
• 允许的类型范围
• 出错时返回什么信息
• 上传失败后前端应该怎么恢复

这些约束听起来不性感，却比“支持更多动效和预览”更能决定接口长期稳不稳。

大小限制为什么要最先做

因为它是资源成本最直接的一道闸。
如果文件体积不受控，上传请求会先把带宽、内存和处理时间一起拉高。尤其 Node.js 这种事件驱动环境，单次重请求带来的拖累会比想象中更明显。

先把大小收住，是在给后面所有体验优化留空间。

小结

图片上传接口当然要讲体验，但稳定的体验从来不是先做花哨反馈，而是先把边界收好。
2016 年之后我对这类接口的判断越来越简单：大小、类型、失败路径先站住，后面的体验才不会建立在脆弱链路上。