简介这是一套基于uniapp开发的重机械维修系统APP项目源码面向需要构建设备报修与维修派单平台的前端开发者与软件工程学习者。系统作为用户与维修方之间的交互载体核心围绕报修流程展开用户可绑定设备在主界面发起报修或保养申请填写信息并定位报修地点以工单形式提交至所属行政区的区域主管由主管在后台分派任务维修员终端接收工单并选择接单或拒单拒单则回滚重新派单接单后进入维修流程并完善工单信息用户可实时查看进度。支付环节分为两步先支付维修员选定的配件费用维修完成后再支付人工服务费。资源包共1169个文件以531个js、345个vue为主辅以94个md说明、89个json配置、42个scss样式及若干图片与字体资源压缩包约2.29MB目录结构完整便于二次开发与流程梳理。目前已有123人学习适合作为毕业设计或uni-app全栈练习的参考项目。1. 重机械维修管理搬进手机这套 uniapp 源码到底能跑通什么工地上设备一趴窝维修工单还在微信群里靠吼、靠拍照片、靠 Excel 回填这是很多重机械租赁和维修团队的日常。这套基于 uniapp 的重机械维修系统 APP 项目源码解决的就是把「报修—派单—维修—验收—归档」这条链路塞进一个能同时跑微信小程序、安卓和 iOS 的客户端里。它适合两类人一类是手里有维修队、想快速搭一套内部工单系统的老板或技术负责人另一类是想拿一个完整业务型 uniapp 项目练手、准备上架安卓应用市场的前端。源码本身是项目级结构不是单页 demomanifest 配置、页面路由、请求封装这些该有的都有拿到手能直接改业务字段而不是从零搭架子。2. 拆开源码看结构uniapp 项目骨架与 manifest 配置怎么落地拿到一份 uniapp 项目源码第一件事不是急着跑而是先看清它的目录约定和配置文件。这套重机械维修系统的骨架是标准的 uniapp 工程结构pages 放页面、static 放静态资源、components 放复用组件、common 或 utils 放请求封装和工具函数。真正决定它能不能顺利打包成 APP 的是根目录那个 manifest.json很多人跑不起来、打包报错八成卡在这里。2.1 目录结构与页面路由的对应关系uniapp 的页面必须在 pages.json 里注册没注册的页面跳转直接白屏。这套源码的页面大致分几块登录、工单列表、工单详情、报修提交、个人中心。你打开 pages.json 会看到每个页面的 path 和 stylestyle 里的 navigationBarTitleText 就是顶部标题。常见做法是先把 pages 数组里第一个页面设为登录页或首页因为 uniapp 默认把数组第一项当启动页。{ pages: [ { path: pages/login/login, style: { navigationBarTitleText: 登录, navigationStyle: custom } }, { path: pages/order/list, style: { navigationBarTitleText: 维修工单, enablePullDownRefresh: true } } ], globalStyle: { navigationBarTextStyle: black, navigationBarBackgroundColor: #FFFFFF } }这段配置里navigationStyle: custom表示登录页用自定义导航栏适合放 logo 和背景图enablePullDownRefresh: true让工单列表支持下拉刷新维修工单是实时性要求高的场景这个开关基本必开。改页面标题就改navigationBarTitleText加新页面就往pages数组里追加一项路径要和实际文件目录严格对应大小写都不能错这是 uniapp 最容易翻车的地方之一。2.2 manifest.json 里决定打包成败的几个字段manifest.json 是 uniapp 打包 APP 的核心配置它分好几个平台节点app-plus 管 APP 端mp-weixin 管微信小程序端h5 管网页端。重机械维修系统如果要上架安卓应用市场重点看 app-plus 下的 distribute 节点里面配应用名称、版本号、图标、启动图还有安卓的包名。{ name: 重机械维修, appid: , versionName: 1.0.0, versionCode: 100, app-plus: { distribute: { android: { packagename: com.yourcompany.repair, permissions: [ uses-permission android:name\android.permission.CAMERA\/, uses-permission android:name\android.permission.INTERNET\/ ] }, ios: {}, sdkConfigs: {} } } }packagename是安卓应用的唯一标识一旦上架就不能随便改改了就变成一个新应用老用户收不到更新。permissions里相机权限是维修工单拍照上传的刚需网络权限是请求后端接口的基础。versionCode是整数每次发版必须递增versionName是给用户看的。这里有个血泪经验appid 那一栏如果留空用 HBuilderX 云打包时会提示你重新获取本地调试不影响但正式打包前一定要填上自己账号下申请的那个。2.3 请求封装与后端接口对接业务型项目不可能把请求散落在每个页面里这套源码一般会在 utils 下封一个 request.js统一处理 baseURL、token 和错误提示。维修系统的接口通常包括登录、工单列表、工单详情、提交报修、上传图片这几类。// utils/request.js const BASE_URL https://your-api-domain.com/api function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Content-Type: application/json, Authorization: uni.getStorageSync(token) || }, success: (res) { if (res.data.code 200) { resolve(res.data.data) } else if (res.data.code 401) { uni.reLaunch({ url: /pages/login/login }) reject(res.data) } else { uni.showToast({ title: res.data.msg, icon: none }) reject(res.data) } }, fail: (err) { uni.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) } export default request这段封装做了三件事拼 baseURL、带 token、按后端返回的 code 分流。Authorization头里放登录后存进 storage 的 token401 直接踢回登录页这是最常见的鉴权处理。你要改的就是BASE_URL换成自己的后端地址以及code 200这个成功判断不同后端约定不一样有的用 0 表示成功照着自己接口改。参数说明上options.url是相对路径options.data是请求体GET 请求会自动拼成 query。3. 从源码到能装的应用打包、上架与多端适配的实操路径源码能跑起来只是第一步真正交付给维修队用得打包成能安装的 APP 或者能扫码用的小程序。uniapp 的优势就是一套代码多端出但多端适配的坑也集中在这一步。这一章按「先跑通 H5 调试 → 再打小程序 → 最后打 APP」的顺序走每一步都有它存在的理由。3.1 本地跑通与 H5 调试导入项目到 HBuilderX 后先别急着打包用「运行到浏览器」把 H5 端跑起来这是排查页面逻辑最快的方式。运行前确认 manifest.json 里 h5 节点的router.base配置如果部署在子目录下要改本地调试一般默认/就行。# HBuilderX 里操作路径 # 1. 文件 - 导入 - 从本地目录导入选中源码根目录 # 2. 运行 - 运行到浏览器 - Chrome # 3. 浏览器打开控制台看 Network 里接口是否 200跑起来后重点看两件事一是登录接口通不通二是工单列表有没有数据。如果页面白屏先看控制台报错多半是 pages.json 里路径写错或者某个组件没引入。如果接口 404检查 request.js 里的 BASE_URL 是不是还留着示例域名。这一步不涉及打包改代码即时生效适合先把业务字段和页面文案改成自己团队的叫法。3.2 微信小程序端打包与包体积控制重机械维修系统如果给维修工用微信小程序是最省事的入口不用装 APP扫码就用。但小程序有主包 2MB 的限制热词里那个「source size exceed max limit 2mb」就是典型报错。这套源码如果静态图片多很容易超。{ mp-weixin: { appid: wx你的小程序appid, setting: { urlCheck: false, es6: true, minified: true }, optimization: { subPackages: true } } }urlCheck: false是本地调试时允许请求未备案域名正式发布前要改回 true 并在小程序后台配好合法域名。minified: true开启压缩能砍掉一部分体积。真正管用的是分包把工单详情、个人中心这类非首屏页面拆到 subPackages 里主包只留登录和列表。图片尽量走 CDN 或者放后端返回的 URL别一股脑塞 static 目录这是控制包体积最直接的手段。打包时在 HBuilderX 选「发行 → 小程序-微信」生成的代码用微信开发者工具打开上传。3.3 安卓 APP 打包与上架应用市场要上架安卓应用市场走 HBuilderX 的「发行 → 原生App-云打包」。打包前 manifest.json 里 app-plus 的图标、启动图、包名、版本号都得填全。云打包分公共测试证书和自有证书正式上架必须用自有证书证书用 keytool 生成。# 生成安卓签名证书 keytool -genkey -alias repairkey -keyalg RSA -keysize 2048 -validity 36500 -keystore repair.keystore # 参数说明 # -alias 证书别名打包时要对应填 # -validity 36500 表示有效期 100 年应用市场一般要求足够长 # -keystore 生成的证书文件名生成后把 keystore 文件、别名、密码填进云打包界面。这里有个后悔药级别的提醒证书和密码一定要备份应用上架后更新必须用同一个证书签名丢了就只能重新上架一个新应用。打包完成后拿到 apk去各安卓应用市场提交需要准备软著、隐私政策这些材料审核周期各家不同。iOS 端还需要苹果开发者账号和证书流程更绕源码本身跨端没问题卡点通常在账号和证书环节。4. 避坑与排查这套源码最容易翻车的五个地方项目源码类资源能不能用起来差别往往不在功能多全而在这些细节有没有提前说清。下面五条是我拆这类 uniapp 业务项目时反复遇到的按「现象 → 原因 → 解决」记下来。4.1 页面跳转白屏或报「page not found」现象是点击按钮跳转后一片空白控制台提示找不到页面。原因基本是 pages.json 里没注册目标页面或者 path 和实际文件路径大小写不一致。uniapp 对路径大小写敏感pages/Order/list和pages/order/list是两个东西。解决方法是打开 pages.json 逐项核对新增页面先注册再跳转跳转用uni.navigateTo({ url: /pages/order/list })路径前加斜杠。4.2 打包后接口全部失败现象是 H5 调试正常打成 APP 或小程序后所有请求报错。原因是 APP 端和小程序端对请求域名有校验小程序还要求域名备案并配在后台白名单。解决方法是小程序端在小程序后台「开发管理 → 服务器域名」里配上 request 合法域名APP 端检查 manifest 里网络权限是否开启以及后端是否允许跨域。本地调试可临时关 urlCheck正式环境必须配好。4.3 图片上传在真机上失败现象是模拟器能传图真机点上传没反应或报权限错误。原因是安卓真机需要动态申请相机和存储权限源码里如果只写了uni.chooseImage没做权限判断就会静默失败。解决方法是在调用前用uni.getSetting查权限没授权就uni.authorize申请manifest 里也要声明对应权限。这是维修工单拍照场景的高频坑。4.4 云打包提示 appid 为空现象是点云打包弹窗要求获取 appid。原因是 manifest.json 里 appid 字段留空这个 appid 是 DCloud 的应用标识不是微信小程序的 appid。解决方法是登录 DCloud 开发者账号在 HBuilderX 里点「重新获取 appid」它会自动写入 manifest。注意别和 mp-weixin 节点下的微信 appid 搞混两个是不同平台的东西。4.5 修改代码后打包没生效现象是改了页面文案或逻辑重新打包发现还是旧的。原因是 HBuilderX 有缓存或者改的是编译后的产物目录而不是源码目录。解决方法是改完先「运行到浏览器」确认生效再打包打包前清理一下项目缓存确认改的是源码根目录下的文件。这个坑不致命但很耗时间养成改完即验证的习惯能省很多事。5. 进阶玩法把工单状态机和消息提醒接进这套源码源码跑通、打包上架只是及格线真正让维修队愿意天天用的是业务闭环。重机械维修的核心是工单状态流转待接单 → 维修中 → 待验收 → 已完成。这套源码一般有状态字段但状态机校验和消息提醒往往要自己补。我一般会在提交状态变更的接口前加一层前端校验防止维修工跳步操作。// 工单状态流转校验 const STATUS_FLOW { pending: [repairing], // 待接单只能转维修中 repairing: [verifying], // 维修中只能转待验收 verifying: [done, repairing], // 待验收可完成或打回 done: [] } function canTransfer(current, next) { const allowed STATUS_FLOW[current] || [] return allowed.includes(next) } // 调用示例 if (!canTransfer(order.status, done)) { uni.showToast({ title: 当前状态不能直接完成, icon: none }) return }这段校验把合法流转路径写死成一张表canTransfer判断当前状态能不能到目标状态不能就拦下来提示。参数上current是工单当前状态next是准备改成的状态。这样做的好处是前端先挡一道后端再做一次校验双保险。消息提醒方面uniapp 可以用uni.createPushMessage做本地通知或者接后端的长连接推送维修工接到新工单能及时响。验证方法很简单拿两个账号一个报修一个接单走一遍完整流转看状态和提醒是否都对得上。从那以后我每次拿到这类业务源码都强制先走一遍完整业务闭环再谈二次开发因为页面能打开不代表流程能跑通。希望这套重机械维修系统的拆解能帮到你少走几个我踩过的坑。本文还有配套的精品资源点击获取