简介这是一份基于Python与Vue.js的社区养老管理系统完整项目采用B/S结构后端使用主流Python语言开发前端使用Vue.js构建适用于养老机构信息化管理场景也适合作为Web全栈开发学习或毕业设计的参考案例。系统功能覆盖老人管理、护工管理、亲属管理、病史管理、房间管理、活动管理、用户管理、日志管理及系统信息等模块业务逻辑完整角色划分清晰。压缩包共177个文件大小6.02MB核心含35个py后端源码、14个vue前端组件、35个ts脚本与38个svg图标另有js、图片、样式及配置文件源码目录结构规范便于按模块阅读与二次开发。资源附带演示地址和测试账号读者可直接在线体验系统功能也可下载源码本地部署。目前已有313人学习浏览对于想快速上手PythonVue.js前后端分离开发或构建同类管理系统的开发者是一份具有参考价值的实操素材。1. 社区养老管理系统为什么我建议直接看这份Python项目再动手如果你接手过社区养老机构的日常管理一定对这样一幕不陌生老人档案散落在纸表和Excel里、护工排班靠微信群里接龙、上门服务记录要月底人工核对。这个基于Python的社区养老管理系统本质上就是把「老人档案、服务工单、健康记录、费用结算」这四件最磨人的事收进一个后台里前端用的是Vue.js后端用Python生态实现。它适合两类人一是社区养老机构的管理者想找一个能直接改着用的业务系统二是Python后端开发想看看一个带权限、带流程状态、带统计报表的管理系统该怎么做。我把它下载下来在本地完整跑通了一遍又从目录结构到核心接口逐层拆过这篇就把「它是什么、怎么跑、怎么改」一次说清。2. 项目架构与技术选型Python后端和Vue.js前端是怎么分工的2.1 为什么是Python Vue.js的组合这类管理系统选型时通常有两种路线一是Django自带模板渲染二是前后端分离。这个项目选择了后者后端用Python提供JSON接口Vue.js负责页面交互。实际拆下来看前端的路由和组件做得比较规矩后端的接口路径设计也干净每个资源都有明确的URL语义比如老人档案、服务记录、护工信息都有独立的模块。对想二次开发的人来说前后端分离的最大好处是你可以只改前端样式不动业务逻辑或者只重写后端接口不动页面。后端框架的形态从代码组织方式看是类Flask的路由风格用蓝图Blueprint按业务域拆分配置文件和路由注册这种组织方式在中小型项目里很常见。数据库方面用MySQL连接配置集中在配置文件里迁移脚本和数据初始化脚本是分开的这样部署时可以按需执行。前端脚手架是Vue CLI的风格组件按视图文件夹组织axios做HTTP请求封装路由模式用的history这些在后续改菜单和页面时会直接碰到。2.2 核心表结构设计一眼看懂业务主链系统的主链可以概括为社区 → 老人 → 档案 → 服务工单 → 健康记录。拆数据库表结构时重点看这四张表elder_info老人基础信息包括姓名、年龄、紧急联系人、所在社区编号、护理等级service_order服务工单字段包括老人编号、服务类型、护工编号、状态、预约时间、实际完成时间health_record健康记录包括血压、心率、体温和备注每次上门服务时由护工填写staff_info护工/员工信息包含角色字段用于区分管理员和护工四个表之间的关联逻辑不复杂老人表是一侧服务工单和健康记录分别以老人编号作为外键关联到elder_info。这种设计的好处是查询某个老人的服务历史时一条SQL就能拿到全量数据而不需要多表Join套多表。护理等级这个字段隐藏在业务中的权重很高——社区养老场景里半自理和全失能老人的服务频率和结算标准完全不同这个字段直接决定后续报表统计的口径。2.3 目录结构拆解改动时要认得路拿到源码后先看根目录整体是前后端分开的两个文件夹。前端里面src/views下每个视图对应一个菜单比如老人管理、工单管理、数据报表src/api下是与后端接口对应的JS模块一个后端资源对应一个JS文件。后端按业务模块分文件夹每个模块里有路由文件和对应的数据处理文件。配置集中在config目录静态文件单独放在static目录。这种结构对于二次开发的意义在于你要加一个新功能模块流程基本是固定的——先在数据库加表然后对照现有代码克隆一份路由和数据处理文件最后在前端克隆一个视图组件并注册路由。整个链路不需要动公共代码风险面很小。我之前改过同类项目最怕的是那种所有接口都堆在一个文件里的写法看起来文件少但每次改动都要全文搜索而这个项目模块边界比较清晰算得上省心。3. 核心模块拆解一个服务工单从创建到完成的数据流转3.1 登录与权限角色怎么影响菜单渲染打开系统第一步是登录。登录接口的处理逻辑是先按用户名查用户表取到密码哈希后验证验证通过后签发token返回前端。前端拿到token写入本地存储后续每个请求都在拦截器里带上。后端的权限控制核心在角色判断管理员和护工拿到的菜单列表不一样这个差异在前端路由守卫里处理——根据用户角色过滤可访问路由表。# 登录接口的核心校验逻辑示意 def login(): data request.get_json() username data.get(username) password data.get(password) user db.find_user_by_name(username) if user is None or not check_password_hash(user[password], password): return jsonify({code: 401, msg: 用户名或密码错误}) token create_token({uid: user[id], role: user[role]}) return jsonify({code: 200, token: token, role: user[role]})这里有个细节值得注意密码校验用的是哈希比对而不是明文相等判断这对生产环境很重要。如果项目的环境依赖里包含哈希函数库通常会自动引入如果没有建议后续改造时手动加一个sha256加盐的方案。菜单权限的实现前端那边由路由守卫控制判断依据是登录时返回的role字段。理清这个逻辑后你就能明白为什么给护工账号分配某些菜单权限后依然看不到入口——因为前端路由表和后端角色字段是联动的缺一不可。3.2 老人档案管理增删改查怎么处理复杂字段老人档案表单里除了常规文本字段还有护理等级下拉框、紧急联系人电话、所在社区选择。后端的处理方式是接收JSON数据后逐字段做校验再写入数据库。编辑时会先按ID查出原始记录把前端传上来的字段覆盖后保存。删除时做的是软标记还是物理删除这个项目里采用的方式是直接物理删除关联的服务记录——如果考虑生产数据安全建议改成逻辑删除字段。// 前端新增老人档案的提交逻辑示意 async function addElder(elderForm) { const { data } await request.post(/api/elder/add, { name: elderForm.name, age: elderForm.age, care_level: elderForm.careLevel, contact: elderForm.contactPhone, community: elderForm.communityId }); if (data.code 200) { message.success(新增成功); fetchElderList(); } else { message.error(data.msg); } }这个模块里容易踩坑的是社区字段。如果社区信息存在独立的社区表那么前端提交的communityId必须经过后端校验存在性否则会留下孤儿数据。我看到的部分代码里后端只做了长度校验没有做存在性校验二开时这个位置值得补强——可以在后端加一个外键查询提交前先去社区表count一下ID是否存在。3.3 服务工单状态机待接单、服务中、已完成怎么流转服务工单是这套系统里业务逻辑最重的模块拆它的状态流转能看清整条业务链路。工单创建之后会有几个状态节点护工接单、开始服务、填写记录、完成归档每个状态转换都对应一个后端接口。# 工单状态更新接口示意 def update_order_status(): data request.get_json() order_id data.get(order_id) new_status data.get(status) # 状态合法性判断待接单 - 服务中 - 已完成 allowed_next {待接单: [服务中], 服务中: [已完成]} current get_order_status(order_id) if new_status not in allowed_next.get(current, []): return jsonify({code: 400, msg: 非法的状态流转}) update_order_status_sql(order_id, new_status) return jsonify({code: 200, msg: 更新成功})状态机的写法并不复杂但它的价值体现在业务防错上。没有状态校验的话一个误操作完全可能把已经完成的订单改回待接单导致统计报表错乱。这个项目用白名单的方式限制流转路径算是在后端做了防线。如果要扩展新状态比如增加「已取消」或「待回访」改allowed_next字典和前端状态标签配置两处就行。我之前改过一个功能更复杂的服务系统当时用的是状态模式类来处理流转项目小的时候不必上那么重的设计字典白名单够用了。理解这段逻辑之后还有一个收获Vue前端列表里的状态标签是通过配置映射的后端是什么字符串前端就展示什么样式所以改新增状态时前后端要保持一致。4. 本地部署与启动全流程从拉取源码到看到登录页4.1 后端环境初始化Python依赖和数据库导入老规矩先建虚拟环境装依赖再导数据库。假设你已经把源码包解压到工作目录依次执行的命令如下。cd backend python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate pip install -r requirements.txt依赖装完后需要初始化数据库。项目包里通常会带SQL文件我拿到的文件里有初始化脚本和示例数据分别是schema.sql和init_data.sql。先建库再导入这两份文件mysql -uroot -p -e CREATE DATABASE elder_care DEFAULT CHARACTER SET utf8mb4 mysql -uroot -p elder_care schema.sql mysql -uroot -p elder_care init_data.sql数据库导入成功后会看到前面提到的四张主表和若干辅助表初始数据里会有一条管理员账号。账号密码在init_data.sql里是明文存储登录后进系统改掉就行。这一步有个容易忽略的细节如果用的是MySQL 8以上版本后端配置文件里的驱动字符串要确认对得上。4.2 后端启动配置改哪几个地方能跑通配置问题一直是本地跑项目最容易翻车的位置。启动后端前需要检查配置文件里的数据库连接信息——用户名、密码、端口、字符集四处必须改成本地值。如果你的MySQL密码是123456就填123456字符集保持utf8mb4不动端口默认3306不需要改改了容易踩通讯协议问题的坑。python app.py看到启动日志里打印监听地址就可以验证接口了浏览器访问一下本机IP加端口后端会返回接口文档或告警页视项目具体实现而定。后面调试接口阶段我的习惯是先起后端再起前端这样前端请求有响应时能直接在浏览器Network面板里区分是网络错误还是业务错误少一层排查成本。4.3 前端启动Vue.js项目依赖安装和代理配置后端就绪后进入前端目录cd ../frontend npm install npm run serve这里最有可能卡住的是跨域问题。本地开发时前端运行在8080端口后端跑在5000或9000端口Vue CLI的代理配置在vue.config.js里。检查方式很简单——打开页面打开浏览器开发者工具看Networks面板如果某个请求报出跨域相关错误提示第一反应应该不是改后端加CORS而是看代理配置是否把/api前缀正确转发到了后端地址。# vue.config.js 中常用的代理写法示例 devServer: { proxy: { /api: { target: http://localhost:5000, changeOrigin: true } } }注意changeOrigin: true这行少了它有的场景下请求头里的Host不对后端某些框架会拒绝服务。跑通前端后浏览器会自动打开登录页用init_data.sql里预置的账号登录看到菜单渲染出来就说明前后端正常联通了。5. 部署避坑记录三个让新手最头疼的经典翻车现场5.1 数据库中文乱码字符集不统一玄学现象导入init_data.sql之后登录系统看到菜单和老人姓名是问号。排查结果指向建库时的字符集没有显式指定默认落到了latin1后端连接配置却写的utf8mb4两边一个混合就全乱。解决重建数据库并显式指定字符集再重新导入mysql -uroot -p -e DROP DATABASE elder_care mysql -uroot -p -e CREATE DATABASE elder_care DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci mysql -uroot -p elder_care schema.sql mysql -uroot -p elder_care init_data.sql从那以后我每次新建项目数据库都强制走一遍带字符集的建库语句不乱删库就先查默认字符集。5.2 前端启动后登录接口404后端路由前缀对不上现象后端进程正常启动前端页面也正常加载输入账号点登录Network面板显示请求地址是http://localhost:8080/api/login返回404。原因Vue代理把/api前缀转发了但后端路由注册时没有统一挂载/api前缀后端实际路由是/login代理转发过去之后路径不匹配。解决找到后端的路由注册代码把所有接口统一加上/api前缀或者改vue.config.js代理配置把路径转换规则写成重写形式的语法proxy: { /api: { target: http://localhost:5000, changeOrigin: true, pathRewrite: {^/api: } } }这个位置是新手动辄迷糊的地方。优先推荐改后端的统一前缀项目规范更重要鲜少建议为了省事把代理改裸转否则以后联调真实后端时还要再改回来。5.3 工单状态就是不更新前端缓存了旧列表现象创建工单后列表页看到数据出现了点状态变更后界面还是老状态刷新页面才正常。原因前端状态更新后方法里没有主动刷新列表。在部分Vue实现里数据更新后视图不触发更新看起来像后端接口失败其实接口正常返回了。解决在后端更新成功回调里重新请求列表数据代替只改本地数组的做法。常见写法是在修改成功的分支里调用获取列表的异步函数。代码校验问题这个位置去掉status本地数组赋值必须每次从后端重新拉避免前台数据和数据库不一致。遇到这类情况先查Network确认返回再纠结视图逻辑能少走很多弯路。6. 二次开发实战给系统加一个「服务评价」模块的思路参考落到二次开发这一层我建议从最有说服力的场景切入——服务完成后家属的评价反馈。当前系统里工单完成即结束没有收集评价的通道。加这个模块需要前后端联动走一遍正好能验证你对这套代码结构的熟悉程度。后端要做的事新增一张评价表字段可以设计为工单编号、评分、评价内容、评价时间。接口这边新增提交评价的接收逻辑注意在接口里校验工单当前状态是否为已完成因为只有完成的工单才允许被评价。数据库迁移的话最稳的方法是与原项目保持一致先建立表结构再重启后端。前端新增组件视图和服务支持模块接入路由之后在工单列表增加操作入口。业务规则可以这样做状态为已完成且未评价的工单操作列里显示评价按钮已评价过的显示已评价文字且不能重复提交。这个入口判断涉及工单列表数据是否关联了评价表接口要在返工时单列表数据时额外返回一个是否评价的标记字段。做法上最直接的方案是在工单查询结果里做一次子查询或关联查询判断评价表里是否存在对应的记录。改完后验证链路新建工单 → 接单 → 完成 → 出现评价按钮 → 提交评价 → 列表变为已评价 → 数据库里能查到记录。这七个步骤走通模块就算完整落地了。这套项目的可扩展性在这个改造流程里已经体现得很明显。因为前后端分离业务闭环的每一步都有对应的落点——加表、加接口、加组件。如果你是想拿它做课程设计或毕设这个评价模块加完之后还可以继续延伸出「服务统计报表根据评价分数做排名」的页面前后端工作量都可控。我自己的习惯是每拿到一个新项目源码先完整跑通一遍再造一个最小的功能进去这个最小功能往往是一种状态倒推——比如把完成状态加一个后续节点。这样一遍下来目录结构、路由注册、接口链路和数据库关联基本全摸清了。希望这套拆解思路也能帮你在社区养老这个场景里快速从阅读者变成开发者。本文还有配套的精品资源点击获取
