uniapp装修小程序全开源源码：二次开发到上线的完整避坑指南

简介：这份最新装修小程序系统源码基于UniApp跨平台框架开发，面向装修公司、设计工作室及独立工长，用于搭建推广引流、在线获客的用户端小程序，实现从品牌展示到预约量房的完整业务闭环。内置商城、案例、团队、工地、小区、广告、营销、全景、文章、单页、预约等11大管理模块，前端采用Vue语法体系，后端基于PHP开发并配套完整SQL数据库脚本，支持微信授权登录与多端同步编译，目录结构清晰、易二次开发。资料共2000个文件，以1203个js脚本、153个vue页面组件、229个HTML页面和214个JSON配置为主，另附2个sql数据库脚本，压缩包整体约31.66MB，可快速完成部署测试。已有61人浏览学习，适合具备基础PHP与小程序开发经验的读者作为商用级源码参考，也可用于学习装修行业小程序的技术架构、运营后台设计与营销组件落地方式。

1. 装修小程序系统源码：uniapp 全开源版到底能不能直接拿来用

拿到一套号称"全开源、亲测可用"的装修小程序源码，第一反应别急着导入 HBuilderX，先想清楚你要拿它干什么。装企老板要的是获客工具——业主点开小程序看案例、要报价、约看工地；开发者要的是能二次交付的底座——换皮肤、接接口、加模块。uniapp 版最大的价值在于同一套代码能编译到微信小程序、App 和 H5，而装修行业恰恰是"老板今天要小程序、明天问能不能做个 App"的重灾区，这套方案能省掉一次重写的钱。但它不是解压即用：后端接口、图片域名、资质配置都得自己补齐。下面把跑通这套源码的完整路径拆开讲，新手能一步步跟着跑起来，熟手直接跳去改参数。

2. 拆解一套装修小程序源码：项目结构里藏着多少要改的活

拿到源码第一件事不是点运行，而是先把目录过一遍。你花一晚上读结构，能省下后面三天的返工。大多数 uniapp 装修小程序的代码组织方式都类似：pages 放业务页面，components 放复用组件，static 放静态资源，根目录几个 JSON 文件管全局配置。先看清这几层，才知道哪些地方要动。

2.1 先看 pages.json：页面注册和 tabBar 决定小程序骨架

pages.json 是 uniapp 工程里最重要的配置文件，它不写业务逻辑，但决定了哪些页面能被打开、底部 tabBar 长什么样、导航栏用什么风格。装修类小程序一般有五个核心页面组：首页、案例库、报价、预约、个人中心。拿到源码先打开这个文件，确认 tabBar 页面是否齐全，页面路径有没有指向不存在的 vue 文件——这种低级错误在二手源码里特别常见。

{ "pages": [ { "path": "pages/index/index", "style": { "navigationBarTitleText": "首页", "enablePullDownRefresh": true } }, { "path": "pages/case/case", "style": { "navigationBarTitleText": "装修案例" } }, { "path": "pages/quote/quote", "style": { "navigationBarTitleText": "免费报价" } }, { "path": "pages/appointment/appointment", "style": { "navigationBarTitleText": "预约看工地" } }, { "path": "pages/mine/mine", "style": { "navigationBarTitleText": "我的" } } ], "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/case/case", "text": "案例" }, { "pagePath": "pages/quote/quote", "text": "报价" }, { "pagePath": "pages/mine/mine", "text": "我的" } ] }, "globalStyle": { "navigationBarTextStyle": "white", "navigationBarBackgroundColor": "#2B3A4A", "backgroundColor": "#F5F6F8" } }

这份配置有两点要注意。第一，tabBar 最多五个，案例、报价、预约如果都放 tab，地方会不够用，常见做法是把"预约看工地"做成首页和案例页里的按钮，而不是单独占一个 tab。第二，navigationBarBackgroundColor 用深色，是因为装修行业的案例图以浅色为主，深色导航栏能把页面视觉压住；如果你接的是主打年轻群体的整装品牌，改成白色底加黑色文字反而更合适。改完 pages.json 记得在微信开发者工具里重新编译，tabBar 修改不会热更新，这是新手最容易忽略的一个点。

