基于Uniapp开发的深度学习模型检测查询系统
可以提供实现本软件的可复现源码一、基于Vue+Flask+SQLite的网站系统
主要缺点在于:
•Vue开发的前端局限于H5网站端,极大的限制的系统的使用场景难以应用于实际;•Flask后端接口API过于内聚,难以进行扩展;对于普通用户与管理员用户权限没有进行区分;•SQLite文件存储与数据量上限,功能特性有限;
二、基于Uniapp+Flask+MYSQL的一站式平台
主要改进点:
1、为什么改用Uniapp而不是基于传统基于Vue框架开发的纯Web网站
多端一体化覆盖(代码复用度高)
•纯 Vue Web 只能直接面向浏览器(PC/移动端 H5)用户,需要额外开发才能支持小程序或原生 App•UniApp 在同一套 Vue 语法下,可一键编译为各类小程序,H5 页面,原生 iOS/Android App(以及快应用等)•仅需维护一份代码,就能触达几乎所有主流渠道,降低了推广成本
简化上线与迭代流程
•做纯 H5 网站时,想要再上线到微信小程序,需要重新搭建小程序项目、改写页面和 API 逻辑;而 UniApp 可以直接生成对应小程序包并上传审核。
统一调用系统与硬件能力
对于摄像头、传感器、推送、支付、蓝牙等原生能力,纯 H5 常需借助 Hybrid 框架(Cordova/Capacitor)或编写各端插件;而 UniApp 内置了 uni.* API,将常见的原生能力封装好,兼容各小程序与 App 端。
只需一套 uni.request()、uni.scanCode()、uni.getLocation() 等调用即可,无需手动分别适配微信小程序、支付宝小程序、Android、iOS,节省大批桥接工作
2、为什么使用MYSQL数据库替代SQLite
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在项目由原型或小规模内部应用逐渐演变为面向公网、具备多终端访问与高并发要求的线上系统时,用 MySQL 替代 SQLite,能够获得更好的并发性能、更丰富的数据库特性、更完善的运维生态与更强的可扩展性,从而满足业务持续增长的需求。
3、对Flask后端的优化
detection/├── __init__.py├── app.py # 应用工厂或初始化入口,只做 “创建 app + 注册蓝图 + 读取配置” 等├── config.py # 定义 Config、DevelopmentConfig、ProductionConfig 等├── models.py # ORM 模型定义(比如 SQLAlchemy model)├── auth.py # 负责用户登录/注册、Token 验证的路由与函数├── routes.py # 负责其他业务相关的路由(Item、Order、Profile 等)├── utils.py # 工具函数(加密、分页、日期处理等)├── reset.py # 重置数据库或初始化数据的脚本(也可以当作 CLI 脚本单独运行)──app.py #启动文件
将原先核心代码全部集成在app.py文件中,改为将不同功能拆分到多个模块的结构;
优势在于:
•
职责单一
•config.py 负责配置和环境变量•models.py(或 models/ 目录)负责定义数据模型/ORM•routes.py 负责把所有路由(API Endpoint)集中管理•auth.py 负责与用户认证/授权相关的视图或函数•utils.py 放通用工具函数(如加密、格式转换、分页器等)•reset.py 专门处理一些重置/初始化的脚本
可维护性与可扩展性更高
•轻松添加新功能•模块化引用与重用
•提高代码可读性与可测试性
•更清晰的架构脉络•单元测试更方便
三、出现的问题
1、routes.py提供的是/users而前端请求时需要请求/api/users的原因
app.register_blueprint(api_bp, url_prefix="/api")将api_bp蓝图中的所有接口都统一挂载到/api的路径之下
|
|
|
|
app.register_blueprint(api_bp) |
|
/users |
app.register_blueprint(api_bp, url_prefix='/api') |
/api 前缀 |
/api/users |
app.register_blueprint(api_bp, url_prefix='/v1') |
/v1 前缀 |
/v1/users |
为什么要保留/api前缀的原因
•RESTful 规范推荐:所有接口统一在 /api/ 下,避免和前端页面路径 /home、/login 冲突•未来扩展方便:如你要引入 /api/v2/、/admin/api/ 等不会混乱•统一代理配置:前端开发时可统一设置 /api 代理转发
2、当在微信小程序登录时采用Session是终是无法登录成功,为什么利用Token令牌来替代Session会话
•Token更加适合前后端分离、多端登录、跨域、微服务,而传统Session依赖于服务器内存,不易扩展
|
|
|
|
|
|
|
|
|
|
有状态
|
无状态
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
微信不支持跨域 Cookie(Session 无效) |
|
3、密码的存储 和 Token 的生成与验证
单向加密—不可逆哈希,不能采用JWT保存密码,密码不能被解密
from werkzeug.security import generate_password_hash, check_password_hash# 存储时(加密)user.password = generate_password_hash("your_password")# 验证时(对比)check_password_hash(user.password, "user_input_password") # 返回 True / False
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4、管理员与普通用户的权限设置
|
|
|
@token_required |
|
@admin_required |
current_user.status == "管理员" 验证权限 |
current_user |
|
权限覆盖面
|
|
|
|
|
|
@admin_required |
|
|
|
@token_required |
|
|
|
@admin_required |
|
|
|
@admin_required |
|
|
|
@token_required |
|
|
|
@admin_required |
|
|
|
@token_required |
|
|
|
|
|
四、页面展示
|
|
普通用户端 |
![]() |
![]() |
|
|
|
![]() |
![]() |
|
|
|
![]() |
![]() |
|
|
|
![]() |
![]() |

夜雨聆风








