★ FEATURED ARTICLE 目标检测项目被很多面试官列为“最有性价比的全栈练手方向”原因很简单YOLOv5做模型、Flask做服务、Vue做界面一条链路打通了算法和工程。今天我把这个平台的完整搭建经验整理出来从后端接口设计到前端画框渲染再到面试考点一次性讲透。这个项目不是让你做一个只能跑通Demo的玩具。它要解决的是三类人的真实痛点准备面试的人缺一个能撑住深挖的项目算法工程师想补工程化能力后端或前端工程师想摸一摸模型推理的链路。一套代码覆盖检测模型封装、REST API设计、可视化交互、性能优化、部署上线每个环节都有面试官愿意追问的技术点。先说清楚这篇文章不是教程式地贴全部源码而是把整个项目的设计思路、关键实现、踩坑过程和面试应答逻辑拆开讲。你照着思路搭一遍比背十篇面试题都管用。1. 这个项目解决什么问题为什么 CRUD 项目在面试里越来越不吃香1.1 面试官真正想从项目里看到什么我帮不少人改过简历发现一个共性现象大多数人写的项目都是“某某管理系统”“某某后台”功能描述翻来覆去就是用户管理、权限管理、订单管理。这类项目的技术点高度同质化面试官问几轮就到底了最后的结论通常是“没做过什么有挑战性的东西”。面试官在项目环节真正想看的不是功能列表而是三个信号你遇到没遇到过真实问题、你是怎么拆解和解决的、你能不能把自己的方案讲清楚。目标检测平台恰好能把这三个信号全部打满。它不是增删改查而是“上传一张图模型推理前端画框”的完整闭环里面涉及模型原理、接口设计、并发处理、坐标换算、性能调优任何一个环节都能引出一连串有深度的问题。1.2 目标检测平台覆盖的三种能力为了直观我列了一张表标注这个项目分别锻炼和展示了哪些能力能力维度项目里对应的部分面试能引出的问题算法理解YOLOv5 推理流程、NMS、IoU、置信度阈值聊聊 NMS 的流程IoU 怎么算mAP 怎么来的后端工程Flask 接口设计、模型单例加载、异常处理模型为什么只加载一次为什么 Flask 够用前端工程Vue 组件设计、Canvas 画框、axios 异步交互画框坐标怎么换算大图加载怎么优化这三条线里任意一条单独拿出来都可以支撑一段十分钟的面试对话。更关键的是它们彼此之间有结合点比如“检测框的坐标从后端传到前端之后前端怎么映射到图片上”——这个问题单纯做算法或单纯做前端的人都答不完整而你做过整个闭环回答起来自然很扎实。1.3 项目最终做到什么程度我给一个明确的功能边界你搭的时候照着这个范围做就行不用盲目加功能后端提供模型推理服务支持上传图片返回检测框坐标、类别、置信度、推理耗时前端支持本地上传、拖拽上传检测结果以彩色边框和标签形式叠加在图片上展示检测统计信息比如检测到多少个目标、每类目标分别有多少个、单次推理耗时支持切换不同大小的模型权重文件比如在 yolov5s 和 yolov5m 之间切换观察精度和速度的差异整体走通生产部署链路用 Gunicorn 或 Docker 启动服务。这个范围说大不大说小不小。它不包含训练环节因为训练是另一套话题会过度分散项目的主线。项目主标题是“推理平台”核心价值在工程封装和可视化训练部分你用官方预训练权重带过去就行。2. 技术选型的三个理由YOLOv5、Flask、Vue 为什么是“面试友好组合”2.1 检测模型为什么选 YOLOv5 而不是 YOLOv8 或 DETRYOLO 系列现在迭代到了 v8、v9甚至还有各种非官方版本为什么我坚持推荐 YOLOv5第一个原因是生态成熟度。YOLOv5 的 GitHub 仓库、官方文档、社区博客极其丰富遇到问题很容易搜到解决方案。它的使用方式已经高度标准化一行命令下载权重几行代码就能跑推理训练和评估的脚本也都现成。对于面试项目来说你能把精力集中在工程实现上而不是纠结模型源码。第二个原因是面试场景的匹配度。YOLOv5 的模型结构是 CSPDarknet 骨干加 PANet 颈部加 YOLO Head这套结构是目标检测领域的基础知识面试官大概率熟悉。你聊它的时候可以自然地引出 backbone、neck、head 的分工引出 anchor 机制引出损失函数的概念。换成 DETR 这类 Transformer 方案结构复杂性高面试官如果不是做检测方向的反而聊不到那么深。第三个原因是性能和精度的平衡。YOLOv5s 在 CPU 上也能跑出可以演示的速度这对项目演示很重要。你不可能在面试现场保证有 GPUCPU 上能跑起来是底线。表面对比如下对比项YOLOv5YOLOv8DETR文档与社区资源极丰富较丰富偏研究向面试基础认知度高中高偏低CPU 推理友好度高s/m 体积小中高较低结构讲解难度适中适中较难2.2 后端框架为什么 Flask 而不是 FastAPI 或 Django很多人一上来就想用 FastAPI理由是它异步、性能好、自带 Swagger 文档。这些优势我都承认但放在这个项目里有几个问题。最核心的一点YOLOv5 的 PyTorch 推理是同步阻塞操作你就算把 FastAPI 的 async 语法用出花来模型前向传播那几百毫秒还是同步的。对于单个请求FastAPI 的异步优势在这个场景基本发挥不出来。Flask 的同步 worker 模型反而和推理操作天然匹配一个请求占用一个 worker跑完返回逻辑清晰。第二个理由是 Flask 的普适性。去面试的时候聊 Flask 不会有什么争议它仍然是国内后端岗位里使用率极高的框架。面试官听到 Flask脑子里立刻能调出相关的知识框架。Django 则偏重、模板和 ORM 都是自带的一套体系对这个项目来说太重了。第三个理由是 Flask 的扩展能力刚好够用。文件上传用 Werkzeug跨域用 Flask-CORS项目结构用 Blueprint 拆分这些在 Flask 生态里都是标准操作。我要强调一个观点选型不是为了追求最新最炫而是为了在面试表达中让你的每一步选择都有清晰的逻辑支撑。2.3 前端框架为什么 Vue 而不是 ReactVue 在这个项目里最大的优势是“渐进式”。你可以只用一个 Vue 实例加几个组件就把页面搭起来不需要折腾 Redux、Router 这些对单页功能来说多余的东西。Canvas 画框的逻辑在 Vue 的 template 里也很直观图片传进来计算属性负责生成坐标数据watch 或方法触发重绘。React 当然也能做但 Vue 的中文文档、国内社区生态、模板语法对中文开发者更友好搭界面效率更高。而且面试时 Vue 的响应式原理数据劫持、依赖收集本身就是一个经典考点项目里用到了组件通信、计算属性、生命周期正好把这些考点全部激活。选 Vue 不是为了贬低 React而是选那个让项目成本和面试收益比最高的方案。3. 后端工程化核心模型加载、接口设计、推理调度3.1 模型不能每次请求都加载一次单例与预热新手写 Flask 接口最容易犯的错误是把模型加载写在视图函数内部。每次请求进来都执行一遍torch.load结果就是第一次请求等十秒第二次请求还等十秒偶尔还会内存爆掉。正确做法是模块加载时完成模型初始化之后所有请求复用同一个模型实例。我给一个标准的模型管理模块的骨架# model_manager.py import torch from yolov5.models.experimental import attempt_load from yolov5.utils.general import non_max_suppression from yolov5.utils.torch_utils import select_device class ModelManager: _instance None def __new__(cls, *args, **kwargs): if cls._instance is None: cls._instance super().__new__(cls) return cls._instance def __init__(self, weights_pathyolov5s.pt, device): if hasattr(self, model): return self.device select_device(device) self.model attempt_load(weights_path, map_locationself.device) self.model.eval() # 预热跑一次全零输入让 CUDA 完成初始化 dummy_input torch.zeros((1, 3, 640, 640)).to(self.device) _ self.model(dummy_input) print(模型加载与预热完成) def predict(self, img_tensor): with torch.no_grad(): return self.model(img_tensor)[0]这里用单例模式保证模型只初始化一次用预热操作解决“第一个请求特别慢”的问题。预热在 GPU 上尤其重要因为 CUDA 上下文初始化通常要花几百毫秒到几秒提前跑一次推理能把这部分时延转移到服务启动阶段。3.2 接口设计输入输出规范从哪里来后端接口不要拍脑袋定先想清楚前端要什么。检测平台的前端最终要画框、显示类别和置信度、统计目标数量所以后端返回的数据结构应该长这样{ success: true, detections: [ { box: [50, 80, 300, 420], label: person, confidence: 0.91 } ], num_detections: 1, inference_time_ms: 85.3, width: 640, height: 480 }box我习惯用[x1, y1, x2, y2]的绝对坐标格式前端拿到的就是原图坐标系里的值画框时不需要后端参与缩放计算。num_detections看起来冗余但对前端统计展示非常方便减少一次数组求长度的逻辑。width和height是原图尺寸前端做坐标映射的基准。对应的路由设计如下app.route(/api/health, methods[GET]) def health(): return {status: ok} app.route(/api/detect, methods[POST]) def detect(): # 1. 校验文件是否存在 # 2. 校验文件类型和大小 # 3. 读图并预处理 # 4. 推理 NMS # 5. 组织响应 JSON健康检查接口看起来简单但在部署和面试时都是加分项。部署后你可以用curl快速验证服务是否存活面试时你可以说“我设计了健康检查接口方便运维探活”这比单纯说“我写了检测接口”要工程化得多。3.3 推理管线letterbox、前向传播、NMS 后处理YOLOv5 要求输入尺寸是 32 的倍数默认是 640×640。直接 resize 会破坏长宽比导致目标变形、检测精度下降。正确做法是 letterbox保持长宽比缩放图片再把剩余区域用灰色填充。def letterbox(img, new_shape(640, 640), color(114, 114, 114)): shape img.shape[:2] r min(new_shape[0] / shape[0], new_shape[1] / shape[1]) new_unpad (int(round(shape[1] * r)), int(round(shape[0] * r))) img cv2.resize(img, new_unpad, interpolationcv2.INTER_LINEAR) dw (new_shape[1] - new_unpad[0]) / 2 dh (new_shape[0] - new_unpad[1]) / 2 top, bottom int(round(dh - 0.1)), int(round(dh 0.1)) left, right int(round(dw - 0.1)), int(round(dw 0.1)) img cv2.copyMakeBorder( img, top, bottom, left, right, cv2.BORDER_CONSTANT, valuecolor ) return img, r, (dw, dh)预处理把原图转成模型需要的 1×3×640×640 张量推理输出是一个包含边界框、置信度和类别概率的原始张量。non_max_suppression是关键后处理它先按置信度阈值筛掉低分框再通过 IoU 计算去掉重复框。NMS 的流程我在项目里理解得特别透彻因为跑一遍你会看到它的实际效果——没有 NMS一张图里同一个物体会输出好几个重叠框加上 NMS 之后每个目标只剩一个框。这个现象本身就是面试时最好的素材你可以顺手画一下 NMS 的流程先排序置信度取最高分框删除与其 IoU 超过阈值的框循环往复直到处理完所有框。3.4 错误处理与边界条件后端不能只管正常流程边界条件处理不到位演示时随时翻车。我总结了这个项目必须处理的几类异常异常场景处理方式返回状态没有上传文件判断file is None400上传了非图片格式校验 MIME 类型和扩展名400图片超过大小限制限制MAX_CONTENT_LENGTH413图片解码失败捕获cv2.error400模型推理异常全局异常钩子捕获500比如文件类型校验我见过有人只检查扩展名然后传一个改名为.jpg的病毒文件进来cv2.imread返回空对象后端直接 500。正确做法是同时检查 MIME 类型和imread的结果ALLOWED_EXTENSIONS {jpg, jpeg, png, bmp} def allowed_file(filename): return . in filename and filename.rsplit(., 1)[1].lower() in ALLOWED_EXTENSIONS file request.files.get(file) if file is None or file.filename : return {error: 未选择文件}, 400 if not allowed_file(file.filename): return {error: 不支持的图片格式}, 400在整体设计上我建议把不同模块拆到不同文件里app.py只做路由注册model_manager.py管模型生命周期detector.py管预处理和后处理config.py管路径和设备参数。这个拆分本身就是“工程化”三个字的一部分面试官看一眼你的项目结构就知道你有没有模块化意识。4. 前端可视化Canvas 画框、上传交互与结果呈现4.1 组件划分不要把一个页面写成一块铁板前端我用 Vue 3 加 Vite 构建。页面功能不复杂但如果全部堆在App.vue里很快会变得没法维护。我分成三个组件UploadPanel.vue负责上传交互ResultCanvas.vue负责图片展示和画框StatsPanel.vue负责检测结果的统计展示。父组件持有图片地址和检测结果通过 props 传给子组件子组件通过事件和父组件通信。这个划分的核心逻辑是“关注点分离”上传逻辑和画框逻辑互不干扰统计面板只接收数据、不管数据怎么来的。面试时被问到“组件之间怎么通信”你就可以讲父传子 props、子传父 emit再补充一个你说过的场景——比如 ResultCanvas 需要根据图片尺寸调整 Canvas 大小用 watch 监听图片地址变化后触发重绘。4.2 上传交互axios 封装与 loading 状态上传用axios发送FormData。有个细节大图推理可能要一两秒甚至更久期间用户可能会重复点击上传。必须做 loading 状态锁按钮置灰并显示“检测中”。// api.js import axios from axios; const http axios.create({ baseURL: /api, timeout: 30000 }); export function detectImage(file) { const formData new FormData(); formData.append(file, file); return http.post(/detect, formData, { headers: { Content-Type: multipart/form-data } }); }组件里这样使用const loading ref(false); const result ref(null); async function handleUpload(file) { if (loading.value) return; loading.value true; try { const res await detectImage(file); result.value res.data; } catch (err) { // 错误提示 } finally { loading.value false; } }timeout: 30000这个参数很重要。默认的 axios 超时可能只有几秒一张大图在 CPU 上推理很容易超时结果就是前端报错、后端实际已经跑完了。我因为这个问题在演示时翻过一次车后来统一把超时调到了 30 秒并且在前端对图片做了尺寸限制超过 2000px 的图先等比压缩再上传。4.3 Canvas 画框坐标系换算才是核心难点画框听起来很简单调用 Canvas 的strokeRect就行。真正麻烦的是坐标换算。后端返回的坐标是原图坐标系而 Canvas 的显示尺寸可能和原图尺寸不一致因为图片在页面上是按比例缩放的。如果直接用原图坐标画框框的位置会偏。解决方案是拿到图片的实际显示尺寸计算缩放比例再映射坐标function drawDetections(canvas, image, detections) { const ctx canvas.getContext(2d); const displayWidth canvas.clientWidth; const displayHeight canvas.clientHeight; const scaleX displayWidth / image.naturalWidth; const scaleY displayHeight / image.naturalHeight; ctx.drawImage(image, 0, 0, displayWidth, displayHeight); detections.forEach((det) { const [x1, y1, x2, y2] det.box; ctx.strokeStyle #00ff88; ctx.lineWidth 2; ctx.strokeRect(x1 * scaleX, y1 * scaleY, (x2 - x1) * scaleX, (y2 - y1) * scaleY); ctx.fillStyle #00ff88; ctx.font 14px sans-serif; ctx.fillText(${det.label} ${(det.confidence * 100).toFixed(1)}%, x1 * scaleX, y1 * scaleY - 4); }); }这里面有一个很容易被忽略的坑canvas.clientWidth取的是 CSS 渲染后的宽度而image.naturalWidth取的是图片原始像素宽度。如果你用image.width得到的是 DOM 属性宽度和 CSS 宽度可能不一致画框就会偏。我最终在代码里强制把 Canvas 的宽高和图片显示区块的宽高保持一致再配合object-fit: contain处理不同宽高比的图片。文本标签的位置也有讲究。如果目标在图片顶部标签画在框上方会超出 Canvas 边界所以要做一次越界判断把文字放到框内部。这个细节看起来小但演示时出现一个标签显示不全观感就很差。4.4 结果统计与交互体验StatsPanel 展示三块信息检测总数、各类别数量分布、推理耗时。核心是这些数据不在后端一次性算好而是前端基于 detections 数组用计算属性动态生成const stats computed(() { if (!result.value) return null; const byLabel {}; result.value.detections.forEach((d) { byLabel[d.label] (byLabel[d.label] || 0) 1; }); return { total: result.value.num_detections, byLabel, time: result.value.inference_time_ms }; });再做一次“重新检测”按钮触发同一个文件的重新上传。这个功能实现不难但演示效果很好换个模型权重点一下重新检测精度和耗时的差异直观地摆在眼前面试官很难不顺着这个话题继续追问。5. 性能优化与部署落地从开发机到“能演示”的完整链路5.1 CPU 推理能优化的空间很多人默认推理必须要 GPU其实 CPU 上也有一套成熟的优化组合。第一个是半精度推理把模型参数转为 FP16。GPU 上效果明显CPU 上虽然不一定提升但可以显著降低内存占用。第二个是限制线程数和推理尺寸。YOLOv5 官方提供了export.py脚本可以把 PyTorch 模型导出为 TorchScript 或 ONNX 格式。ONNX 配合 ONNX Runtime 推理在 CPU 上的速度通常比原生 PyTorch 快 20% 到 50%而且部署时不需要安装完整 PyTorch 环境。我在项目里预留了一个开关通过配置文件选择使用 PyTorch 还是 ONNX Runtime 后端# config.yaml model: weights: model/yolov5s.pt device: cpu backend: onnx # pytorch / onnx img_size: 640 conf_thres: 0.4 iou_thres: 0.45这里还有一个项目选型层面的思考默认推理尺寸 640×640 在 CPU 上约需 100 到 300 毫秒取决于机器如果换成 320×320速度可以提升四倍左右精度只是轻微下降。对于演示场景把模型尺寸和阈值都做成可配置的本身就是“工程化”的体现。5.2 服务端并发与模型内存的平衡Flask 自带的开发服务器只能应付单用户调试上线演示至少要用 Gunicorn 起多 worker。但是这里有个经典陷阱模型在内存里占几百 MB如果 Gunicorn 起了 4 个 worker每个 worker 都会加载一份模型4GB 内存瞬间吃满。解决方案有两种。第一种模型不大且内存充足直接用preloadTrue让 Gunicorn 启动前先加载模型再 fork 出多个 worker利用写时复制机制让 worker 共享模型内存。第二种模型较大或者高峰期并发不高就用 1 个 worker 加多线程模式。我实际项目的做法是gunicorn -w 2 -b 0.0.0.0:5000 --preload app:app--preload的副作用是如果模型加载失败错误会在启动阶段暴露而不是等到第一个请求。这对部署友好很多值得在面试时提一句。5.3 Docker 打包与环境一致性“在我电脑上能跑”在面试里是减分项Docker 化之后一句话就能解决环境问题。Dockerfile 的几个关键点FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . # 下载 YOLOv5 权重到指定位置 RUN python -c from yolov5.utils.downloads import attempt_download; attempt_download(yolov5s.pt) CMD [gunicorn, -w, 2, -b, 0.0.0.0:5000, --preload, app:app]用python:3.9-slim而不是完整版镜像镜像体积可以控制在 1GB 以内。如果你是 CPU 推理不用装 CUDA 相关的包镜像还能更小。前端构建后可以用 Nginx 托管静态文件同时把/api路径反向代理到 Flask 服务这样生产和开发共用同一套接口路径前端不需要区分环境。5.4 前端构建产物与后端服务的结合方式关于前后端如何结合我见过三种方案开发时前后端分离跑两个端口生产时前端构建产物交给 Nginx、后端单独跑或者直接把 Vue 构建出的dist目录挂到 Flask 的static目录下由 Flask 统一服务。后一种方案更适合面试项目它没有引入 Nginx 这种额外组件部署链路更短。我在项目里用的是 Flask 挂载 dist 目录的方案。这样整个项目最终只有一个服务端口一条命令启动面试时演示没有任何多余的配置步骤。如果你后续想深入部署再切到 Nginx 方案也不难核心改一下静态文件路径和代理规则就行。6. 面试考点全覆盖这个项目里能挖出来的问题清单6.1 算法层的经典追问面试官看到目标检测项目第一反应是问模型本身。我建议你提前准备以下几类问题每类都能从项目里找到实际对应点NMS 是必问的。它的作用是解决同一目标被多个预测框重复覆盖的问题。流程是所有框按置信度排序选择最高分框保留然后和剩下的框逐一计算 IoUIoU 超过阈值的框直接丢弃重复这个步骤直到没有框剩下。我在项目里调过iou_thres从 0.4 调到 0.6 的效果差异是阈值越高重复框越多但对紧密相邻的多个目标更友好。IoU 的含义要能用一句话讲清楚两个框的交集面积除以并集面积用来衡量两个框的重合程度数值范围 0 到 1。面试官很可能让你当场手写 IoU 计算代码其实很短def iou(box1, box2): x1 max(box1[0], box2[0]) y1 max(box1[1], box2[1]) x2 min(box1[2], box2[2]) y2 min(box1[3], box2[3]) inter max(0, x2 - x1) * max(0, y2 - y1) area1 (box1[2] - box1[0]) * (box1[3] - box1[1]) area2 (box2[2] - box2[0]) * (box2[3] - box2[1]) return inter / (area1 area2 - inter)mAP 是目标检测里最常用的评价指标。它衡量模型在不同置信度阈值下的平均精确率。自然语言解释就是对每个类别计算不同召回率下的精确率画 PR 曲线求面积再对所有类别取平均。面试时能把这条链路讲清楚已经超过大多数候选人。6.2 工程层的常见问题工程类问题主要围绕 Flask 和 Vue。Flask 和 FastAPI 的区别是最常被问的。我的回答话术是FastAPI 基于 ASGI 支持原生异步适合 I/O 密集型场景自带交互式文档Flask 是 WSGI 同步框架生态成熟、上手简单。本项目是 CPU 推理属于计算密集型任务同步模型和 Flask 天然匹配异步带来的收益有限所以我选 Flask。模型加载为什么不放在请求函数里因为torch.load是重量级操作一个模型几百 MB加载需要几秒甚至更久。如果每个请求都加载服务会频繁卡死内存也会被撑爆。我把它提到服务启动阶段做单例初始化用预热跑一次推理确保后续请求稳定。CORS 问题也值得准备。开发时前端跑 5173 端口、后端跑 5000 端口浏览器会拦截跨域请求。我的做法是给 Flask 加flask-corsfrom flask_cors import CORS CORS(app, resources{r/api/*: {origins: *}})面试时被问到“你遇到过跨域问题吗”这就是一个很好的切入点你可以接着讲前后端分离架构的特点。6.3 项目表述的六层回答框架有了项目不会表达等于白做。我总结了一套回答框架大家可以直接套用第一层讲背景为什么做这个项目。回答“因为我想把算法模型落地成完整的 Web 应用打通从推理到可视化的全链路”。第二层讲技术栈YOLOv5 做检测、Flask 做后端、Vue 做前端。第三层讲核心难点模型生命周期管理、坐标换算、CPU 推理性能优化。第四层讲解决方案单例加载加预热、Canvas 按显示尺寸映射坐标、ONNX Runtime 加速。第五层讲结果平台可以完成图片上传、实时检测、可视化展示和统计。第六层讲反思如果重新做我会加上批量检测任务队列、用消息队列处理异步任务、引入 Redis 做结果缓存。这套框架的好处是每一层都能接住面试官的追问。比如你讲到坐标换算面试官就可能顺着问去了解 Canvas 绘制机制。你讲到模型生命周期就可能问你 Python 单例模式、Gunicorn worker 模型。所有问题都在你的准备范围内。7. 真实踩坑记录文档里查不到的那些问题7.1 中文文件名引发的编码事故第一次测试时我上传了一张“测试图片.jpg”后端返回成功但是接下来怎么都读不出图。排查了半天发现某些系统环境下cv2.imread读中文路径文件会直接返回None而且不报错。这就是所谓的“静默失败”。解决方式是统一改用cv2.imdecode读取绕开文件系统路径编码问题def read_image_from_file(file_storage): filestream file_storage.read() np_arr np.frombuffer(filestream, np.uint8) img cv2.imdecode(np_arr, cv2.IMREAD_COLOR) if img is None: raise ValueError(图片解码失败) return img另外保存文件时用uuid重命名彻底避免中文和特殊字符问题。这两个改动看起来小但它们属于“经验性知识”网上文档不会主动告诉你。7.2 Flask debug 模式导致模型加载两次开发调试时我把debugTrue打开结果发现程序启动后模型被加载了两次内存翻倍启动时间也翻倍。原因是 Flask 的 debug 模式会自动启动 reloader主进程加载一次模型子进程又加载一次。解决方法是两层第一层调试时明确关闭 reloaderapp.run(debugTrue, use_reloaderFalse)第二层模型加载用单例模式子进程再加载时检查实例是否已存在。这个坑我第一次遇到时排查了很久因为模型加载两次不报错只是内存异常你很难第一时间想到是 reloader 在作怪。7.3 Canvas 画框偏移问题画框偏移是前端最大的坑。我在 4.3 节已经讲了坐标映射的方案但这里补充一个更隐蔽的问题当图片显示区域使用了 CSS 的max-width: 100%时canvas.clientWidth在不同浏览器里的精度不同导致框的位置有 1 到 2 像素的偏差。解决方案是在图片load事件触发后读取图片的自然尺寸再把 Canvas 的像素尺寸设置成和显示尺寸一致最后用getBoundingClientRect获取精确的渲染尺寸来计算缩放系数。这套组合下来画框精度完全可控。这个细节我说得很细因为它是整个前端部分技术含量最高的环节。7.4 大图超时与内存压力第一次用一张 8000×6000 像素的航拍图测试前端直接超时后端进程的内存占用飙升到 2GB 以上。原因很直接大图经过 letterbox 缩放后虽然只有 640×640但imdecode解码时的内存峰值仍然和原始分辨率成正比。我做了三层防护前端在上传前检查图片尺寸超过 3000 像素就等比压缩后端设置MAX_CONTENT_LENGTH限制文件大小为 10MB推理前如果检测到图片过大先用cv2.resize等比缩放到 2000 像素以内。这三层组合起来基本堵死了大图导致的超时和内存问题。7.5 多进程下 CUDA 显存溢出如果服务器有 GPU在 Gunicorn 多 worker 模式下每个 worker 都会加载一份模型显存直接溢出。这个问题在面试里也经常被追问我的回答是GPU 场景下要么限制 worker 数为 1要么用显存共享方案。显存共享比较复杂不建议在面试项目里做我最终的做法是 GPU 场景强制单 workerCPU 场景可以多 worker。这个取舍本身也能体现工程判断力面试时我会说“我根据推理场景的特点选择了合适的并发模型而不是盲目堆 worker”。把取舍逻辑讲清楚比实现的复杂程度更能打动人。做完这个项目到现在我最大的体会是一个项目能不能在面试里立住不取决于它用了多新的技术而取决于你把每个环节的“为什么”想明白了没有。模型加载为什么用单例、坐标为什么在前端换算、部署为什么选 Gunicorn、并发怎么权衡这些问题你在亲手搭建的过程中会自然形成答案。建议你搭完以后把每个决策点写成一两句话的记录面试前翻一遍效果比背题库好得多。
阅读完成 · 觉得有帮助？