拿到源码后我一般还会对照页面路径逐个检查组件引用。如果某几个页面引用了同一个自定义组件，但组件的属性名不一致，运行时不报错但 UI 渲染异常，这种问题最耗时间。用编辑器全局搜索组件名，然后把所有引用它的页面过一遍，花不了半小时，但能省下未来几天的排查成本。

2.2 manifest.json 和项目配置：AppID、权限、SDK 都在这

manifest.json 是 uniapp 工程的"身份证"。第一次打开这套源码，必改三个地方：微信小程序 AppID、权限声明、基础库最低版本。AppID 别用源码里自带的——那可能是作者的测试号，真机预览时会被微信拦截。改 AppID 不像改普通字段那么简单，HBuilderX 重新编译后，微信开发者工具必须重新导入 unpackage 产物，否则工具里还缓存着旧的 AppID。

{ "appid": "wx1234567890abcdef", "setting": { "minified": true, "es6": true, "urlCheck": false }, "mp-weixin": { "appid": "替换成你自己的小程序AppID", "setting": { "urlCheck": false }, "permission": { "scope.userLocation": { "desc": "用于推荐您附近的装修工地" } }, "requiredPrivateInfos": ["getLocation"] } }

urlCheck 这个参数值得单独说。开发阶段把它设成 false，可以跳过域名校验，直接用 IP 加端口访问本地后端接口，省去每次调接口都被拦的烦心事。但上线前必须把它改回 true，并且在小程序后台配置 request 合法域名，否则正式版直接请求失败。很多新手把源码跑通后就忘了改回去，结果上传体验版一切正常，一发布线上版接口全挂，这种翻车我见过太多次了。permission 里的 scope.userLocation 是针对"推荐附近工地"这类功能的，如果这套源码用到了位置接口，微信要求必须在 manifest 里声明用途说明，否则审核会被打回。requiredPrivateInfos 是另一个容易漏掉的地方——微信从基础库 2.21.3 开始要求所有隐私接口都必须在这个数组里声明，漏一个审核就拒一次。

为了让你对这套源码里要改的文件有个整体认知，我从历次交付里总结了一张配置清单，每次开工前过一遍：

2.3 "全开源"不等于零成本：先判断后端在不在、接口通不通

这是亲测源码最容易踩的认知坑。所谓全开源，通常指的是前端 uniapp 工程完整可编译，但后端接口有三种情况：源码自带一套 Node/PHP 后端、只有 Mock 数据、完全没有接口层。拿到代码先搜一下 uni.request 的调用，把所有请求地址汇总，看它们指向的是同一个域名还是分散的 IP。

grep -r "uni.request" pages/ --include="*.vue" | head -20

这条命令能快速列出所有请求调用。如果地址是 http://localhost:3000 或者 http://192.168.x.x 这类内网地址，说明源码作者自己也没部署过正式后端。此时你有两条路：一是自己补一套后端，装修类小程序的核心接口其实不多——案例列表、报价计算、预约提交、验证码登录，四个接口撑起 80% 的业务；二是把这套源码当纯前端模板，接到你现在用的 CRM 或 ERP 系统上。判断标准很简单：你的业务是装修公司自用，还是你要拿这套代码去交付给装企客户。前者建议直接接现有系统，后者才值得从零补后端。这个决策做错了，后面全是白干。

接口字段的约定也要提前对齐。以报价接口为例，前端传给后端的参数一般有 area、houseType、styleLevel，但后端可能期望的是 areaSize、decorationStyle，字段对不上前端就会拿到 undefined。拿到源码后先看每个页面的 data 里变量命名，再对照请求参数，形成一份字段映射表。我通常会直接改前端代码去适配后端字段，因为后端往往已经承载了多处调用，改前端成本最低。

