企业官网建设流程全解析

简介：这是一套基于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 项目练手、准备上架安卓应用市场的前端。源码本身是项目级结构，不是单页 demo，manifest 配置、页面路由、请求封装这些该有的都有，拿到手能直接改业务字段，而不是从零搭架子。

2. 拆开源码看结构：uniapp 项目骨架与 manifest 配置怎么落地

拿到一份 uniapp 项目源码，第一件事不是急着跑，而是先看清它的目录约定和配置文件。这套重机械维修系统的骨架是标准的 uniapp 工程结构，pages 放页面、static 放静态资源、components 放复用组件、common 或 utils 放请求封装和工具函数。真正决定它能不能顺利打包成 APP 的，是根目录那个 manifest.json，很多人跑不起来、打包报错，八成卡在这里。

2.1 目录结构与页面路由的对应关系

uniapp 的页面必须在 pages.json 里注册，没注册的页面跳转直接白屏。这套源码的页面大致分几块：登录、工单列表、工单详情、报修提交、个人中心。你打开 pages.json 会看到每个页面的 path 和 style，style 里的 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 的 token，401 直接踢回登录页，这是最常见的鉴权处理。你要改的就是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做本地通知，或者接后端的长连接推送，维修工接到新工单能及时响。验证方法很简单：拿两个账号，一个报修一个接单，走一遍完整流转，看状态和提醒是否都对得上。

从那以后我每次拿到这类业务源码，都强制先走一遍完整业务闭环再谈二次开发，因为页面能打开不代表流程能跑通。希望这套重机械维修系统的拆解能帮到你，少走几个我踩过的坑。

本文还有配套的精品资源，点击获取