博主介绍✌ 专注于VUE,小程序安卓Java,python,物联网专业 从事毕业指导项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题我会尽力帮助你。一、研究目的随着城市化进程加速社区居民对高质量、低成本生鲜产品的需求日益增长然而传统的生鲜配送模式在供应链管理、库存控制与物流调度方面存在显著瓶颈。当前多采用线下直供或大型电商平台分拣发货的方式导致配送时效长、损耗率高、信息闭塞等问题。与此同时社区居民对个性化服务与即时响应的期望不断提升迫切需要一种能够实现订单即时生成、库存实时更新与配送路径最优化的系统。基于此背景本研究聚焦于构建一套面向社区生鲜配送的全流程信息化解决方案以期在技术层面突破传统模式的局限。本研究旨在通过SpringBoot框架搭建高可扩展、易维护的后端服务并结合微信小程序实现前端交互与业务展示从而形成闭环式的社区生鲜配送平台。具体目标包括一是实现订单管理模块支持用户下单、支付、取消与查询等功能二是构建库存管理子系统实现进货登记、库存盘点与预警机制三是设计物流调度算法利用实时位置数据优化配送路径并降低配送成本四是提供数据分析与报表功能为社区商家与运营方提供决策支持。通过上述模块的集成本研究期望提升社区生鲜供应链的透明度与响应速度降低产品损耗率并为居民提供更便捷、可靠的购物体验。此外研究还将关注系统的可持续性与安全性。后端服务将采用微服务架构支持水平扩展与灰度发布数据传输将使用HTTPS协议并配合OAuth2.0认证机制保障用户隐私与交易安全系统日志与监控将通过ELK栈实现实时告警与性能分析。通过对上述技术细节的深入探讨本研究不仅为社区生鲜配送提供技术支撑也为类似场景的智慧物流系统设计提供可借鉴的参考框架。二、研究意义本研究所提出的基于SpringBoot与微信小程序的社区生鲜配送系统具有重要的理论与实践意义。首先从理论层面来看该系统将分布式微服务架构与移动端即时交互技术有机结合形成了一个完整的端到端供应链信息化模型此模型可为后续研究提供可复制、可扩展的技术框架推动智慧物流与社区服务融合的学术探讨。其次在实践层面该系统通过实现订单管理、库存监控与物流调度等核心功能能够显著提升社区生鲜配送的时效性与准确性具体而言订单实时生成与支付流程的自动化可减少人工操作错误库存预警机制则有助于降低过期损耗而基于位置数据的路径优化算法则能在保持配送质量的前提下降低运输成本。再次本研究所采用的微信小程序平台凭借其广泛渗透的用户基础与成熟的支付生态为社区居民提供了便捷、低门槛的购物入口这不仅提升了居民对生鲜服务的满意度也为社区电商模式创新提供了可行路径。再者系统所采用的SpringBoot框架与微服务架构具备良好的横向扩展性与高可维护性在面对不同社区规模、不同业务需求时可通过模块化部署实现快速迭代从而满足多样化的运营场景。最后该系统在数据安全与隐私保护方面结合HTTPS传输、OAuth2.0认证以及日志监控机制确保了用户信息与交易数据的安全性这为社区服务平台在合规性与信任度方面奠定了坚实基础。综上所述本研究不仅为解决传统生鲜配送模式中存在的效率低下、成本高昂等痛点提供了技术方案也为智慧社区建设与城市物流现代化提供了可借鉴的实践经验具有显著的社会经济价值与推广前景。三、国内外研究现状在全球范围内基于互联网技术的生鲜配送研究已从传统仓储物流向数字化、智能化转型。研究者主要聚焦于供应链协同、物联网传感与数据集成、人工智能预测与决策支持以及最后一公里配送路径优化等方向。通过大数据分析与机器学习模型国外学者已在需求预测、库存补货策略和动态定价机制方面取得显著进展同时基于云计算平台的微服务架构为多租户物流系统提供了弹性扩展能力。国内研究同样呈现多元化发展趋势。近年来社区电商与社交媒体平台的深度融合推动了基于小程序的生鲜交易模式学术界在微物流网络设计、智能配送车辆调度以及实时库存监控系统方面开展了大量实验研究。特别是在城市社区场景下结合地理信息系统与路径规划算法的研究已实现配送时效显著提升。与此同时国内外学者对冷链温控技术、可追溯性管理与食品安全监管的数字化手段也展开深入探讨。总体而言国内外研究已在算法优化、系统架构与业务模式创新方面形成了丰富成果但仍存在跨平台数据共享难题、算法解释性不足以及绿色低碳配送路径设计等亟待解决的挑战。 在技术实现层面物联网传感器的普及使得温度、湿度与位置信息能够实时采集并上传至云端支持对生鲜产品全程可视化监控区块链技术被引入以保证交易数据不可篡改从而增强消费者对食品来源与质量的信任。与此同时边缘计算的应用降低了数据传输延迟为实时配送决策提供了技术保障。国内外研究亦关注绿色物流与碳排放评估提出基于多目标优化的配送路线规划模型以兼顾成本、时效与环境影响。通过对比分析可知国外在大规模物流网络的协同调度与无人机配送试点方面已取得初步成果国内则更侧重于社区级别的细分市场与社交化运营模式。尽管如此系统间的数据互操作性、算法透明度以及消费者隐私保护仍是亟需攻克的难题。四、预期达到目标及解决的关键问题本研究的预期目标聚焦于构建一套面向社区生鲜配送的全流程信息化平台旨在实现订单管理、库存监控与物流调度的闭环式协同并通过技术创新提升配送时效、降低损耗率以及增强用户体验。首先系统将采用SpringBoot微服务架构与微信小程序前端相结合实现高并发请求的快速响应和模块化维护其次库存管理子系统将通过实时数据采集与预测模型实现自动补货与预警减少因库存不足或过剩导致的资源浪费再次物流调度模块将引入基于位置服务与车辆状态的动态路径规划算法在保证配送时效的前提下最小化运输成本最后系统将集成数据分析与报表功能为社区商家与运营方提供决策支持并通过安全认证与加密传输保障用户信息与交易数据的安全。通过上述目标的实现本研究期望在提升社区生鲜配送效率、降低运营成本以及增强消费者满意度方面取得显著成效。然而在实现上述目标的过程中仍面临若干关键问题。首先系统内部各模块之间的数据同步与一致性难以保证尤其是在高并发订单场景下库存状态更新可能出现延迟或冲突其次物流调度算法需要在实时位置、车辆承载能力、配送时间窗口以及道路拥堵等多维约束下求解最优路径其计算复杂度与实时性之间存在矛盾再次系统的安全与隐私保护是不可忽视的挑战需在保证数据可用性的同时防止信息泄露与篡改此外随着社区规模扩大或业务拓展至多租户模式系统的可扩展性与模块化维护性将受到考验最后用户体验方面的多样化需求如个性化配送时间、冷链监控反馈以及售后服务接口也要求系统在功能设计与交互体验上保持高度灵活。针对上述关键问题本研究将通过技术创新与方法论探索力求提出可行且具有推广价值的解决方案。五、研究内容本研究围绕社区生鲜配送系统的整体架构展开首先构建基于SpringBoot的后端服务框架采用微服务化设计将订单处理、库存管理、物流调度与用户交互等核心功能拆分为独立模块每个微服务通过RESTful API与消息队列实现异步通信从而提升系统的可伸缩性与容错能力。随后在前端层面引入微信小程序技术利用其原生组件与微信支付SDK实现订单下单、支付确认以及配送状态实时查询等交互功能同时通过小程序内置的地理位置服务获取用户地址信息为后端调度模块提供精准定位数据。系统的数据层采用分布式数据库与缓存技术利用Redis实现热点数据的快速读取并通过主从复制机制保障数据一致性在库存管理子系统中结合物联网温湿度传感器实时采集生鲜产品的状态信息通过时间序列数据库存储并供预测模型使用。物流调度模块则采用基于Dijkstra或A*算法的路径规划框架并将车辆GPS轨迹、道路拥堵指数以及配送时间窗口等多维约束纳入优化目标利用遗传算法或粒子群优化实现动态调度决策。为保证系统安全后端服务通过OAuth2.0授权与JWT令牌机制进行身份验证并在数据传输层使用TLS加密所有关键操作均记录日志并通过ELK栈进行集中监控与告警。系统完成后将在真实社区环境中部署试点采集订单量、配送时效、库存周转率等关键指标利用AB测试与多变量回归分析评估系统改进对运营成本与用户满意度的影响并通过可视化报表向社区商家与运营方提供决策支持。六、需求分析用户需求方面社区生鲜配送系统的目标用户主要包括社区居民、社区商家以及配送运营方。对于居民而言核心需求是能够在短时间内完成生鲜商品的浏览、下单与支付并获得实时订单状态反馈同时他们期望系统能够提供多样化的商品分类、精准的价格信息以及灵活的配送时段选择以满足不同生活节奏与饮食习惯此外居民对生鲜产品的新鲜度与安全性有严格要求因而需要系统能够展示商品来源、采摘时间以及冷链温控监测数据从而增强购买信任。对于社区商家而言需求侧重于订单管理与库存监控的高效性他们希望系统能够自动生成销售报表、库存预警以及补货建议以降低人工成本与存货积压风险同时商家需要通过系统获取配送费用与收益分配信息以便进行财务核算与业务优化。配送运营方则关注于车辆调度与路径规划的优化他们需要系统提供实时车辆位置跟踪、运力调度预测以及异常事件报警功能以提升配送时效与降低运营成本此外运营方还需要系统支持多租户管理与权限控制确保不同社区之间的数据隔离与安全性。综合上述用户需求可归纳为一是便捷的前端交互体验二是高效的订单与库存处理流程三是透明的商品质量与冷链监控信息四是精准的配送调度与实时跟踪功能五是完善的数据安全与权限管理机制。功能需求方面系统需实现多层次模块化设计以满足上述用户需求。首先订单管理模块应支持商品浏览、购物车操作、订单生成、支付对接以及订单状态查询该模块还需实现优惠券、积分抵扣等营销功能并与库存管理模块进行同步校验。其次库存管理子系统需具备商品入库登记、库存盘点、实时库存查询与预警机制通过与物联网传感器的对接实现温湿度监测数据的采集与存储并将异常状态及时推送给商家与运营方。第三物流调度模块需实现车辆资源管理、配送时段规划、路径优化算法以及实时车辆跟踪该模块应支持多目标优化时效、成本、能耗并能够在高并发订单场景下保持实时响应。第四用户与商家交互界面需采用微信小程序技术提供商品详情展示、购物车管理、支付接口、订单追踪以及客服沟通功能同时为商家与运营方提供后台管理控制台支持权限分配、数据报表与系统监控。第五安全与权限管理模块需实现OAuth2.0授权流程、JWT令牌验证以及数据加密传输并通过日志审计与异常告警保障系统安全。最后系统整体需具备可扩展性与高可用性采用微服务架构、容器化部署与自动化运维工具以支持业务增长与功能迭代。通过上述功能需求的实现系统能够全面满足社区生鲜配送的业务流程与用户体验要求。七、可行性分析经济可行性方面本研究所提出的社区生鲜配送系统在初期投入与长期收益之间具有良好的平衡。首先采用SpringBoot框架与微信小程序技术能够显著降低软件开发成本与维护费用因为这两种技术均拥有成熟的生态体系与丰富的开源组件其次系统通过微服务化架构实现模块化部署可在云端按需扩容从而避免了过度投资导致的资源浪费再次系统的核心业务包括订单处理、库存管理与物流调度这些功能可通过自动化流程减少人工成本并提升运营效率再者平台可通过多渠道收入模式实现盈利包括商品销售佣金、配送费用分成以及增值服务订阅最后市场调研显示社区居民对生鲜配送的需求持续增长且对价格敏感度与时效性要求较高这为系统提供了稳定的客源基础。综合上述因素项目在经济层面具备可观的投资回报预期并且能够在短期内实现成本回收。社会可行性方面本研究所构建的系统能够满足社区居民对健康、安全与便利性的多重诉求。首先系统通过实时温湿度监测与冷链追踪技术保障生鲜产品在运输过程中的质量与安全从而提升居民对食品安全的信任其次配送时效的提升将有效缓解社区居民因工作繁忙而无法及时采购生鲜的问题改善生活质量再次系统提供的数据可视化报表与库存预警功能有助于社区商家降低过期损耗、减少浪费促进资源的高效利用再者在就业层面系统的运营需要配送人员、仓储管理人员与技术支持人员为社区创造新的就业机会最后系统在推广过程中可结合社区治理与公益活动例如开展食品安全宣传、健康饮食指导等从而提升社会认同感与参与度。综上所述该系统在社会层面具备广泛的接受度与正向影响符合公共利益与可持续发展的要求。技术可行性方面系统所采用的技术栈与架构均已在业界得到验证并具备实现目标功能的能力。SpringBoot框架提供了快速开发、易于集成以及高性能的后端服务基础微服务化设计通过Docker容器化与Kubernetes编排实现弹性伸缩与高可用微信小程序技术凭借其原生渲染与支付SDK能够为终端用户提供流畅的交互体验并且无需额外安装应用即可使用物联网传感器与MQTT协议的结合可实现对温湿度、位置等关键指标的实时采集与推送在数据层面采用分布式数据库与Redis缓存可满足高并发读写需求安全层面系统通过OAuth2.0授权、JWT令牌以及TLS加密传输保障身份验证与数据安全此外系统设计时已考虑到日志审计、异常监控与灰度发布等运维需求确保在生产环境中能够持续稳定运行。鉴于上述技术要素均已成熟且易于集成本研究在技术层面具备实现目标功能的充分可行性。八、功能分析系统功能模块可按业务流程与技术实现层面划分为若干互联的子系统整体架构呈现前后端分离、微服务化与数据驱动的特征。首先前端交互模块采用微信小程序技术为社区居民提供商品浏览、购物车管理、订单下单、支付确认以及配送状态跟踪等功能该模块通过调用后端RESTful接口完成数据交互并利用小程序原生组件实现地图定位与实时物流信息展示。其次订单管理子系统负责接收并处理用户下单请求校验库存可用性、计算运费与优惠、生成订单记录并触发支付流程在支付完成后该子系统将订单状态更新为已付款并将配送指令推送至物流调度模块。第三库存管理子系统以分布式数据库为核心支持商品入库登记、库存盘点、实时库存查询与预警功能通过物联网传感器采集温湿度等环境数据并将异常状态同步给商家与运营方实现冷链质量可视化。第四物流调度子系统整合车辆资源管理、配送时段规划与路径优化算法该模块根据订单需求、车辆承载能力、道路拥堵信息以及配送时间窗口进行动态调度生成最优路线并实时推送给司机端同时支持异常事件监控与自动重调度。第五数据分析与报表子系统聚合订单、库存与物流数据利用统计与机器学习模型提供销售预测、库存周转率、配送时效等关键指标的可视化报表该模块为社区商家与运营方提供决策支持并支持自定义报表导出。第六安全与权限管理子系统实现OAuth2.0授权、JWT令牌验证以及数据加密传输通过细粒度角色与权限配置保障不同用户角色居民、商家、运营员在系统中的访问范围同时记录操作日志并提供审计查询。第七通知与客服子系统负责向用户推送订单状态更新、配送提醒与促销信息并提供在线客服与问题反馈通道该模块通过微信消息接口与后台服务协同工作确保信息及时、准确。最后后台管理控制台为商家与运营方提供统一的业务管理入口支持商品上架、价格调整、订单查询、物流监控与系统配置等功能通过微服务化部署实现高可用与弹性扩容。综上所述系统通过上述功能模块的协同运作实现从前端用户体验到后端业务处理再到数据分析与安全保障的完整闭环满足社区生鲜配送的业务需求与技术可行性。九、数据库设计字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注---|---|---|---|---|---user_id | 用户编号唯一标识用户。 | 36 | CHAR(36) | 主键 | 用于关联订单与通知等表。username | 用户登录名。 | 50 | VARCHAR(50) | |password_hash | 密码哈希值。 | 64 | CHAR(64) | |phone_number | 手机号码。 | 20 | VARCHAR(20) | |email_address | 邮箱地址。 | 100 | VARCHAR(100) | |product_id | 商品编号唯一标识商品。 | 36 | CHAR(36) | 主键 | 用于订单项与库存关联。product_name | 商品名称。 | 200 | VARCHAR(200) | |description_text | 商品描述信息。 | 5000 | TEXT | |category_id | 所属分类编号外键指向 categories 表。 | 36 | CHAR(36) | 外键categories.category_id|price_per_unit | 单价。 | 10,2 | DECIMAL(10,2) | |category_id | 分类编号唯一标识分类。 | 36 | CHAR(36) | 主键 | 用于关联商品表。category_name | 分类名称。 | 100 | VARCHAR(100) | |order_id | 订单编号唯一标识订单。 | 36 | CHAR(36) | 主键 | 用于关联订单项、派送等表。user_id | 下单用户编号外键指向 users 表。 | 36 | CHAR(36) | 外键users.user_id|order_timestamp | 订单创建时间。 | 19 | DATETIME | |order_status | 当前状态待付款、已付款、配送中、已完成、已取消。 | 20 | VARCHAR(20) | |total_amount | 总金额。 | 10,2 | DECIMAL(10,2) | |order_item_id | 订单项编号唯一标识订单项。 | 36 | CHAR(36) | 主键 | 用于关联订单表。order_id | 所属订单编号外键指向 orders 表。 | 36 | CHAR(36) | 外键orders.order_id|product_id | 商品编号外键指向 products 表。 | 36 | CHAR(36) | 外键products.product_id|quantity_ordered | 订购数量。 | 10 | INT | |unit_price_at_purchase | 购买时单价。 | 10,2 | DECIMAL(10,2) | |inventory_id | 库存记录编号唯一标识库存条目。 | 36 | CHAR(36) | 主键 | 用于关联商品表。product_id | 商品编号外键指向 products 表。 | 36 | CHAR(36) | 外键products.product_id|warehouse_location | 仓库位置描述。 | 100 | VARCHAR(100) | |quantity_available | 可用库存数量。 | 10 | INT | |vehicle_id | 配送车辆编号唯一标识车辆。 | 36 | CHAR(36) | 主键 | 用于派送表关联。vehicle_number_plate | 车牌号码。 | 20 | VARCHAR(20) | |capacity_units | 承载容量单位件。 | 10 | INT | |driver_name | 驾驶员姓名。 | 100 | VARCHAR(100) | |dispatch_id | 派送记录编号唯一标识派送。 | 36 | CHAR(36) | 主键 | 用于关联订单与车辆。order_id | 被派送订单编号外键指向 orders 表。 | 36 | CHAR(36) | 外键orders.order_id|vehicle_id | 负责配送的车辆编号外键指向 delivery_vehicles 表。 | 36 | CHAR(36) | 外键delivery_vehicles.vehicle_id|dispatch_timestamp | 派送时间。 | 19 | DATETIME | |dispatch_status | 派送状态已派送、配送中、已完成、异常。 | 20 | VARCHAR(20) | |notification_id | 通知编号唯一标识通知。 | 36 | CHAR(36) | 主键 | 用于用户消息推送。user_id | 接收用户编号外键指向 users 表。 | 36 | CHAR(36) | 外键users.user_id|message_content | 消息内容。 | 2000 | TEXT | |sent_timestamp | 发送时间。 | 19 | DATETIME | |is_read_flag | 是否已读标识0 未读、1 已读。 | 1 | TINYINT(1) | |以上表结构遵循第一范式至第三范式避免冗余并通过主外键实现完整性约束。每个表均以 CHAR(36) 类型的 UUID 作为主键确保全局唯一性字段大小与类型根据实际业务需求设定兼顾存储效率与可扩展性。十、建表语句CREATE DATABASE IF NOT EXISTS community_fresh_delivery CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;USE community_fresh_delivery;-- 用户表CREATE TABLE users (user_id CHAR(36) NOT NULL,username VARCHAR(50) NOT NULL,password_hash CHAR(64) NOT NULL,phone_number VARCHAR(20),email_address VARCHAR(100),PRIMARY KEY (user_id),UNIQUE KEY idx_username (username)) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 商品分类表CREATE TABLE categories (category_id CHAR(36) NOT NULL,category_name VARCHAR(100) NOT NULL,PRIMARY KEY (category_id)) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 商品表CREATE TABLE products (product_id CHAR(36) NOT NULL,product_name VARCHAR(200) NOT NULL,description_text TEXT,category_id CHAR(36),price_per_unit DECIMAL(10,2) NOT NULL,PRIMARY KEY (product_id),KEY idx_category (category_id),CONSTRAINT fk_products_category FOREIGN KEY (category_id)REFERENCES categories(category_id)ON UPDATE CASCADE ON DELETE SET NULL) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 订单表CREATE TABLE orders (order_id CHAR(36) NOT NULL,user_id CHAR(36) NOT NULL,order_timestamp DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,order_status VARCHAR(20) NOT NULL,total_amount DECIMAL(10,2) NOT NULL,PRIMARY KEY (order_id),KEY idx_user (user_id),CONSTRAINT fk_orders_user FOREIGN KEY (user_id)REFERENCES users(user_id)ON UPDATE CASCADE ON DELETE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 订单项表CREATE TABLE order_items (order_item_id CHAR(36) NOT NULL,order_id CHAR(36) NOT NULL,product_id CHAR(36) NOT NULL,quantity_ordered INT NOT NULL,unit_price_at_purchase DECIMAL(10,2) NOT NULL,PRIMARY KEY (order_item_id),KEY idx_order (order_id),KEY idx_product (product_id),CONSTRAINT fk_order_items_order FOREIGN KEY (order_id)REFERENCES orders(order_id)ON UPDATE CASCADE ON DELETE CASCADE,CONSTRAINT fk_order_items_product FOREIGN KEY (product_id)REFERENCES products(product_id)ON UPDATE CASCADE ON DELETE RESTRICT) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 库存表CREATE TABLE inventory (inventory_id CHAR(36) NOT NULL,product_id CHAR(36) NOT NULL,warehouse_location VARCHAR(100),quantity_available INT NOT NULL,PRIMARY KEY (inventory_id),KEY idx_product (product_id),CONSTRAINT fk_inventory_product FOREIGN KEY (product_id)REFERENCES products(product_id)ON UPDATE CASCADE ON DELETE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 配送车辆表CREATE TABLE delivery_vehicles (vehicle_id CHAR(36) NOT NULL,vehicle_number_plate VARCHAR(20) NOT NULL,capacity_units INT NOT NULL,driver_name VARCHAR(100),PRIMARY KEY (vehicle_id),UNIQUE KEY idx_plate (vehicle_number_plate)) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 派送表CREATE TABLE dispatches (dispatch_id CHAR(36) NOT NULL,order_id CHAR(36) NOT NULL,vehicle_id CHAR(36),dispatch_timestamp DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,dispatch_status VARCHAR(20) NOT NULL,PRIMARY KEY (dispatch_id),KEY idx_order (order_id),KEY idx_vehicle (vehicle_id),CONSTRAINT fk_dispatches_order FOREIGN KEY (order_id)REFERENCES orders(order_id)ON UPDATE CASCADE ON DELETE CASCADE,CONSTRAINT fk_dispatches_vehicle FOREIGN KEY (vehicle_id)REFERENCES delivery_vehicles(vehicle_id)ON UPDATE CASCADE ON DELETE SET NULL) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;-- 通知表CREATE TABLE notifications (notification_id CHAR(36) NOT NULL,user_id CHAR(36) NOT NULL,message_content TEXT NOT NULL,sent_timestamp DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,is_read_flag TINYINT(1) NOT NULL DEFAULT 0,PRIMARY KEY (notification_id),KEY idx_user (user_id),CONSTRAINT fk_notifications_user FOREIGN KEY (user_id)REFERENCES users(user_id)ON UPDATE CASCADE ON DELETE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方获取联系方式