3. 从 HBuilderX 到微信开发者工具：跑通 uniapp 装修小程序的最小闭环

环境搭起来不难，但顺序错了会浪费一晚上。我一般按"导入→改配置→编译→预览"四步走，每一步都看一眼输出，别一口气全做完再排错。编译工具的联动机制关系到你后续每天的工作效率，第一次打通之后，后面就只是点几下鼠标的事。

3.1 导入工程：HBuilderX 打开的三种方式和常见报错

uniapp 工程有两种打开方式：如果拿到的是完整目录，直接 HBuilderX 的"文件→导入→从本地目录导入"，选择项目根目录；如果拿到的是压缩包，先解压再导入，别直接在压缩包界面里拖拽。导入后看控制台输出，重点看有没有"未找到 manifest.json"这类提示——这说明目录选错了，uniapp 工程根目录必须同时包含 manifest.json、pages.json 和 App.vue 三个文件。

另一种常见情况是源码用了 vue3 语法但编译器版本配的是 vue2。在 HBuilderX 里右键项目名，看"使用 Vue 版本"选项。装修类小程序源码大多数基于 vue2 写，因为社区组件多；如果你拿到的是 vue3 版本，注意看代码里是否用了 setup 语法和组合式 API，这两套写法的组件复用方式完全不同。版本选错的表现是页面白屏、控制台报一堆 Unexpected token。

导入完成后别急着运行，先把项目里的 node_modules 确认一下。有些二手源码会把 node_modules 一起打包，体积能到几百兆，这些依赖在你自己电脑上不一定兼容，常见做法是删掉后重新执行 npm install。但要先看工程里有没有 package.json——没有的话说明作者用的是 HBuilderX 内置编译器，不需要 node_modules，你硬装反而会把环境搞乱。这一步属于"看情况处理"的环节，取决于源码作者自己的开发习惯，拿到手先观察再动手。

3.2 编译到微信小程序：manifest 配置和 project.config.json 的联动

在 HBuilderX 工具栏点"运行→运行到小程序模拟器→微信开发者工具"，首次运行会要求你指定微信开发者工具的安装路径。这里有个容易卡壳的点：HBuilderX 是通过命令行调用微信开发者工具的 CLI 端口，微信开发者工具必须先在"设置→安全设置"里打开"服务端口"，否则 HBuilderX 会报"未安装或未启动微信开发者工具"。

编译完成后，HBuilderX 会在工程的 unpackage/dist/dev/mp-weixin 目录生成微信小程序原码。这时用微信开发者工具导入这个目录。有些新人会直接导入整个 uniapp 工程，那是错的——微信开发者工具只能识别编译产物。推荐的方式是在 HBuilderX 里勾选"运行到小程序模拟器时自动打开微信开发者工具"，它会自动完成导入。

project.config.json 里有几个参数影响你后面干活：

改了这些配置后，需要在微信开发者工具里点"编译"才会生效。特别提醒：manifest.json 改了 AppID 之后，HBuilderX 重新编译，但微信开发者工具里如果还开着旧的编译结果，需要关掉项目重新导入，否则你会以为没生效。

3.3 第一个验证点：首页能不能拉到数据

跑通的标准不是页面能打开，而是首页能拉到真实数据。装修类小程序首页一般有三个数据源：案例轮播图、风格推荐列表、装修攻略文章。如果这套源码接的是 Mock 数据，页面能正常渲染，但换到你自己的后端时会出现字段对不上的情况。

打开微信开发者工具的 Network 面板，刷新页面，看请求列表里有没有你预期的接口调用。我一般会重点盯三个时间点：页面 onLoad 时发请求、返回数据后 setData、渲染完成后图片懒加载触发。如果 Network 面板里一个请求都没有，多半是 uni.request 被写在了某个你还没触发的生命周期里；如果请求发出但返回 404，去看后端路由和前端请求路径是否一致；如果返回 200 但页面空白，打开 Console 看有没有 JSON 解析报错。

