4S店客户管理系统做成微信小程序这篇论文为什么值得认真写做4S店客户管理系统之前我真去一家店里蹲了两天。销售手里一台车卖出去之后客户档案就丢在Excel里售后顾问提醒保养靠翻系统、靠打电话保险续保那边每到月底就开始疯狂群发短信。整个流程不能说没有管理只能说全靠人力扛。把这样一个业务搬到微信小程序上不是赶时髦给门店做个H5而是把“保养到期”“保险到期”这类服务节点真正自动化地盯起来。这篇复盘是基于我做完整套“4S店客户管理系统微信小程序”毕业设计项目的经历从需求、技术选型、数据库设计、页面实现一路讲到论文写作和答辩准备。适合正在准备小程序方向毕业设计的同学、打算给门店做数字化工具的开发者以及想评估这套方案可行性的4S店业务负责人。小程序最适合这类场景的原因其实特别朴素低频服务、扫码即用、不用下载App。一位车主一年进店两三次你让他装个App根本不现实但打开微信扫一下就能绑定车辆、查维保记录、预约保养这个成本几乎为零。下面我按项目推进的真实顺序拆一遍里面每一条都是实际踩过之后才写出来的。1. 项目概述与需求分析1.1 4S店客户管理的核心痛点做系统之前先把业务痛点梳理清楚。4S店的客户流失问题非常严重出保之后客户回店率常年不到一半大量车主流向路边维修店。流失的原因不是4S店技术不行而是服务节点根本没盯住——保养该做了没人提醒保险到期了没人跟进客户半年没进店也没人发现。第二个痛点是信息碎片化。销售手里一套客户资料售后手里一套保险专员手里又一套同一台车的信息散在三四个Excel里。客户打电话来问上次保养是什么时候顾问要先翻半天系统体验非常差。第三个痛点是触达方式粗放。短信群发打开率极低电话回访遭人烦微信社群没人运营。不是不想关怀客户是缺少一个低频、不打扰、且客户愿意接受的触达通道。这些痛点决定了系统必须围绕“车辆档案 服务节点提醒 自助预约”来设计而不是做一个通用型CRM。1.2 为什么微信小程序比App更合适选微信小程序做载体有四个原因答辩时把这些讲透基本没人能问倒你。第一免安装。汽车服务是典型的低频场景一位车主一年打开系统不到十次你让他为十次使用装一个App卸载率会教做人。小程序扫码即用用完即走留存不靠桌面图标靠订阅消息。第二身份体系现成。小程序可以直接用微信授权登录再通过手机号快速绑定车主身份注册门槛大大降低。对4S店而言每一个微信用户都是一个可触达的私域资产比App的匿名访客强太多。第三订阅消息能实现精准提醒。这是小程序最值钱的能力——客户授权一次系统就能在保养到期时下发提醒。后面我会详细讲一次性订阅消息的坑。第四支付和售后闭环。小程序内可以直接结算保养费用省去收银台排队售后评价、投诉建议都能在一个入口里完成。1.3 角色边界与功能范围界定做毕设或者做一期MVP功能都一定要克制不然会把自己拖死。我最终把角色和功能切成三块车主端车辆绑定、预约保养、维保记录查询、积分与优惠券。门店端客户列表、预约审核、维保记录录入、到期客户筛选。管理端数据看板、会员统计、活动配置、反馈处理。核心做三条闭环就够了一通客户从扫码到绑定车辆二约客户自主预约保养、门店确认到店三提醒保养到期系统自动发消息。积分、优惠券这类“锦上添花”的功能放在第三期再加。论文里你完全可以把这三条闭环写成一个“核心业务流程闭环图”篇幅、逻辑都有了。2. 技术选型与系统设计思路2.1 前端框架选原生小程序还是跨端方案小程序前端有三条路可选微信原生、uni-app、Taro。我直接说结论如果项目定死了“只做微信小程序”原生框架永远是最稳的选择。原生小程序的优势在于调试器还原度最高生命周期、组件机制都是官方出品碰到奇怪问题查文档和社区都方便。对写论文来说原生框架还有一个隐性优势——评审老师大概率也熟悉原生语法你讲onLoad/onShow的区别他能听懂讲 uni-app 的条件编译他就未必能接住。uni-app 的价值在于一套代码多端发布但代价是要应对平台差异支架方法、组件行为在不同端上可能不一致经常要为兼容写条件编译。Taro 适合 React 技术栈的团队个人项目用 Taro 会引入额外编译复杂度。这里放一张我当时做的对比表方便你直接抄进论文维度原生小程序uni-appTaro多端支持仅微信多端多端学习成本低中需懂Vue中需懂React调试体验最好较好较好社区资料最丰富丰富一般适合场景微信专属项目多端业务多端业务2.2 后端方案云开发还是自建服务器后端是很多毕设卡壳的地方。我建议你在“微信云开发”和“自建后端Node.js MySQL”里二选一其余方案别碰。微信云开发的好处是省事有免费的云函数、云数据库、云存储用户登录的 openid 直接从云函数上下文里拿不需要自己写鉴权逻辑数据库操作也支持基础事务。对时间紧、想快速出完整成品的同学云开发几乎是作弊器。缺点有两个一是冷启动延迟用户突然点进来可能要等一两秒云函数拉起二是自建后端能写的“架构章节”在云开发下就写不出来了论文里如果全靠“调用云函数”一句话带过显得单薄。自建后端的好处就是真的能写出一整章内容接口鉴权、参数校验、事务、并发控制、HTTPS 部署全是实打实的代码。缺点是你得自己搞定服务器、域名、HTTPS 证书而且联调阶段手机真机预览必须配合法域名这一步经常让新手崩溃。我的个人建议毕设如果时间三个月以上选自建后端内容深度完全不一样。时间紧就直接云开发先把业务跑通论文里在“架构设计”处做“云开发替代传统后端”的对比论证也能写出东西来。2.3 数据库设计核心表结构与字段说明数据库是整个系统的地基。我把关键表列出来字段都是实际能落地的表名核心字段说明用户表openid、unionid、昵称、头像、手机号openid只负责鉴权不参与业务客户表客户ID、姓名、手机号、性别、生日手机号唯一索引业务主键车辆表车辆ID、车牌号、品牌、车型、车架号车牌号唯一外键关联客户ID维保记录表记录ID、车辆ID、里程数、保养项目、下次保养日期冗余“下次保养日期”用于到期提醒预约单表预约ID、客户ID、车辆ID、到店时间、状态状态用int0待确认/1已确认/2已到店/3已完成/4已取消积分流水表流水ID、客户ID、变动值、类型、时间只做流水记录总分通过SQL聚合计算优惠券表券ID、客户ID、面额、有效期、状态状态0未使用/1已使用/2已过期设计时有几个坑要提前避开。第一openid 和业务身份必须分层。openid 只用来做微信登录客户的手机号才是业务主键。如果以后要对接小程序之外的渠道比如PC端openid 不能当客户ID用。第二车辆表不存“主驾驶人”只存客户关系。一台车可能一家人开绑定关系放在客户车辆关联表里一个客户可以绑多台车一台车也可以关联多个客户用中间表解耦。第三维保记录表要冗余“下次保养日期”。到期提醒是一个高频筛选查询如果每次都要关联保养记录再算日期查询会慢很多。直接给维保记录加一个“下次保养日期”字段提醒查询就变成select * from 维保记录 where 下次保养日期 between ...一条SQL的事。2.4 登录鉴权与接口安全设计很多论文里登录就写一个“wx.login() 获取code”答辩时老师一问“然后呢”就卡住。完整流程应该是小程序调用wx.login()拿到临时 code。code 传到后端后端用 code 换 openid云开发场景下云函数直接用cloud.getWXContext()拿 OPENID连这一步都省了。服务端用 openid 生成自定义登录态 token推荐 JWT返回给小程序。小程序把 token 存进 storage后续每个请求都在 header 里带Authorization: Bearer token。后端用中间件统一校验 token失效则返回 401小程序收到 401 自动跳登录页重新授权。这里有两个细节必须写进论文里因为它们是“设计理由”。一个是 code 的有效期是 5 分钟而且只能使用一次所以 code 绝不能缓存到前端存储里用完即丢。另一个是为什么不用 openid 直接当登录凭证——openid 是微信平台的唯一标识一旦泄露任何拿到它的人都能冒充这个用户所以必须再包一层 token并给 token 设置过期时间。接口安全方面除了鉴权还需要做入参校验、防重放时间戳加nonce、SQL 注入过滤。微信云开发的数据库天然带权限控制自建后端就要自己在 Data Access Layer 层做白名单校验别把原生 SQL 拼接放出去。3. 核心功能模块拆解3.1 车辆绑定与客户档案管理客户档案模块的第一件事是“一客多车”。一位车主名下可能有台轿车一台SUV还有一台给家人开的代步车订单、维保记录必须能分车查询。我的做法是客户表、车辆表、绑定关系表三张表独立用户在小程序里可以添加多台车每台车维护自己的车牌号、品牌车型、车架号。录入方式这里有一个非常容易踩的坑很多同学想加“扫描身份证自动提取信息”功能觉得答辩时炫酷。醒一醒证件识别涉及 OCR小程序本身没有原生能力要么接第三方收费 API要么自己训练模型都不是毕设该碰的复杂度而且是敏感个人信息隐私合规问题一堆。我的建议手动录入 车牌号辅助识别就够了如果你想体现点智能化用云开发自带的人工智能扩展能力做车牌识别即可别把身份证识别引进来。档案管理的另一个重点是历史轨迹。客户从首次意向、试驾、购车、首保、维修到续保每一步都该有一条记录。这套数据能支撑后面所有营销动作比如筛选“购车满三年即将出保”的客户做回厂专案。论文里把这个模块写成“客户全生命周期档案”整个立意就立起来了。3.2 预约保养流程设计、时间槽位与状态机预约保养是系统的核心闭环。用户流程是这样设计的选择门店和车辆如果绑定过多台车。选择保养类型和项目比如小保养、大保养、更换轮胎。选择一个时间槽位半小时为一个单位每个槽位限制同一门店同时预约不超过3单。提交预约单状态为“待确认”。门店端顾问确认状态变为“已确认”同时调起订阅消息授权为“到店提醒”做准备。客户到店核销状态变为“已到店”。保养完成门店录入本次保养项目和下次保养建议状态变更为“已完成”。状态机是整个系统的重头戏书面上一定画一张状态流转图答辩直接照着讲。注意每一步状态变更都要校验前状态不能允许“已取消”跳回“已确认”这种边界是后端防并发之外的基本功。时间槽位冲突处理是有讲究的。同一辆车、同一家门店不能有两条时间重叠的预约这个校验要在后端做前端只是展示。如果用了云开发事务可以保证校验和插入的原子性自建后端就开事务锁行。我见过一个半吊子项目校验写在前端用户改个时间参数就能绕过这种漏洞答辩被抓住必死。3.3 到期提醒与订阅消息的一次性授权问题订阅消息是这套系统真正的杀手锏但也是坑最多的地方。先说规则wx.requestSubscribeMessage只能在用户主动点击事件里调用不能在页面加载时静默调用。用户点了“允许”你才能给他发一条一次性订阅消息。一次性订阅的含义是授权一次、发送一次发完那一次授权就消耗掉了。想再发必须让用户再点一次授权。所以“一次授权到期自动提醒”在汽车服务这个类目下做不到——长期订阅目前只优先开放给民生、政务、医疗等特定类目汽车类目拿不到长期订阅资格。我的落地思路是把授权动作嵌入到业务流程里。客户提交预约单时弹一次订阅消息授权授权内容定义为“保养完成提醒”到店核销时再弹一次定义为“下次保养到期提醒”。这样每次业务动作对应一次授权授权转化率最高也最不容易让用户反感。还有一个细节订阅消息的模板内容要精心设计。我用的模板包含车牌号、上次保养里程、保养项目客户收到消息不用打开小程序就知道该干吗。千万别只发一句“您该保养了”那是骚扰。3.4 会员积分与优惠券成本可控的增粘设计积分模块是很多门店的真实需求但我建议把它排到第二期再做。原因很简单积分规则牵扯到门店成本消费1元积1分、100积分抵1元这个比例算错了门店会亏。我的建议是积分抵现比例不要超过5%并且要在活动规则里写明有效期和使用门槛。积分获取方式就三条消费赠送、签到赠送、推荐新客赠送。签到赠送的积分一定不要设太高不然用户天天上来薅积分运营成本压不住。积分流水必须单独建表每一笔变动都有时间、来源、操作人方便后期对账和审计。优惠券模块最复杂的是“发券”和“核销”两个动作。发券场景包括新客注册礼、生日礼、保养后回馈券、流失召回券。核销要跟预约流程关联客户在预约单结算页选择优惠券后端校验券状态和有效期防止一个券被用两次。这块业务逻辑不难但字段和校验异常多很考验细节打磨。4. 前后端联调与关键页面实现4.1 请求封装与统一错误处理微信小程序的网络请求如果不封装后果就是每个页面都写一遍wx.request错误处理各写各的token 过期漏处理BFF 层改个 baseURL 全项目都要跟着改。我最终用一个 Promise 封装解决了所有页面复用问题核心代码长这样// utils/request.js const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${url}, method, data, header: { Authorization: Bearer ${wx.getStorageSync(token)}, Content-Type: application/json }, timeout: 10000, success: (res) { if (res.statusCode 200) { resolve(res.data); } else if (res.statusCode 401) { // token 过期重新静默登录再重发请求 handleTokenExpiry().then(() { request(url, method, data).then(resolve).catch(reject); }); } else { wx.showToast({ title: res.data?.message || 系统繁忙, icon: none }); reject(res); } }, fail: (err) { wx.showToast({ title: 网络连接失败, icon: none }); reject(err); } }); }); };封装的价值不只是少写几行代码而是把“错误处理”变成了一个统一收口的地方后端返回非0状态码、HTTP 401、断网、超时四种情况在消费者眼里只有一种体验——清晰的 toast 提示不崩溃不掉链。这里 toast 的title不能直接透传后端错误信息毕竟用户不需要知道“数据库字段长度超限”这种字眼后端返回错误信息要给两层面向接口调用的 code/message以及面向页面的友好提示。4.2 列表加载更多与分页策略客户列表、维保记录、积分流水全是长列表必然要做分页。最土的分页是page size后端起limit skip。但数据量一上去skip的性能会断崖式下降因为数据库要遍历前面全部数据才能跳过。我推荐游标分页以数据_id或时间戳为游标下一页查where({ _id 游标 }).limit(20)翻页性能恒定。前端部分列表页要做三件配套事上拉加载更多onReachBottom、下拉刷新onPullDownRefresh、数据去重。去重这个细节容易被忽视——用户快速下拉两次同一个请求可能发两遍返回数据重复插入列表。我给每个 item 加一个唯一 key渲染前用 Set 做一次去重这个小改动帮我挡了好几个线上 bug。列表页第二次进入要能“秒开”我的做法是把最近一次列表数据缓存到wx.setStorageSync页面onLoad先渲染缓存再静默拉取新数据替换。缓存 Key 要带版本号不然功能迭代后旧缓存污染新页面。4.3 顶部导航栏高度与自定义导航栏适配顶部导航栏高度这个问题凡是做过自定义导航栏的人都被它折磨过。微信小程序默认导航栏高度是固定的但机型不同刘海屏、挖孔屏的胶囊位置不一样写死高度必出兼容事故。正确做法是运行时动态计算const menuButton wx.getMenuButtonBoundingClientRect(); // 胶囊按钮位置 const systemInfo wx.getSystemInfoSync(); // 系统信息 const statusBarHeight systemInfo.statusBarHeight; // 状态栏高度 const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height; // navBarHeight 就是自定义导航栏应有的高度这套公式还能算出导航栏右侧内容的安全区域胶囊按钮的 left 值就是内容不能再往右穿的边界。如果你的页面用了自定义导航栏配置navigationStyle: custom每个页面的顶部都需要预留这个高度不然返回按钮会跟刘海重叠。封装成一个useNavBar公共方法全项目统一调用比每个页面各算一遍靠谱得多。4.4 订阅消息授权弹窗的触发时机与体验优化订阅消息授权弹窗的时机是一个“晚一步没人点早一步被拒绝”的博弈。很多团队喜欢在首页一进来就弹窗授权那基本等于跟用户说“快扫兴”。我的经验是授权弹窗必须跟用户的真实操作绑定——用户点了“提交预约单”之后系统弹出授权框文案写清楚“用于发送预约成功通知和保养到期提醒”这时的授权转化率是最高的。代码实现上wx.requestSubscribeMessage要在用户点击事件的回调内同步调用不能包在 setTimeout 里不能等异步接口返回之后再弹否则会被判定为非用户主动触达而失败。正确姿势是用户点击“确认预约”按钮先弹订阅消息授权授权完成后再把预约请求发出去。另外记住一个规则用户如果点了弹窗底部“总是保持以上选择”此后系统会自动按上次选择处理不会再次弹窗但开发者是无法主动查询到“用户当前订阅授权还剩几次”的。老代码里的wx.getSetting只能看到用户是否关闭了总开关订阅消息的具体剩余次数是拿不到的所以后端接口设计时一定要幂等处理“消息发送失败”和“授权次数不足”这两种异常。4.5 联调与调试经验实录联调阶段我踩过的坑可以写一页纸。首先开发者工具上的模拟器网络环境不等于真机。模拟器可以正常请求真机一发就 failed十有八九是“request 合法域名”没配置。开发阶段可以在开发者工具的“详情—本地设置”里勾选“不校验合法域名”但这个设置只对开发版生效真机预览的体验版、正式版必须把 HTTPS 域名配到小程序后台的 request 合法域名列表里而且域名证书不能过期这个检查务必在提审前做。第二真机联调后端时手机和电脑连同一个 WiFi后端接口地址写电脑的局域网 IP 加端口。注意小程序要求正式环境必须是 HTTPS但开发版的调试模式可以用 HTTP。我见过有人把http://192.168.1.101:3000写死在BASE_URL里提审直接被打回。第三前端请求报错时要学会看 Network 面板请求头、响应体、状态码都在里面。真机定位问题可以用线上的日志上报或者抓包工具看 HTTPS 流量需要在手机安装证书不过这个属于进阶调试新手先学会查后端日志更实在。5. 论文框架与答辩准备5.1 论文结构怎么搭才能撑起整章内容毕设论文和项目代码是两套东西代码跑得再溜论文结构要是不对老师看着也头大。我的论文目录是按下面这套搭的你可以直接当模板章节内容要点建议篇幅摘要项目背景、系统功能、技术方案、结论800字左右第一章 绪论背景与意义、国内外研究现状、论文结构2000字左右第二章 需求分析业务痛点、用户角色、功能用例、非功能需求3500字左右第三章 系统设计架构设计、数据库设计、接口设计、安全设计5000字左右第四章 系统实现关键模块的页面逻辑、核心代码、截图5000字左右第五章 系统测试测试环境、功能测试用例、性能测试、兼容性测试2500字左右第六章 总结与展望做了什么、不足、未来方向800字左右5.2 需求分析与设计章节怎么写出干货需求分析章节最容易写成“需求说明书”的堆砌。要写出干货必须从“业务场景”出发。比如“保养到期提醒”这个需求不能只写“用户需要收到提醒”而要写清楚客户出保后流失率多少当前人工提醒的效率是多少系统提醒的业务流程是什么提醒的触达渠道选订阅消息的理由是什么。这些数据撑起来需求分析章节就有肉了。设计章节的“接口设计”部分我强烈建议你做一张接口清单表列出每个接口的请求方式、路径、参数、返回字段。这不是凑页数而是给第4章的实现做索引。数据库设计部分除了E-R图还要写清楚字段注释和设计理由比如车牌号为什么建唯一索引、积分流水为什么单独建表这些“为什么”是答辩时老师最感兴趣的点。5.3 答辩高频问题Top10与应答思路我整理了十道高频答辩题每道都给应答思路为什么用微信小程序不用App——答低频服务场景免安装依托微信生态获客开发成本低于双端App。云开发和自建后端你怎么选、为什么——答如果用到云开发强调免运维、弹性扩缩和原生鉴权如果选自建后端强调可控性、事务能力和扩展性。两种方案在论文里做对比论证即可。数据安全怎么保障——答token鉴权、入参校验、数据库权限配置、敏感字段加密、日志审计。订阅消息为什么只能发一次——答这是微信平台的开放策略汽车服务类目未获得长期订阅资格所以设计上把授权嵌入业务节点。分页为什么用游标不用skip——答大数据量下skip性能线性下降游标恒定且能避免新增数据导致的翻页重复。多个用户同时预约同一个时间槽怎么办——答后端开启数据库事务先查后插校验与插入原子性数据库唯一索引兜底。用户恶意篡改积分怎么办——答所有积分变动走服务端接口、记录流水前端不直接写库敏感操作二次校验身份。索引建了哪些为什么——答车辆表车牌号唯一索引、客户表手机号唯一索引、预约单表时间门店联合索引、维保记录下次保养日期索引。怎么测试的——答功能用例覆盖主流程并发场景模拟兼容性测试覆盖主流机型和微信基础库版本。这个系统实际部署了吗——答如实说明开发环境和测试环境部署情况如果没上生产就强调部署方案已完成、真机测试通过避免打肿脸充胖子。5.4 论文排版与查重的避坑细节排版细节决定了老师的第一印象。截图前把开发者工具的动态调试窗口全部收起来只保留模拟器页面截图用“页面截图标注”的组合一张截图配一句话说明“用户点击了什么、预期出现什么”。代码片段只贴核心逻辑贴之前把无关的 console.log 全删掉注释要写清楚“为什么这么做”而不是“做什么”。参考文献是查重重灾区。别只挂“百度百科”找三到五篇微信小程序开发相关的真论文、两三篇数据库设计书籍的引用、两三篇汽车售后服务研究的期刊文章全部按学校要求的GB/T 7714格式写这个细节能看出你是不是真的看过文献。测试章节记得写“预期结果”和“实际结果”两列两列必须逐行对齐一个用例一个用例地写清楚。哪怕你实际只测了二十个用例也别只放一个大表格——拆成小程序端、门店端、管理端三个子表清晰又充实。6. 上线审核注意事项与踩坑备忘录6.1 审核类目与隐私合规要点提审之前必须做两件事一是选对服务类目。汽车服务类的小程序建议放在“汽车服务”分类下别为了蹭流量选“工具”或者“生活服务”类目和实际业务不符会被打回。二是配置“用户隐私保护指引”。新版微信要求小程序在后台声明收集哪些用户信息收集手机号、车牌号、位置信息都必须在隐私声明中逐一列明而且使用时要有弹窗提示和授权记录。隐私合规这块特别值得写进论文“非功能需求”章节因为它是严肃工程化项目的分水岭。如果你在论文里写了“本系统收集车辆信息用于提供服务”却没在技术实现中提到隐私弹窗和合规声明那答辩时基本会被老师抓住。6.2 真实开发里逃不掉的十个坑wx.getUserInfo拿不到用户头像昵称基础库 2.27.1 之后接口调整替代方案是头像昵称填写能力让用户手动填而不是自动读取。这个坑几乎每个新手都踩而且改了之后老代码全失效。云函数冷启动首次调用要等一两秒优化方案是定期预触发或者前端做 loading 兜底文案。订阅消息报错 43101用户取消了授权不代表系统 bug错误处理要区分。真机预览连不上后端检查 IP 是否同一个局域网、HTTPS 证书是否有效、合法域名是否配置。页面栈超过10层小程序默认最多10层用wx.navigateBack和wx.redirectTo代替部分navigateTo。包体超过2M限制图片压缩、分包加载、主包只保留核心页面。一个 4S 店系统主包不算大但如果你贴了一堆营销活动页分分钟超限。iOS 日期解析失败new Date(2024-01-01)在 iOS 返回 Invalid Date要转成2024/01/01格式。这个坑能让人崩溃。请求并发限制小程序同域同时最多10个请求批量上传图片时会触发并发上限要控制并发数。setData 滥用频繁 setData 大对象会导致页面卡顿列表页数据更新用局部路径更新。客服消息“假死”小程序后台没开“客服”功能客服入口在手机上点了没有任何反应。6.3 性能优化清单性能优化不是可选项是上线前的基本功。我整理了一份自检清单按优先级排首屏速度核心数据从 storage 先渲染再静默请求最新数据覆盖用户感知几乎零等待。分包策略主包只留首页、登录、预约三个核心页面其他页面全部扔分包主包体积直接减半。图片资源所有图片压缩后走 CDN列表页缩略图尺寸明确不加载原图。接口合并详情页原本三个接口车辆信息、维保记录、预约状态合并成一个聚合接口少一次网络往返就少一次失败概率。数据库索引每次提醒查询都要扫“下次保养日期”字段必须建索引否则数据量到几万条时会明显变慢。这套清单做完工具类小程序的体验基本能达到流畅的标准够撑起论文第五章的“性能测试”小节。最后分享一点个人体会做完这个项目最大的感受是小程序开发本身不难难的是把“业务节点”想清楚。4S店客户管理系统看起来是写了一堆页面、一堆接口实际上核心就是让“保养到期”“保险到期”这两件事被自动盯住让客户在需要服务的时候正好出现在你面前。如果你准备做这个题目我的建议是先把预约和提醒这两条闭环做得结结实实再去碰积分、优惠券这些外围功能。答辩的时候能讲清楚“每个设计决策背后为什么这么选”比功能堆得又多又全更能说服老师。最后再分享一个小技巧论文里的系统截图记得把开发者工具顶部的项目路径和调试信息裁掉只留真机模拟页面。这个细节看多了论文的老师一眼就能分辨你是真的做过还是在摆拍。祝你的项目顺利通过盲审答辩稳住。
