Python + Vue 前后端分离：手把手实现企业级项目分配与进度管理系统

做企业内部项目管理系统最怕的不是功能多而是做完没人用。我前后给三家公司搭过项目分配和进度追踪的体系最后都收敛到一个结论管理系统的核心不是“管理”而是让每个人打开系统就能秒懂“我该干什么、现在干到哪了、下一步谁来接”。这个 Python Vue 前后端分离的项目分配进度管理系统就是围绕这个思路落地的。后端用 Python 生态处理权限、任务状态流转和统计数据前端用 Vue 做项目卡片、任务看板和进度可视化整条链路覆盖了从“立项拆任务”到“成员汇报进度”再到“管理者看板”的全流程。无论你是准备拿它当毕业设计还是团队内部想自建一套轻量管理工具这篇记录都能给你一套能直接抄作业的完整方案。1. 先想清楚这套系统到底要解决什么很多初学者拿到这种题目第一反应就是“不就是增删改查嘛”。真上手才会发现增删改查只是地基真正决定系统好不好用的是业务规则怎么落地到代码里。1.1 传统管理方式的痛点没做过企业项目的人可能感受不到但凡是带过 5 人以上开发团队或项目组的一定经历过这些场景任务分配靠开会会开完了谁负责哪块全靠记。进度汇报靠微信群里接龙消息一刷屏关键信息就被淹没了。项目延期了负责人想复盘却发现根本说不清“卡在哪个环节、卡了几天”。新人接手项目看到一堆文件文档不知道哪些任务还开着、哪些已经验收。这个系统要做的就是把上面所有“靠人盯”的事情变成“系统自动流转”。项目立项后负责人拆解任务、指定成员、设置截止时间成员登录后看到的是自己的待办清单做完一项就更新状态管理员或项目经理随时能看整体进度、延期预警和成员负载。换句话说系统要充当一个不睡觉的项目助理。1.2 核心功能模块拆解从使用者的角度倒推系统可以拆成四个核心模块模块核心功能面向角色登录认证登录、注册、JWT 鉴权、修改密码所有用户项目管理创建项目、编辑信息、项目成员管理、项目状态管理管理员、项目经理任务分配任务创建、指派成员、设置优先级与截止时间、进度更新项目经理、普通成员统计看板项目进度总览、任务状态分布、成员负载统计所有人按权限显示至于消息通知、评论协作、附件上传这些扩展功能初期先不做把主流程跑通比堆功能重要得多。系统设计上预留了通知功能的表结构后续要加也就是写个定时任务的事。1.3 用户角色与权限边界权限设计我采用的是最常见的三角色模型管理员、项目经理、普通成员。管理员拥有全部权限可以管理用户账号、查看所有项目、指派项目经理项目经理可以创建项目、拆分任务、调整优先级、关闭项目普通成员只能看到自己被分配的任务以及所在项目的概况不能跨项目操作。这里有个容易踩坑的点很多人会把权限做得很复杂比如细化到“谁能看哪个字段”。实际企业内部用太细的权限只会让开发成本和沟通成本成倍上涨。角色控制在 3 个以内权限精确到“页面级别 关键操作级别”基本覆盖 80% 的场景。剩余 20%用“项目内成员可见”这个硬规则去兜底既简单又好解释。还有个细节普通成员也应该能看到项目的整体进度只是不能修改。这能提升成员的参与感不至于觉得“我只管自己那一亩三分地”。2. 技术选型为什么是 Python Vue这个组合在技术社区里已经是非常成熟的搭配了但成熟不等于无脑选还是要弄清楚背后的取舍逻辑。2.1 后端框架的选择Python 后端的主流选择有三个Flask、Django、FastAPI。我最终用的是Flask SQLAlchemy MySQL。选择 Flask 的原因很直接项目的业务逻辑主体是常规 CRUDFlask 的灵活性能让你把精力集中在业务规则上而不是被框架的“全家桶”牵着走。Django 自带 Admin 后台和 ORM确实是“开箱即用”但它的耦合度较高做前后端分离接口时序列化和路由定制反而要多花时间去覆盖默认行为。FastAPI 性能好、文档自动生成但团队里如果有人不熟悉异步写法维护成本是个隐患。当然如果你是单枪匹马开发Django 的 Admin 后台能省掉不少接口开发时间。但既然标题就是 Python我用 Flask 这套组合写出来的代码更接近“从零设计一个系统”的本质面试或答辩时也更好讲清楚每一行代码为什么存在。2.2 前端框架与组件库的选择前端用了Vue 3 Vite Pinia Element Plus。这套组合的好处是Vue 3 的组合式 API 让逻辑复用变得非常干净。Vite 启动速度快开发体验比 Webpack 时代好太多。Element Plus 组件库自带表格、表单、弹窗、日期选择器后台管理页面 80% 的界面都能直接拼出来。这里要提醒一下现在很多教程还在教 Vue 2 Element UI但新项目建议直接上 Vue 3 Element Plus。虽然网上 Vue 2 的资料更多但 Vue 3 已经是绝对主流而且 Vue 2 已经停止维护了没必要给自己埋坑。至于状态管理项目规模不大Pinia 其实并不是必需的但用了之后确实能让“跨页面共享当前用户信息”和“刷新后恢复登录态”这两个事变得非常顺手。2.3 前后端分离的取舍前后端分离意味着前端负责页面渲染和用户交互后端只提供 JSON 接口。好处显而易见前后端可以并行开发、独立部署后续要做移动端 H5 或小程序后端接口可以直接复用。但分离也有代价跨域问题、两套环境的部署、接口文档的维护。跨域用 flask-cors 解决部署用 Nginx 做反向代理接口文档用 Apifox 或 Swagger 生成这些都是有标准答案的不用自己硬扛。实际开发时我建议以“接口文档先行”的方式协作先把所有接口的路径、参数、返回结构定好前端就可以用 Mock 数据跑界面后端专注实现逻辑最后联调时有文档比对能省掉大量扯皮时间。3. 数据库设计与接口规划数据库设计是这类系统的灵魂。表结构不合理后面写业务逻辑时到处都是补丁。3.1 表结构设计我设计了 6 张核心表用户表user、项目表project、项目成员关联表project_member、任务表task、任务操作日志表task_log、通知表notification。关键字段如下用户表 user字段类型说明idint主键usernamevarchar(50)登录名唯一password_hashvarchar(255)密码哈希werkzeug 生成roletinyint1管理员 2项目经理 3成员real_namevarchar(50)真实姓名用于显示created_atdatetime创建时间项目表 project字段类型说明idint主键namevarchar(100)项目名称descriptiontext项目描述statustinyint1进行中 2已归档 3已取消manager_idint项目经理 ID外键 user.idstart_datedate开始日期end_datedate截止日期created_atdatetime创建时间任务表 task 是最核心的表字段类型说明idint主键project_idint所属项目外键 project.idtitlevarchar(200)任务标题descriptiontext任务描述assignee_idint负责人外键 user.idprioritytinyint1低 2中 3高statustinyint0待开始 1进行中 2已完成 3已延期plan_startdate计划开始时间plan_enddate计划结束时间actual_enddatetime实际完成时间progresstinyint0-100手动更新进度百分比created_atdatetime创建时间设计时几个容易忽略的点status 和 progress 要分开。status 是状态机里的节点progress 是连续值两者缺一不可。比如“进行中”的任务可以手动标到 80%但状态还是“进行中”直到负责人确认完成。外键不要建太多级联。比如删除项目时任务我是用“软删除”逻辑处理的给项目表加一个 deleted 字段而不是物理删除避免误删数据补不回来。时间字段区分 date 和 datetime。计划时间是 date精确到天就够实际完成时间是 datetime方便看是谁几点几分验收的。3.2 状态流转设计任务状态我设计成一个有限状态机待开始 - 进行中 - 已完成 | | -- 已延期 --从已完成回退到进行中用于返工转移规则只有任务负责人本人或者项目经理、管理员能更新状态。待开始任务越过计划开始日期且未更新状态系统自动标记为“已延期”。已完成任务若被标记返工则强制回退到“进行中”同时清空实际完成时间。项目归档后所有未完成任务统一置为“已延期”并禁止继续编辑。这套规则在代码里就是一个专门的函数集中处理状态变化而不是散落在各个视图函数里。这样以后要加“审核通过”状态只需要在函数里增加一条转移分支不会动到已有逻辑。3.3 核心 API 一览接口设计遵循 RESTful 风格统一返回结构为{ code: 0, message: success, data: { } }方法路径说明POST/api/auth/login登录返回 JWTGET/api/user/info获取当前用户信息GET/api/project/list项目列表按角色过滤POST/api/project/create创建项目GET/api/project/detail?idxx项目详情含任务树POST/api/task/create创建任务PUT/api/task/update更新任务状态/进度/负责人GET/api/task/detail?idxx任务详情GET/api/statistics/overview项目整体统计每个接口都要做权限校验不能只靠前端隐藏按钮来防越权。后端校验的逻辑很简单拿到当前登录用户,再查对应资源属于哪个项目再判断该用户是不是该项目成员或管理员。4. 后端核心模块实现后端代码的组织方式直接影响后续维护体验工程目录我是这样划分的。4.1 工程目录结构project_backend/ ├── app.py # 应用入口注册蓝图 ├── config.py # 配置文件数据库连接、密钥 ├── models/ │ ├── __init__.py # 初始化 SQLAlchemy │ ├── user.py │ ├── project.py │ └── task.py ├── api/ │ ├── __init__.py │ ├── auth.py # 登录、注册接口 │ ├── project_api.py # 项目相关接口 │ ├── task_api.py # 任务相关接口 │ └── statistics_api.py # 统计接口 ├── utils/ │ ├── jwt_utils.py # JWT 签发与校验 │ ├── decorators.py # 权限校验装饰器 │ └── response.py # 统一返回封装 └── requirements.txt分层原则很简单models 层只定义表结构api 层只处理请求和响应utils 层放公共逻辑。不要在视图函数里写复杂的业务规则那样用不了多久就乱成一锅粥。4.2 登录鉴权与用户管理登录用的是 JWT 方案。用户提交用户名密码后端校验通过后生成 token前端把 token 存在本地存储里每次请求在 Header 中携带Authorization: Bearer token。JWT 的三个关键配置是密钥、过期时间、签发算法。密钥必须放在环境变量里不要硬编码在代码中过期时间我设置的是 12 小时各公司可以按实际调整太短会让成员频繁重新登录太长有安全风险。密码存储用的是 werkzeug 的generate_password_hash这是 Flask 自带的密码哈希工具加盐处理远比明文或 MD5 安全。登录逻辑简化后长这样auth_bp.route(/login, methods[POST]) def login(): data request.get_json() username data.get(username) password data.get(password) user User.query.filter_by(usernameusername).first() if not user or not check_password_hash(user.password_hash, password): return jsonify({code: 1, message: 用户名或密码错误}), 401 token jwt_utils.generate_token(user.id, user.role, user.real_name) return jsonify({code: 0, data: {token: token}})权限校验用装饰器实现比如只有项目经理和管理员能创建项目def require_role(*roles): def decorator(fn): def wrapper(*args, **kwargs): current_user g.current_user if current_user.role not in roles: return jsonify({code: 403, message: 无权限操作}), 403 return fn(*args, **kwargs) return wrapper return decorator用装饰器的好处是权限逻辑和业务逻辑完全解耦每个接口只要加上一行require_role(1, 2)就能完成控制。4.3 任务分配与进度更新任务分配这个环节有几个容易纠结的场景任务能不能转给别人项目经理能不能强制修改成员的任务状态我的处理方案是创建任务的权限项目经理和管理员。修改任务状态的权限任务负责人本人、项目经理、管理员。修改任务负责人的权限仅项目经理和管理员修改后会在任务日志里记录操作者。进度更新是核心操作所以我在后端做了一个专门的“事务脚本”来处理。前端每次提交进度传入新的进度值和目标状态后端统一校验def update_task_status(task, new_status, operator): # 校验状态转移是否合法 allowed { 0: [1], # 待开始 - 进行中 1: [2, 3], # 进行中 - 已完成 / 已延期 2: [1], # 已完成 - 进行中返工 3: [1] # 已延期 - 进行中重新开始 } if new_status not in allowed.get(task.status, []): raise BizException(非法的状态变更) task.status new_status if new_status 2: task.actual_end datetime.now() db.session.commit() task_logger.log(task, operator, new_status)同时每次状态变更都会写入 task_log 表记录“谁在什么时间把任务从什么状态改成了什么状态”。这个日志表在项目复盘时价值巨大能直接回答“这个任务为什么延了三天”这种问题。4.4 统计报表接口统计接口是管理层最看重的功能也是能跟“普通增删改查”拉开差距的地方。我做三个维度的统计项目进度已完成任务数 / 总任务数按百分比展示。任务状态分布待开始、进行中、已完成、已延期的数量。成员负载每个成员名下的未完成任务数量用于发现“某人任务过载”的情况。统计接口用一条聚合查询就能搞定SELECT status, COUNT(*) as cnt FROM task WHERE project_id :pid AND deleted 0 GROUP BY status前端拿到这个数据后用 ECharts 画饼图和柱状图看板效果立刻就有了。后端只负责给原始数据图表展示全部交给前端这就是前后端分离的典型合作模式。5. 前端界面开发与交互细节前端部分的工作量不比后端少甚至更琐碎。Vue 开发要关注的不仅是“写出来”还有“怎么让使用者不迷路”。5.1 工程结构与路由设计前端工程用 Vite 初始化目录结构project_frontend/ ├── src/ │ ├── api/ # 接口封装按模块分文件 │ ├── assets/ │ ├── components/ # 通用组件进度条、任务卡片等 │ ├── router/ # 路由配置 │ ├── stores/ # Pinia 状态管理 │ ├── views/ │ │ ├── Login.vue │ │ ├── Dashboard.vue # 个人工作台 │ │ ├── ProjectList.vue # 项目列表 │ │ ├── ProjectDetail.vue # 项目详情含任务面板 │ │ ├── TaskEdit.vue # 任务创建/编辑弹窗 │ │ └── Statistics.vue # 统计看板 │ ├── App.vue │ └── main.js ├── vite.config.js └── package.json路由设计有几个页面是必须的登录页、工作台、项目列表、项目详情、统计看板。项目详情页是最复杂的里面要有项目基本信息、任务列表、成员列表、进度统计四块内容。页面之间的跳转逻辑是登录后默认进入个人工作台工作台上展示“我负责的任务”和“我参与的项目”点项目卡片进入项目详情统计看板从导航栏进入。5.2 axios 封装与请求拦截axios 封装是前端项目的基座必须一开始就做好。请求和响应各设置一个拦截器// request 拦截统一携带 token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // response 拦截统一处理错误码 service.interceptors.response.use( response { const res response.data if (res.code ! 0) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { // token 过期跳转登录页 localStorage.removeItem(token) router.push(/login) } ElMessage.error(error.response?.data?.message || 网络异常) return Promise.reject(error) } )这些封装能做到“登录过期自动踢回登录页”“接口报错统一弹提示”避免每个页面都写一堆重复的 try-catch。5.3 核心页面开发项目列表页用的 Element Plus 的el-table展示项目名称、负责人、状态、任务数、进度。这里有一个值得注意的交互进度条直接嵌套在表格列中用el-progress组件展示颜色根据进度自动变化低于 50% 显示红色50%-80% 显示黄色80% 以上显示绿色。光这一个细节就比纯数字表格直观得多。任务管理界面我采用的是“任务卡片 编辑抽屉”的交互模式每个任务显示标题、负责人、截止日期和状态标签。点击“编辑”按钮从右侧滑出抽屉面板可以修改状态、进度、负责人。进度更新用滑动条或数字输入框一步操作完成。任务状态用彩色标签区分待开始是灰色进行中是蓝色已完成是绿色已延期是红色。颜色记忆成本低成员扫一眼就知道当前哪些任务是风险项。统计看板页用 ECharts 画两张图项目进度总览用横向柱状图任务状态分布用环形图。每张图上方加了一个时间筛选器支持查看“本周”“本月”“全部”三个维度这样项目经理可以快速了解这段时间的工作节奏。5.4 权限控制与路由守卫前端路由守卫的作用是“挡在门外”避免未登录用户直接通过链接地址访问内部页面。核心逻辑router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path ! /login !token) { next(/login) } else if (to.path /login token) { next(/) } else { next() } })但这里必须强调路由守卫只是提升用户体验的辅助手段不能代替后端权限校验因为前端的任何判断都可以被绕过。真正的数据安全必须依赖后端接口的权限控制。前端隐藏“创建项目”按钮后端也要校验角色缺一不可。6. 环境配置与常见问题排查实录这部分是我最想分享的因为开发过程中 70% 的时间其实都花在环境配置和修 bug 上。6.1 开发环境搭建整套开发环境分为三层Python 后端、Node.js 前端、MySQL 数据库。后端环境的关键点是用虚拟环境隔离依赖python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install flask flask-sqlalchemy flask-cors flask-jwt-extended pymysql前端环境的坑更多。先确认 Node.js 版本Vite 要求 Node 版本 16如果本机版本太旧Vue 3 项目跑不起来。接着安装依赖npm install国内网络环境建议先切换镜像源npm config set registry https://registry.npmmirror.com6.2 高频报错速查表我整理了一下开发过程中碰到的问题整理成速查表现象原因解决方案前端请求后端报 404接口路径写错或代理配置缺失检查 vite.config.js 的 server.proxy后端报 CORS 错误前端跨域请求未处理安装 flask-cors并注册到 app数据库中文乱码数据库默认字符集不是 utf8mb4建库时指定CHARACTER SET utf8mb4端口被占用后端口或 Vite 端口冲突后端改app.run(port5001)前端改 server.portnpm install 卡住网络问题切换镜像源后重新安装登录后刷新就退出前端未持久化 token用 localStorage 保存 token任务状态改完列表不刷新前端请求成功后未重新拉取数据在 then 里重新调用列表接口压轴的一个大坑是Vue 前端请求接口的 baseURL 不能写死成 localhost。如果前端跑在 5173 端口、后端跑在 5000 端口直接写http://localhost:5000/api会触发 CORS 和代理两层问题。最稳的方案是在 vite.config.js 里配置代理server: { port: 5173, proxy: { /api: { target: http://localhost:5000, changeOrigin: true } } }前端请求时直接用/api/xxx作为路径让 Vite 代理转发这样前后端联调时完全不需要关心跨域。6.3 部署前的检查清单系统开发完部署上线前一定要逐项检查下面这些点每条都是我用真实事故换来的后端配置文件去掉调试模式DEBUG False。数据库密码和 JWT 密钥不要写在代码里改用环境变量。前端打包前把 api baseURL 改成线上域名不要再用代理。Nginx 配置反向代理前端静态文件、后端接口分别指向不同端口。最重要的一条上线前用两个不同的浏览器账号同时登录把“改任务状态、改进度、查看统计”完整走一遍模拟真实协作场景不要在单机自测环境跑一遍就当没事了。我当时第一次部署就吃过亏单机测试一切正常一旦两个账号并发操作任务状态出现了覆盖后来把前端“修改任务”的逻辑加上了“更新前比对当前 status”才彻底解决并发下的状态错乱。写在最后的一点体会这套系统从零到跑通全部流程我两个周末完成主体功能中间踩掉的坑比预想多一倍。但做完之后最有价值的收获不是“我写了几个接口”而是真正理解了管理系统的本质是让信息流动有规则——JWT 保证了谁在流动状态机保证了往哪流动日志表记录了怎么流动统计看板让大家看见流动的结果。如果你正在做类似的项目我的建议是不要一上来就写代码先用一天时间把角色、状态、权限这三件事想清楚这会决定你后面是写 2000 行代码还是补 2000 行补丁。后续如果想继续扩展这个项目还有几个顺手的方向任务评论 消息通知站内信、Excel 导出周报、成员工时统计。架构已经留好了位置做起来不用伤筋动骨随时可以接着往上加。