注意：开发阶段如果遇到所有请求都 pending 或超时，先检查 urlCheck 是否已经设成 false。微信开发者工具的"不校验合法域名"开关在详情→本地设置里，和 manifest 里的 urlCheck 是两套独立配置，都要关掉才行。

这一关过了，整套源码的前端链路就通了。接下来才有资格谈改业务。我见过很多人没跑到数据就开始改代码，最后发现改的字段全错了，白费几天功夫。

4. 改业务模块：报价、预约、案例展示的落地改造

装修小程序的核心业务跑不出三块：报价、预约、案例。源码里这三块大概率是写死的静态数据，你要做的就是把它们从"死数据"改成"活接口"。这三块的改造方法可以互相参考，但各自有各自的边界条件，改之前先把业务规则问清楚——尤其是报价公式，装企之间的算法差异大到你无法想象。

4.1 报价模块：把静态公式改成后端接口

装修报价在小程序里通常是"面积×风格系数×档次系数"，源码里可能直接把几个档位的单价写死在 data 里。改造的第一步是找到这个计算逻辑，把它抽成独立的计算函数，方便后续接接口时替换。

// pages/quote/quote.vue 中的报价计算逻辑 export default { data() { return { area: 0, // 建筑面积，单位平米 styleLevel: 1.2, // 风格系数：现代简约1.0、轻奢1.2、欧式1.4 gradeLevel: 1.0, // 档次系数：经济1.0、舒适1.3、豪华1.8 basePrice: 680 // 基础单价：元/平米 } }, methods: { // 把计算逻辑独立出来，方便后续换成后端计算 calcQuote() { const raw = this.area * this.basePrice * this.styleLevel * this.gradeLevel // 总价向上取整到百位，避免出现 123456.7 这种不美观的数字 return Math.ceil(raw / 100) * 100 }, async fetchRemoteQuote() { const res = await uni.request({ url: '/api/quote/calc', method: 'POST', data: { area: this.area, styleLevel: this.styleLevel, gradeLevel: this.gradeLevel } }) // 后端返回格式统一为 { code: 0, data: { total: 128000 } } if (res.data.code === 0) { this.total = res.data.data.total } } } }

这里有一个容易被忽略的细节：报价结果是给业主看的第一屏关键信息，必须保证在小程序切后台再回来时仍能正确显示。建议把最近一次报价结果缓存到 storage 里，下次打开直接渲染缓存，等接口返回后再覆盖——这比每次冷启动都转菊花强得多。另外，系数类参数不要硬编码在前端，装修公司调整报价策略的频率远高于发版频率，把它们放到后端配置里，改价格不用重新提审小程序。这个改动不大，但能让客户觉得你是真懂装修行业的。

4.2 预约看工地：表单校验和时间段选择的边界

预约模块的技术难点不在表单本身，而在"时间选择"和"防重复提交"。装修工地预约通常是"上午/下午"两个时段，而不是精确到分钟的时间点——因为工长没法承诺分钟级的到达时间。源码里如果用的是 picker 的 date 模式，建议改成两个 picker 联动：先选日期，再选时段，时段用一个单选按钮组更直观。

// 预约表单提交前的校验逻辑 submitAppointment() { // 先校验基础字段，再提交，避免无效请求打到后端 if (!this.form.phone || !/^1[3-9]\d{9}$/.test(this.form.phone)) { uni.showToast({ title: '请填写正确的手机号', icon: 'none' }) return } if (!this.form.date || !this.form.slot) { uni.showToast({ title: '请选择看房时间', icon: 'none' }) return } // 防重复提交：用一个布尔锁，请求期间禁止再次点击 if (this.submitting) return this.submitting = true uni.request({ url: '/api/appointment/create', method: 'POST', data: this.form, success: (res) => { this.submitting = false if (res.data.code === 0) { uni.showToast({ title: '预约成功', icon: 'success' }) } }, fail: () => { this.submitting = false uni.showToast({ title: '网络异常，请重试', icon: 'none' }) } }) }

