作为一名开发者，平时在做开发或者写文章时，经常需要对图片进行抠图、去水印或者尺寸裁剪。市面上的工具虽然多，但往往伴随着各种限制。本着“自己动手丰衣足食”的极客精神，我决定自己从零开发一个基于 AI 驱动的在线图像处理平台。
今天就和大家分享一下这个项目的技术栈选型、架构设计，以及在开发过程中踩过的一些坑，希望能给想要尝试全栈开发的同学一些参考。
1. 技术栈选型
在开始写代码前，我花了大概半天时间做技术选型。为了保证前后端类型安全并且提高开发效率，我全套使用了 TypeScript：
- 前端（Web）：
Vue 3+Vite+Pinia。Vue3 的 Composition API 在逻辑复用上确实比 Vue2 优雅很多，配合 Vite 的秒级热更新，开发体验极佳。 - 前端（小程序）：微信原生语法。为了照顾移动端用户，单独写了一套原生小程序，由于后端接口是解耦的，所以大部分接口可以直接复用。
- 后端：
NestJS。Node.js 生态里的企业级框架，它的依赖注入（DI）和模块化设计让代码结构非常清晰，特别适合做中大型项目。 - AI 算力层：底层对接了多个大模型 API（如火山引擎、阿里通义等），通过后端做了一层统一的路由和鉴权代理。
2. 核心功能与架构设计
2.1 前后端解耦与网关代理在架构设计上，我并没有让前端直接去请求第三方大模型的 API，而是全部走我的 NestJS 后端。这样做有几个好处：
- 密钥安全：第三方 API 的 Key 全部存放在服务器环境变量中，不会暴露给前端。
- 流量控制：可以在 NestJS 层做并发限制和重试机制，防止恶意刷接口。
- 日志追踪：方便在后端统计各个功能的调用成功率和耗时。
2.2 大文件上传与流式转发图像处理最核心的一环就是图片上传。在 NestJS 中，我使用了multer拦截器来接收前端传来的图片：
typescript
@Post('enhance')
@UseInterceptors(FileFieldsInterceptor([{ name: 'image', maxCount: 1 }]))
async enhanceImage(@UploadedFiles() files, @Req() req) {
const imageBuffer = files.image[0].buffer;
// 进行后续的业务路由转发
}
为了节省服务器带宽，处理后的结果图我会直接转存到 OSS，然后将外链返回给前端，而不是让图片流量再次穿透我的业务服务器。
2.3 AI 智能对话改图（核心亮点）在这个项目中，我引入了类似 Agent 的逻辑。用户只要输入自然语言（比如：“把图片里的背景换成海滩”），后端会先对用户的Prompt进行解析，根据需求动态路由到最适合的大模型（如专门负责抠图的模型，或专门负责重绘的模型）。
3. 踩过的坑与经验总结
- 跨域导致 Canvas 无法导出：在前端做原图/新图对比渲染时，如果新图是从第三方 OSS 加载的，必须要确保 OSS 配置了正确的
CORS头，并在前端的<img>标签上加上crossOrigin="anonymous"，否则会导致 Canvas 被污染，无法使用toDataURL导出图片。 - 长耗时请求的超时处理：AI 绘图往往需要 10~30 秒，Web 端很容易触发超时断开。我的解决方案是在前端配置长超时，并在后端捕捉请求断开事件（通过
req.on('close')），如果用户关闭了网页，后端会立刻Abort掉对大模型的请求，避免算力浪费。
4. 写在最后
折腾这个项目虽然花了不少周末的时间，但看着一个全栈项目从架构设计到一行行代码跑通，成就感还是满满的。目前项目已经跑通了大部分基础功能（抠图、去水印、AI改图等），我将它部署在了线上作为一个在线的 Demo 环境（体验地址：图片猫官网 www.piccat.cn），算是给自己交了一份全栈答卷。
对于想学全栈的同学，我非常建议大家不要只看教程，一定要自己找一个痛点需求，从建数据库、配 Nginx、写接口到画 UI 完整地走一遍，你会对整个 Web 体系有全新的认知。
大家在全栈开发中有遇到过什么有意思的坑吗？欢迎在评论区一起交流探讨！