随着宠物经济的持续发展宠物寄养服务已经不再只是简单的“线下托管”而逐渐演变为一个需要线上咨询、服务展示、订单管理、实时沟通、动态反馈、评价投诉和平台监管共同支撑的完整业务闭环。在传统宠物寄养场景中宠主往往面临以下问题不清楚附近有哪些可靠寄养机构无法快速了解机构服务内容、价格和口碑寄养过程中缺少及时反馈沟通记录分散服务纠纷难以追溯平台方缺少统一的审核、监管和风险识别能力。因此本项目围绕“宠物寄养”这一真实业务场景设计并实现了一套基于微信小程序和 Web 管理端的宠物寄养服务系统。系统采用“三端 后端统一服务”的整体架构分别面向宠主、寄养机构和平台管理员提供不同的业务能力并通过 Django 后端统一提供接口、鉴权、数据存储、实时通信和 AI 能力。本文将从项目定位、系统架构、核心业务流程、关键模块设计、实时通信方案、AI 能力接入、降级策略以及稳定性设计等多个角度对该宠物寄养服务系统进行完整分析和总结。一、项目定位本项目是一个服务于宠物寄养场景的综合业务系统目标是打通宠主、寄养机构和平台管理员之间的完整业务链路。系统并不是简单的小程序页面集合而是一个具有明确业务分工和数据协同关系的三端系统微信小程序宠主端微信小程序机构端Web 管理端Django 后端统一服务。其中宠主端主要负责寄养咨询、机构浏览、下单、聊天、评价与投诉机构端主要负责入驻申请、资料维护、套餐管理、订单处理和宠物动态反馈管理端则负责机构审核、用户管理、订单监管、投诉处理、AI 风险监控和平台数据统计。从业务本质上看该系统希望解决的是宠物寄养服务中的信息不透明、沟通不及时、服务难追踪、平台难监管等问题。二、系统总体架构系统整体采用“三端 后端统一服务”的架构模式。整体架构如下微信小程序宠主端│微信小程序机构端│├── HTTP API ── Django DRF ── MySQL│└── WebSocket ─ Django Channels ─ RedisWeb 管理端│└── HTTP API ── Django DRFAI 能力└── Django ai_center ── Ollama从架构设计上看系统的核心思想是三端共享同一套后端服务业务数据统一落库前端只负责交互和展示后端负责业务规则、权限控制、数据一致性和能力聚合。这种设计可以避免三端各自维护独立数据逻辑降低系统维护成本同时保证宠主端、机构端和管理端看到的数据口径一致。三、技术选型说明本项目主要涉及以下技术栈1. 小程序端微信小程序端承担宠主端和机构端两个角色的业务交互主要负责页面展示用户登录机构浏览订单创建聊天通信宠物档案维护评价投诉提交机构资料与套餐维护。小程序端通过统一封装的请求层访问后端 HTTP API并通过 WebSocket 实现聊天消息和订单动态的实时推送。2. 管理端管理端是平台运营人员使用的后台系统主要用于管理员登录机构入驻审核用户管理订单监管评价监管投诉处理AI 风险监控平台统计数据查看。管理端通过前端路由守卫限制普通用户访问只允许管理员角色进入后台页面。3. 后端后端采用 Django Django REST Framework 作为统一服务层负责用户认证角色权限控制业务接口提供数据持久化聊天消息落库WebSocket 通信AI 能力聚合管理端统计数据输出。4. 数据库核心业务数据统一存储在 MySQL 中包括用户、宠物、机构、套餐、订单、聊天消息、评价、投诉、预警等数据。5. 实时通信实时通信采用 Django Channels Redis 实现。WebSocket 主要用于聊天消息推送和订单宠物状态推送。6. AI 能力AI 能力由后端ai_center模块统一聚合并通过 Ollama 提供本地模型能力主要用于机构口碑摘要、聊天建议和评价风险分析。四、三端业务划分1. 宠主端宠主端是面向普通宠物主人的小程序端核心目标是帮助宠主完成寄养服务的选择、下单、沟通和服务反馈。宠主端主要功能包括登录与注册浏览寄养机构查看机构详情查看机构服务套餐AI 推荐机构创建寄养订单查看订单状态维护宠物档案与机构实时聊天查看寄养过程中的宠物动态提交评价发起投诉。宠主端的业务路径更偏向“服务消费侧”用户体验要求较高因此页面流程需要尽可能清晰避免用户在寄养下单、聊天沟通和状态查看过程中产生理解成本。2. 机构端机构端是面向宠物寄养机构的小程序端主要解决机构入驻、服务维护、订单处理和寄养反馈问题。机构端主要功能包括机构账号注册提交入驻申请查看审核状态维护机构资料维护服务套餐查看订单列表接单、拒单、改价等订单处理发布宠物动态与宠主聊天查看评价与投诉。机构端的设计重点在于“服务供给侧”。机构需要通过系统完成从入驻审核到服务交付的完整流程因此机构端必须保证订单、套餐、宠物动态和聊天功能稳定可用。3. 管理端管理端是平台运营人员使用的后台系统主要负责平台监管和数据治理。管理端主要功能包括管理员登录平台仪表盘机构审核机构管理用户管理订单监管评价监管投诉处理AI 风险监控预警记录查看平台统计数据查看。管理端承担的是平台治理角色。对于宠物寄养类服务系统来说平台方不仅需要提供交易撮合能力还需要具备审核、监管、纠纷处理和风险识别能力。五、核心业务流程设计1. 宠主业务流程宠主端的主流程可以概括为角色选择↓宠主登录或注册↓首页浏览机构↓查看机构详情↓选择套餐并创建订单↓查看订单详情↓进入聊天页与机构沟通↓寄养过程中查看宠物动态↓服务完成后提交评价或投诉这个流程覆盖了宠主从进入系统到完成寄养服务的完整闭环。其中比较关键的节点包括机构浏览与详情查看套餐选择与订单创建聊天沟通宠物动态反馈服务结束后的评价和投诉。对于宠物寄养业务来说宠主最关心的并不仅仅是价格还包括机构是否可靠、服务是否透明、宠物寄养期间能否得到及时反馈。因此聊天和宠物动态模块在整个宠主流程中具有非常重要的作用。2. 机构业务流程机构端的主流程可以概括为注册机构账号↓提交机构申请资料↓等待管理员审核↓审核通过后维护机构资料和套餐↓查看并处理订单↓寄养过程中发布宠物动态↓通过消息页与宠主沟通机构端的关键点在于“先审核再经营”。也就是说机构注册之后不能立即开展业务而是需要先提交资料并等待管理员审核。审核通过后机构才能继续维护服务套餐、处理订单和发布动态。这种设计符合真实平台类业务系统的逻辑可以有效降低虚假机构、低质量服务方直接进入平台的风险。3. 管理员业务流程管理员端的主流程可以概括为管理员登录↓进入后台仪表盘↓审核机构申请↓查看用户、订单、评价和投诉↓通过 AI 监控和预警中心识别平台风险管理员端的设计目标不是参与每一笔交易而是对平台整体运行情况进行监管。其中比较重要的能力包括机构审核投诉处理评价监管AI 风险监控平台统计分析。对于平台型系统来说管理端的价值并不只是“增删改查”而是要提供可监管、可追溯、可预警的治理能力。六、小程序端架构设计小程序端按照页面层、公共能力层、组件层和状态层进行组织。1. 页面层小程序页面主要集中在miniapp/src/pages/miniapp/src/pages.json页面按照角色和业务模块进行划分包括公共鉴权页宠主页机构页聊天页订单页评价页投诉页。这种划分方式比较清晰能够让不同角色的页面职责保持相对独立。2. 公共能力层小程序公共能力层主要包括以下文件config/env.jsutils/request.jsutils/auth.jsutils/socket.jsapi/modules.js各文件职责如下config/env.js用于维护环境配置例如后端 API 地址WebSocket 地址请求超时时间不同环境下的服务地址。utils/request.js用于封装 HTTP 请求统一处理请求头token 注入401 登录失效403 权限不足500 服务异常timeout 超时提示。请求层统一封装后页面无需重复处理通用错误逻辑可以显著降低页面代码复杂度。utils/auth.js用于维护登录态和角色守卫包括保存 token保存当前用户保存当前角色页面进入时校验角色登录失效后清理状态并跳转角色选择页。utils/socket.js用于封装 WebSocket 生命周期包括创建连接消息监听断线处理消息发送关闭连接连接异常降级处理。api/modules.js用于按业务模块封装接口调用使页面代码不直接拼接接口地址而是通过模块化 API 调用后端服务。3. 组件层当前小程序公共组件主要包括PetOwnerBottomNav.vueInstitutionBottomNav.vueInstitutionCard.vue这些组件主要承担底部导航、机构卡片等复用 UI 的职责。组件化的好处是可以避免多个页面重复编写相似结构同时也方便后期统一调整样式和交互。4. 状态层当前小程序存在store/auth.js同时大量页面也会通过utils/auth.js中的方法读取本地存储和进行角色守卫。从当前结构看系统状态管理仍然偏轻量主要围绕登录态、用户信息和角色信息展开。对于当前业务阶段来说这种方式足够支撑主流程但如果后续小程序页面继续增多可以进一步考虑将订单、聊天、机构信息等状态做更明确的模块化管理。七、管理端架构设计管理端采用后台系统常见的布局方式登录页单独布局后台页面统一挂载在AdminLayout.vue下。1. 路由布局管理端通过路由划分不同功能页面管理员登录后进入统一后台框架。典型结构如下登录页↓AdminLayout├── 仪表盘├── 机构审核├── 机构管理├── 用户管理├── 订单监管├── 评价监管├── 投诉处理├── AI 监控├── 预警中心└── 数据统计这种结构适合中后台管理系统导航关系清晰功能分区明确。2. 管理端模块划分管理端模块按职责划分为仪表盘机构审核机构管理用户管理订单监管评价监管投诉处理AI 监控预警中心数据统计。其中机构审核和投诉处理属于强业务模块AI 监控和预警中心则体现了平台对风险识别能力的扩展。3. 管理端数据访问管理端通过admin-web/src/api/中的请求封装访问后端接口。这种方式保证了管理端不会绕过后端直接访问数据库所有业务数据仍然由后端统一控制方便做权限校验、日志记录和数据聚合。八、后端架构设计后端采用 Django app 按业务领域拆分整体结构清晰便于维护和扩展。1. 后端模块划分后端主要包含以下 appusers 用户、登录、管理员用户管理pets 宠物档案institutions 机构、机构申请、套餐orders 订单、宠物动态chat 会话、消息、WebSocketreviews 评价与评价 AI 分析complaints 投诉与证据dashboard 管理端统计、预警和推荐日志ai_center AI 聚合服务common 常量、响应、通用模型、健康检查这种拆分方式符合典型领域模型设计思想。每个 app 负责一个相对独立的业务领域既避免了所有代码堆积在一个模块中也方便后续单独维护和扩展。2. 路由组织后端总路由位于backend/config/urls.py所有业务接口统一挂载在/api/路径下。统一接口前缀的好处是前后端对接清晰方便做网关或反向代理方便区分 API 请求和静态资源请求后续版本化接口时也更容易扩展例如/api/v1/。3. 数据层设计系统核心数据统一存放在 MySQL 中主要包括用户宠物机构申请机构服务套餐订单宠物动态会话聊天消息评价AI 评价分析投诉投诉证据预警推荐日志。这种设计保证了所有端使用同一份数据源。无论是宠主端查看订单、机构端处理订单还是管理端监管订单本质上都是围绕同一份订单数据进行操作。九、鉴权与角色隔离设计系统中存在多个角色宠主机构管理员。因此鉴权和角色隔离是系统安全设计中的重点。1. HTTP 鉴权HTTP 接口统一采用 JWT 鉴权机制。登录成功后后端向前端发放access tokenrefresh token前端请求接口时在请求头中携带Authorization: Bearer token后端通过解析 token 判断当前用户身份并根据用户角色限制接口访问。2. 小程序角色守卫小程序通过utils/auth.js实现角色守卫主要负责保存 token保存当前用户保存当前角色页面进入时进行角色校验token 失效时清理登录态401 时跳回角色选择页。例如宠主页面只允许宠主访问机构工作台只允许机构用户访问。这样可以避免用户通过手动跳转页面路径访问不属于自己角色的功能。3. 管理端权限守卫管理端路由守卫主要检查两个条件1. 是否存在 token2. user.role 是否等于 admin只有管理员角色才能进入后台页面。这类设计虽然看起来简单但非常关键。因为管理端涉及机构审核、用户监管、投诉处理和风险查看如果角色隔离不严格会带来明显的安全风险。十、订单与机构业务设计1. 机构资料与套餐维护机构审核通过后可以维护机构资料和服务套餐。机构资料主要包括机构名称地址联系方式简介服务能力营业信息审核状态。套餐信息主要包括套餐名称套餐价格服务内容适用宠物类型服务周期是否启用。套餐是宠主创建订单的重要依据因此机构端维护套餐后宠主端才能基于套餐进行选择和下单。2. 订单创建流程宠主创建订单通常需要选择机构套餐宠物寄养时间备注信息。订单创建后机构端可以查看并处理订单。订单状态可以根据业务流程进行流转例如待处理↓已接单↓寄养中↓已完成同时在部分业务场景中机构还可以进行改价操作。3. 宠物动态反馈寄养过程中机构可以发布宠物动态宠主可以在订单详情或相关页面查看。宠物动态的存在非常符合真实业务需求。因为宠主在寄养期间最关心的问题之一就是我的宠物现在怎么样通过宠物动态机构可以上传文字、图片或状态说明让宠主及时了解宠物情况从而提升服务透明度和信任感。十一、聊天系统设计聊天是本项目中比较重要的模块之一。对于宠物寄养业务而言宠主和机构之间的沟通不仅是咨询工具也是服务过程中的重要凭证。因此聊天系统既要支持实时通信也要保证消息可靠落库。1. 聊天核心能力当前聊天模块已经支持会话创建会话列表历史消息总未读数已读标记WebSocket 实时推送HTTP 发送降级单账号开发测试辅助。这些能力已经可以支撑宠主和机构之间的主要沟通流程。2. 聊天链路设计聊天详情页进入后流程如下进入聊天页↓先拉取历史消息↓创建 WebSocket 连接↓在线时接收实时推送↓发送消息时优先保证消息落库↓WebSocket 不可用时走 HTTP 降级发送该设计体现了一个非常重要的原则消息先落库实时推送只是增强能力。也就是说聊天系统不能把 WebSocket 当成唯一消息通道。因为 WebSocket 可能会受 Redis、网络、连接状态等因素影响一旦实时链路失败如果消息没有落库就会造成数据丢失。因此当前系统采用“落库优先、实时增强、离线补偿”的策略是比较稳健的设计。3. WebSocket 路由当前系统存在两个 WebSocket 路由/ws/chat/conversation_id//ws/orders/order_id/pet-status/其中/ws/chat/conversation_id/用于聊天消息实时推送/ws/orders/order_id/pet-status/用于订单宠物状态相关推送。4. WebSocket 鉴权WebSocket 使用JwtAuthMiddlewareStack进行鉴权。它可以从 query token 或 header token 中识别用户身份从而保证 WebSocket 连接也受权限控制而不是任何人都可以随意连接聊天房间。这一点非常重要。因为聊天消息属于用户隐私数据如果 WebSocket 没有鉴权很容易产生越权访问风险。5. 降级策略当前系统设计中明确考虑了 Redis 不可用时的情况。当 Redis 未启动或 WebSocket 不可用时聊天页仍然可以拉取历史消息发送消息自动走 HTTP页面不允许白屏未读数和历史消息仍然可以作为离线补偿。这种降级设计非常实用尤其是在开发测试阶段或者部署环境不完整时可以保证主业务流程不被完全阻断。十二、AI 能力设计AI 能力并不是本系统的主链路但它增强了平台的智能化体验和风险识别能力。当前 AI 模块集中在apps/ai_center主要能力包括机构 AI 口碑摘要聊天建议评价分析与风险标记。1. 机构口碑摘要机构口碑摘要可以基于评价内容、服务表现等信息生成简要总结帮助宠主更快了解机构整体口碑。对于宠主来说相比逐条阅读评价一个结构化的摘要可以更高效地辅助决策。2. 聊天建议聊天建议可以在宠主和机构沟通时提供辅助回复思路。例如当宠主咨询寄养环境、价格、宠物饮食等问题时系统可以辅助机构生成更规范、更友好的回复建议。3. 评价分析与风险标记当用户提交评价后系统可以对评价内容进行 AI 分析识别其中可能存在的风险信息例如服务纠纷宠物健康问题态度投诉疑似恶意评价高风险负面反馈。分析结果可以进入管理端为平台运营人员提供辅助判断。4. AI 降级设计当前系统明确考虑了 Ollama 未启动时的情况。当 Ollama 不可用时AI 实时分析不可用本地模型能力不可用非 AI 主流程不受阻塞。这是一种正确的工程设计思路。AI 能力在当前系统中属于增强能力而不是基础交易链路。因此AI 服务异常时不应该影响登录、下单、聊天、订单处理等核心功能。十三、数据同步与一致性设计系统中的宠主端、机构端和管理端都通过同一后端访问同一份业务数据。数据同步方式主要分为三类1. 结构化业务数据通过 HTTP 同步例如用户信息机构信息套餐信息订单信息宠物档案评价投诉。这些数据对实时性要求没有聊天那么高因此通过 HTTP API 查询和提交即可。2. 在线实时消息通过 WebSocket 同步例如聊天消息订单宠物状态变化实时通知类数据。这些数据对实时体验要求较高因此通过 WebSocket 提升交互体验。3. 离线消息通过历史记录和未读数补偿当用户不在线或 WebSocket 不可用时系统通过会话列表历史消息未读数已读标记实现离线补偿。这种设计可以确保用户再次进入页面时仍然能够看到完整消息记录。十四、错误处理设计一个业务系统是否稳定不仅取决于功能是否完整还取决于异常情况下是否可控。本项目在错误处理方面主要分为小程序端和后端两层。1. 小程序端错误处理小程序请求层负责统一处理401清理登录态并跳转角色选择页403提示无权限500提示服务异常timeout提示请求超时WebSocket 异常切换为 HTTP 降级链路。统一错误处理可以避免每个页面重复编写异常逻辑也能保证用户收到一致、明确的反馈。2. 后端错误处理后端通过统一响应结构和权限控制避免将普通业务错误直接暴露为 500。例如未登录返回 401无权限返回 403参数错误返回 400业务状态不允许操作时返回明确业务提示系统异常才返回 500。这样可以让前端更容易根据状态码做对应处理也让用户看到更友好的错误提示。3. 健康检查接口系统提供/api/health/用于快速判断服务状态包括Django 是否在响应MySQL 是否可用Redis 是否可用Ollama 是否可用。健康检查接口对于开发、部署和排障都非常有帮助。例如当聊天实时推送异常时可以通过健康检查快速判断 Redis 是否正常当 AI 功能不可用时可以判断 Ollama 是否启动。十五、当前已实现能力总结从当前项目状态来看系统已经具备较完整的业务基础能力。1. 登录与角色隔离当前系统已经支持小程序宠主、机构两套登录入口管理端管理员登录后端按角色限制接口访问。这说明系统已经具备多角色业务系统的基础安全模型。2. 宠物档案宠主可以维护自己的宠物档案包括新增宠物编辑宠物删除宠物设置默认宠物。宠物档案是订单创建和寄养服务的基础数据。3. 机构与订单当前系统已经支持机构资料维护服务套餐维护宠主创建订单机构处理订单机构改价宠物动态发布与查看。这部分能力构成了宠物寄养业务的核心交易链路。4. 聊天能力聊天模块当前支持会话创建会话列表历史消息未读数已读标记WebSocket 实时推送HTTP 发送降级单账号开发测试辅助。尤其是“单账号聊天主链路”的支持对于开发阶段演示和调试非常有价值。5. AI 能力当前 AI 相关能力包括机构 AI 口碑摘要聊天建议评价分析风险标记。虽然 AI 能力依赖 Ollama但系统已经设计了降级策略不会阻塞非 AI 主流程。十六、当前可测试主链路1. 宠主端主链路宠主端可以按照以下顺序测试角色选择↓宠主登录↓首页浏览机构↓机构详情↓创建订单↓订单列表与订单详情↓消息页↓聊天页↓宠物档案页↓评价↓投诉这条链路基本覆盖了宠主从进入系统到服务反馈的完整体验。2. 机构端主链路机构端可以按照以下顺序测试机构登录↓机构申请↓审核状态↓工作台↓订单列表↓动态中心↓消息列表↓资料页↓服务套餐页这条链路主要覆盖机构从入驻到接单服务的完整流程。3. 单账号聊天测试链路在只有一个微信测试号的情况下系统也支持聊天演示宠主发起聊天↓发送消息↓通过 dev-reply 或管理命令模拟机构回复↓查看未读数与历史消息这个设计非常适合开发阶段调试。因为微信小程序测试环境中经常只有一个测试号如果必须准备两个真实账号才能测试聊天会明显增加调试成本。十七、当前未完成或受限项分析虽然当前系统主链路已经基本可测但仍然存在一些环境和功能限制。1. Redis 未启动时的限制当前运行环境下 Redis 未启动因此WebSocket 实时推送可能失败Django Channels 的实时消息能力受限订单状态实时推送也可能受影响。但是系统已经设计了降级策略聊天主流程仍可通过 HTTP 历史消息保持可用发送消息可以走 HTTP 降级未读数和历史消息可以完成离线补偿。因此Redis 不可用会影响实时体验但不会完全阻断聊天主流程。2. Ollama 未启动时的限制当 Ollama 未启动时AI 实时分析不可用本地模型能力不可用机构口碑摘要、聊天建议、评价分析等能力会受影响。不过非 AI 主流程不会被阻塞例如登录浏览机构创建订单聊天宠物档案投诉评价提交。这说明系统对 AI 能力的定位是“增强能力”而不是“强依赖主链路”。3. 小程序实机验证限制当前代码和编译产物已经修复但仍需要在微信开发者工具中重新加载miniapp并进行人工点击复测。同时小程序编译目录已经修正为dist/dev/mp-weixin/旧的e.onOpen is not a function问题不再属于当前源码问题而更可能是旧构建缓存造成的异常。因此在继续测试时建议先清理旧缓存再重新编译和加载小程序。十八、稳定性现状分析从当前项目状态来看系统稳定性可以总结为以下几点1. 后端结构完整可启动后端已经按照业务模块完成拆分具备较清晰的工程结构和接口组织方式。2. 主业务链路可测宠主端、机构端和管理端均具备可测试主链路核心功能已经形成闭环。3. 聊天采用稳健策略聊天模块已经切换为落库优先实时增强离线补偿这是一种非常合理的工程实现方式。4. 小程序构建路径已修正当前小程序编译目录已经修正为dist/dev/mp-weixin/这有利于避免开发者工具加载旧目录或旧构建产物。5. 历史缓存问题已定位旧的e.onOpen is not a function问题不再属于当前源码而是旧构建缓存问题。后续测试时应重点关注重新构建和缓存清理。十九、项目亮点总结1. 三端协同设计完整系统不是单一的小程序项目而是宠主端、机构端和管理端共同协作的业务系统。这种设计更贴近真实平台类项目。2. 后端统一服务数据口径一致三端都通过 Django 后端访问同一份业务数据避免了多端数据割裂问题。3. 角色权限边界清晰宠主、机构和管理员拥有不同入口和不同权限后端接口也根据角色进行访问限制。4. 聊天系统具备可靠性设计聊天没有单纯依赖 WebSocket而是采用“先落库再实时推送”的方式。即使 Redis 或 WebSocket 不可用系统仍然可以通过 HTTP 和历史消息保证聊天主流程可用。5. AI 能力合理融入业务AI 没有为了使用而使用而是结合了真实业务场景机构口碑摘要聊天建议评价分析风险标记。这些能力都能增强平台体验和管理效率。6. 降级策略明确系统对 Redis 和 Ollama 不可用的情况都有清晰处理避免外部依赖异常导致主流程整体瘫痪。7. 具备平台监管能力管理端不仅能做基础数据管理还包含投诉处理、AI 风险监控和预警中心体现了平台型系统的治理思路。二十、后续优化方向虽然当前系统已经具备较完整的主链路能力但后续仍可以从以下几个方向继续优化。1. 完善 WebSocket 稳定性可以继续增强自动重连机制心跳检测连接状态提示消息发送失败重试多端在线状态同步。这样可以进一步提升聊天和订单动态推送的实时体验。2. 增强订单状态流转订单模块可以继续细化状态例如待支付待机构确认已接单寄养中待评价已完成已取消退款中已退款并为不同状态设计不同的可操作按钮和权限规则。3. 完善支付闭环如果后续接入真实支付能力可以继续完善预支付订单微信支付回调支付状态同步退款流程对账记录支付异常处理。4. 强化投诉与证据链投诉模块可以进一步增强图片证据上传聊天记录关联订单信息关联平台处理备注投诉状态流转处理结果通知。这对于平台纠纷处理非常关键。5. 优化 AI 风险识别AI 风险能力可以继续扩展评价情绪分析投诉内容分类高频负面关键词识别高风险机构预警聊天内容异常提醒服务质量趋势分析。这样管理端可以从“人工查看”升级为“系统辅助发现问题”。6. 增加运营数据分析管理端可以进一步增强统计能力例如日新增用户数日新增订单数订单成交金额机构入驻趋势投诉率评价平均分热门机构排行AI 风险趋势。这些数据可以帮助平台方更好地了解业务运行情况。7. 优化小程序用户体验小程序端还可以继续优化机构搜索与筛选地图定位套餐对比订单进度时间线宠物动态提醒聊天消息通知评价标签化投诉流程引导。这些优化可以进一步提升宠主和机构的使用体验。二十一、开发与测试建议结合当前项目现状建议后续继续采用以下推进策略先保证主链路可测再逐步补实时增强和智能化能力。具体建议如下1. 优先验证主流程先完整跑通宠主注册登录机构注册申请管理员审核机构维护套餐宠主创建订单机构处理订单聊天沟通宠物动态评价投诉。主流程稳定后再重点测试边界场景。2. 单独验证实时通信Redis 启动后重点测试WebSocket 是否能连接聊天消息是否实时到达断线后是否能恢复未读数是否准确已读标记是否正常HTTP 降级是否可用。3. 单独验证 AI 能力Ollama 启动后重点测试机构口碑摘要聊天建议评价分析风险标记AI 服务异常时是否正确降级。4. 清理小程序缓存后复测由于旧构建缓存可能影响测试结果建议在微信开发者工具中清理缓存重新编译确认加载目录为dist/dev/mp-weixin/重新点击完整主链路。