手机号正则 /^1[3-9]\d{9}$/ 是现在最常用的校验规则，13 到 19 开头、总共 11 位，能挡住大部分误输入。防重复提交的 submitting 锁看起来简单，但很多人会忘：请求发出后没有立刻置 true，用户在弱网环境下连点五六次，后端收到一堆重复预约单。还有一个边界要处理——用户在预约成功后返回上一页再进来，表单应该清空还是保留？我习惯保留表单内容，只清空提交状态，因为业主改日期的概率远高于重新填表的概率。你要是图省事直接清空，用户第二次填表时多半就流失了。

4.3 案例展示：图片懒加载与视频流的 uniapp 适配

装修案例是内容型页面，图片数量多、单张体积大。如果一套源码直接拿 image 标签堆上去，页面会卡到你怀疑人生。uniapp 里做图片懒加载有两种方案：image 标签自带 lazy-load 属性，或者用开源组件。前者简单但只对页面滚动生效，后者可控性更强。对装修案例这种长列表页面来说，lazy-load 已经够用，没必要引入额外依赖。

<template> <view class="case-card" v-for="item in caseList" :key="item.id"> <!-- lazy-load 属性让图片在进入视口前不加载 --> <image class="case-cover" :src="item.coverUrl" mode="aspectFill" lazy-load @click="goDetail(item)" /> <view class="case-title">{{ item.title }}</view> <view class="case-meta">{{ item.area }}㎡ · {{ item.style }}</view> </view> </template>

mode="aspectFill" 这里要解释一下：装修案例封面图通常是设计师出的效果图，比例可能是 4:3 或 16:9，aspectFill 会让图片按短边裁切填满容器，保证卡片视觉统一。如果源码里用的是 scaleToFill，会看到图片被横向拉伸，人像和家具比例失真——这是装修小程序最常见的视觉问题，客户一眼就能看出来。视频类的案例，uniapp 使用 video 组件，需要注意 autoplay 不要开，iOS 下视频自动播放会被系统拦截；还有视频首帧图 poster 要单独给，否则加载视频时会出现黑屏闪烁。

提示：案例列表的接口最好做分页。装修公司的案例库通常按风格、户型、面积三个维度筛选，一次全量拉回几百条数据，微信小程序的 setData 性能会急剧下降。常见做法是页面底部加"上拉加载更多"，每次请求 10 条，接在 onReachBottom 生命周期里触发。

5. 避坑：uniapp 装修小程序从开发到上线的 5 个踩坑记录

这一章写的是我在这类项目里反复踩过的坑，每一条都是"现象→原因→解决"的结构。前四条几乎每个装修小程序都会碰到，第五条看起来小，但最能浪费你的排查时间。

5.1 包体超限：source size 2612kb exceed max limit 2mb

现象：HBuilderX 编译正常，但微信开发者工具上传代码时提示 source size 2612kb exceed max limit 2mb，上传失败。

原因：微信小程序主包限制 2MB，装修小程序超包的头号元凶是案例图片和效果图被当成静态资源直接打包进了代码目录。一张高清效果图 200KB，二十张就 4MB，必超。另一个隐藏杀手是未裁剪的字体文件，部分源码会用 UI 字体做特殊标题，整个字体文件可能 1MB 以上。

解决：第一步，把所有静态图片从 static 目录迁到 CDN 或云端存储，本地只留 tabBar 图标和默认占位图。第二步，检查分包策略，把案例详情、报价结果这类非核心页面放到 subpackages 里，主包只保留 tab 页面和公共组件，一个典型的分包配置如下：

{ "pages": [ { "path": "pages/index/index" } ], "subPackages": [ { "root": "pages/case-detail", "pages": [ { "path": "detail" } ] } ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["pages/case-detail"] } } }

preloadRule 的作用是在用户进入首页时预下载分包，提升案例详情页的打开速度。网络环境设置为 all，意思是 Wi-Fi 和流量都预加载。第三步，压缩项目里的字体文件，或者改用系统字体栈。做完这三步，主包通常能压到 1.5MB 以内。HBuilderX 里运行时有包体分析视图，逐个看每个文件的体积，不要凭感觉猜。

5.2 微信小程序登录获取手机号：getPhoneNumber 的兼容差异

现象：真机上点击"微信一键登录"没有反应，或者回调里拿到的 iv 和 encryptedData 解不开。开发工具里一切正常，一到 iPhone 上就翻车。

原因：新版微信小程序已经用 getPhoneNumber 配合动态令牌换取手机号，旧版源码里的解密逻辑大多基于过时的 session_key 方式。从基础库 2.21.2 开始，微信强烈推荐使用 code 换手机号的方式，也就是 button 的 open-type 设置为 getPhoneNumber，在回调里拿到 code 后发给后端，由后端调用接口换号，前端不再持有解密密钥。

解决：把源码里的手机号解密逻辑改掉。前端只做两件事——放一个按钮，拿到 code 后传给后端；后端拿 code 调用微信接口换手机号。按钮写法如下：

<button open-type="getPhoneNumber" @getphonenumber="handlePhoneNumber"> 微信一键登录 </button>

handlePhoneNumber(e) { if (e.detail.code) { uni.request({ url: '/api/auth/phone', method: 'POST', data: { code: e.detail.code }, success: (res) => { // 后端返回手机号后，存 storage 并刷新登录态 uni.setStorageSync('userInfo', res.data.data) } }) } }

这样前端不再关心 session_key 和 iv，兼容性问题一次性解决。注意：个人主体的小程序没有这个接口权限，只有企业主体才能获取用户手机号，这是个硬性门槛。接私活前先确认客户的主体类型，不然功能做完了上不了线。

5.3 顶部导航栏高度：不同机型的安全区适配

现象：页面顶部内容被刘海屏或胶囊按钮遮挡，标题栏和自定义导航栏在 iPhone 15 上看起来歪了，在安卓机上又太低。

原因：微信小程序的导航栏高度不是一个固定值。iPhone 有刘海屏、灵动岛，安卓有各种状态栏高度差异。源码如果只适配了 iPhone X，放到新机型上就会偏移。自定义导航栏的开发者尤其受影响——你想做沉浸式导航，就得自己算状态栏高度。

解决：用 uni.getSystemInfoSync() 拿 statusBarHeight，然后按平台区分处理。在 App.vue 的 onLaunch 里把这个值缓存到全局变量，所有自定义导航栏的页面统一读取。同时，小程序右上角的胶囊按钮是微信自己渲染的，它的位置你改不了，所以自定义按钮别往右边挤。我见过最省心的做法是：非核心页面直接用微信原生导航栏，只有首页才做自定义沉浸式，风险范围最小。导航栏做深色还是浅色，也要提前跟客户确认好，这直接关系到效果图场景下的整体观感。

5.4 后台运行监测定位：权限声明和隐私协议必须对上

现象：小程序审核被拒，理由涉及"位置信息"相关功能。或者 App 端后台定位被系统弹窗拦截。

原因：装修类小程序的"附近工地"功能需要获取位置，uniapp 在 App 端用的是 plus.geolocation.watchposition 配合 uni.startLocation 这类后台定位能力。微信平台要求必须在 manifest 里声明权限用途，同时在小程序后台配置隐私保护指引。很多人只写了代码，忘了声明，审核就直接打回。这类问题属于典型的"代码是好的，但缺了合规配置"。

解决：第一，manifest.json 的 requiredPrivateInfos 里必须列出用到的每一个 API，比如 getLocation。第二，小程序后台的"隐私协议"里，把采集位置的目的写清楚，推荐话术是"用于推荐离您最近的装修工地"。第三，如果只是推荐列表用，不要用 watchposition 做后台持续监测，用 uni.getLocation 单次获取就够了，后台持续定位会显著增加被拒概率和耗电。这个功能做不做、做到什么程度，在接需求的时候就要和客户确认清楚。很多项目做到一半，客户说"我其实只要用户手动选城市就行"，那前面所有定位代码都是白写。

5.5 uniapp 不打印日志信息：Console 面板一片空白

现象：代码里写了一大堆 console.log，但微信开发者工具的控制台什么都没有，完全无法定位问题，这种日志"黑匣子"状态最让人抓狂。

原因：这套源码在发布模式里集成了日志过滤逻辑，或者代码里用了 uniapp 的条件编译注释把 console 语句在编译时删掉了。另一种可能：写的 console.log 在非当前页面组件的生命周期里，页面已经 onUnload，输出被工具缓冲掉了。日志不输出是所有排查问题里最玄学的——你以为是代码逻辑问题，翻半天才发现是日志被吞了。

解决：先确认是不是条件编译的问题——全文搜索"console"看有没有 #ifdef 或 #ifndef 这类注释包着。如果有，开发阶段直接删掉或注释掉条件编译标记：

// #ifndef 正式环境 console.log('请求参数', params) // #endif

把条件编译注释删掉后，日志立刻恢复。如果没有条件编译，在 App.vue 的 onLaunch 里写一个最简 console.log，看会不会输出。如果这里都没有，那就检查 HBuilderX 的运行模式是不是"发行"模式，发行模式默认过滤日志，改成"运行"模式即可。这个问题通常卡人十分钟以内，但它最容易和"代码写错"搞混，导致你在错误的文件里翻半天。经验是：遇到异常先确认日志通路是通的，再开始排查逻辑。

6. 进阶：从"能跑"到"能交付"的验证清单，少一步都别上线

我给自己定了个规矩：任何 uniapp 小程序，改完代码到交付之间，必须按这份清单完整跑一遍，缺一项都不发版。

第一项，换新 AppID 全量回归。把 manifest.json 里的 appid 换成客户的小程序账号，从 HBuilderX 重新编译，再用微信开发者工具导入，登录、报价、预约、案例四个主流程各点一遍。很多人开发时用自己的测试号，一切正常，换到客户账号后因为类目不同、权限没开，功能直接瘫痪——这不是代码问题，是配置问题，但客户只会觉得你交付的东西是坏的。这个问题属于"后悔药"级别，发布前发现只要十分钟，发布后就要等审核重新排队。

第二项，检查合法域名和隐私接口。在微信公众平台后台把 request 合法域名配全，注意协议必须是 https，端口号不能带。再把隐私保护指引里声明的接口和代码里实际用到的对一遍，多声明没关系，少声明必被拒。这一步每个小程序都要做一次，做完就记进自己的交付文档里，下次直接抄自己的模板，别每次都从头想。

第三项，体验版回归和机型清单。把代码上传为体验版，在自己的手机上走一遍完整流程；再借一台 iPhone 和一台低端安卓机各跑一次。装修小程序的主要用户年龄偏大、设备偏旧，低端安卓机上页面渲染慢、图片加载卡，你在开发工具里根本感受不到。一个实用技巧：在 App.vue 里根据机型做导航栏的降级处理，标题过长时用 uni.setNavigationBarTitle 动态换成短标题，避免截断成省略号。

第四项，真机清后台重进。小程序切后台十分钟再打开，看页面状态是否保留、接口是否重新请求。装修场景下用户经常是看一半去接电话，回来自动续上的体验远比重新加载重要。这个动作在开发工具里模拟不出来，必须真机验证。

最后一项，发版后盯第一小时日志。发布后别急着收工，把微信后台的"实时日志"打开，看有没有接口报错和 JS 异常。我第一次交付时，上线一小时后客户反馈案例视频黑屏，查下来是视频 CDN 的防盗链没加白名单——这种问题如果不盯日志，要等到用户主动投诉才知道。现在我把这个习惯固化成流程，每次发版后设个闹钟，一小时后看日志再收工。

这些坑，每一行都来自真实的交付过程。跑通源码只是开始，能稳定交付才是这套 uniapp 装修小程序真正的价值所在。希望这些经验能帮你在自己的项目里少走几步弯路。

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