简介深蓝装修小程序是一套面向家居装修行业的全栈开发实战资源适用于前端、后端及全栈初学者与中级开发者解决装修服务线上化、用户端轻量化交互与企业端流程数字化等实际业务问题。压缩包共含若干源码文件具体总数未提供主体为微信小程序前端代码WXML/WXSS/JS、后端服务接口逻辑可能基于Node.js或Spring Boot、数据库设计说明及API文档整体体积仅2.55MB轻量易读便于快速部署与二次开发。已有315人学习下载反映出其在垂直行业小程序开发中的实用热度。读者可直接获取完整前后端协同架构方案涵盖用户认证JWT实现、装修案例展示、服务预约、订单管理等核心模块同时包含云服务集成思路与响应式UI实践是理解装修类小程序从需求到上线全流程的优质参考样本。 “深蓝装修小程序前端后端”这个项目我完整跟完了一整套从需求梳理、数据库设计到小程序前端落地、后端接口开发再到最后部署上线前后大概花了两周半时间。趁热把整个过程中的技术选型、业务拆解、模块实现和踩过的坑整理出来给正在做装修类小程序或者准备做前后端分离项目实战的朋友一个可以直接参考的范本。本文会侧重讲“为什么这么做”而不是只贴代码。1. 业务梳理与整体技术方案1.1 装修小程序到底要做什么第一个要搞清楚的问题不是“用什么技术”而是“做给谁用、解决什么问题”。装修行业的线下痛点非常具体获客渠道分散、设计师和工长之间信息不同步、业主无法实时了解工地进度、报价不透明容易扯皮。深蓝装修小程序的定位很明确——做装修公司自己的线上服务入口把“获客—预约—量房—报价—施工—验收”这条业务链搬一部分到微信生态里。所以小程序拆成几个核心功能域用户端装修案例浏览、风格测试、预约量房、查看装修进度、在线咨询。员工端设计师/工长登录后查看分配给自己的任务、上传工地进度照片、维护材料清单。管理端管理员看数据看板、分配线索、管理案例内容。这个定位直接影响技术方案的设计。它不是电商类小程序没有复杂的订单支付闭环但多了进度状态流转、多角色权限这些装修行业特有的业务逻辑。如果一开始不把这个理清楚很容易把项目做成一个“看起来什么都有、但业务上什么都落不了地”的通用模板。1.2 前端技术选型原生小程序还是跨端框架前端选型是很多人拿到需求后的第一轮纠结。微信小程序端的开发方式目前主流有三条路微信原生小程序、uni-app、Taro。我们最终选了微信原生小程序理由很简单项目只做微信端没有多端发布需求uni-app和Taro的跨端能力用不上反而引入一层编译转换成本。装修行业业务偏展示和流程不涉及特别复杂的高性能交互原生小程序的性能完全够。招聘和协作成本低原生小程序的开发资料最多出问题最好排查。不过用原生小程序有一个地方要有个心理准备组件化和状态管理都需要自己规范。我们参照vue的思考方式用behavior抽公共逻辑用app.globalData 缓存来做全局状态细节后面在“前端实现”部分展开。1.3 后端技术选型为什么用Spring Boot而不是Node.js后端我们选了Spring Boot 2.7 MyBatis-Plus MySQL 8.0 Redis这是当前小团队做业务系统比较成熟的一套组合。不是Node.js不好而是装修业务的特点是“状态多、权限细、事务重”Spring Boot这种强类型、强事务的生态处理起来更顺手。具体搭配Spring Boot 2.7稳定资料多JDK8环境下运行非常成熟。MyBatis-Plus单表CRUD几乎不用写SQL业务复杂了再写自定义XML效率很高。MySQL 8.0存储业务数据和案例内容。Redis做验证码缓存、Token黑名单、热点数据的缓存。带我的前辈说过一句话很有道理选型不一定要选最流行的而要选团队里“修得了Bug”的。如果团队对Node.js更熟那用Node.js也完全没问题。关键是这套东西团队要能长期维护下去。1.4 前后端分离的接口约定前后端分离项目实战里最怕的就是“接口格式各写各的”。开发之前我们就用文档把接口规范约束死统一返回结构{ code: 0, message: success, data: {} }code0表示成功非0是各种业务错误码。所有接口使用/api/前缀。分页参数统一为page、pageSize返回体统一为{ list, total }。时间统一用时间戳或yyyy-MM-dd HH:mm:ss字符串不混用。这套约定看起来简单但能省掉联调阶段大量“你这返回的字段怎么不一样”的扯皮。前端封装一个request.js统一处理code判定和异常提示后端封装一个Result类所有接口都返回这个结构。2. 前端实现小程序端的关键模块与踩坑记录2.1 项目目录结构与分包设计深蓝装修小程序的代码结构直接影响后续维护体验。我们最终形成了一套模块化的组织方式├── miniprogram/ │ ├── pages/ # 主包页面 │ │ ├── index/ # 首页 │ │ ├── cases/ # 案例列表 │ │ ├── case-detail/# 案例详情 │ │ ├── user/ # 个人中心 │ │ └── ... │ ├── package-renovation/ # 装修业务分包 │ │ ├── style-test/ # 风格测试 │ │ ├── appoint/ # 预约量房 │ │ ├── progress/ # 装修进度 │ │ └── ... │ ├── components/ # 公共组件 │ ├── utils/ # 工具函数、请求封装 │ ├── behaviors/ # 公共行为 │ └── app.js选择分包的原因很简单小程序主包体积限制是2MB而我们用了一套偏设计感的装修案例图片和自定义组件代码和静态资源很容易超。把预约、进度查询这些低频业务放到分包里可以让首屏加载轻很多。这里有个知识点值得说一说分包异步化。如果我们只是把分包里的页面入口放到分包中主包和分包之间的组件互通是有一定限制的。我们做的时候用了require.async这类方式来动态加载分包中的公共模块。如果你选的是简单场景把分包当独立的页面集合用即可不必一上来就上分包异步化。2.2 首页装修风格推荐与单选框交互首页的核心模块是“风格测试”——用户选几个偏好系统推荐装修风格。这里涉及一个很常见的微信小程序表单交互单选。微信小程序原生的radio-groupradio用起来其实手感一般因为默认样式不好调整而且不同机型渲染差异大。我们没有直接用原生标签而是自己封装了一个“卡片式选择器”view classstyle-options view wx:for{{styles}} wx:keyid classstyle-card {{selectedStyleId item.id ? active : }} bindtaponSelectStyle >const getNavBarHeight () { const systemInfo wx.getWindowInfo(); const menuButton wx.getMenuButtonBoundingClientRect(); const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height; return { statusBarHeight: systemInfo.statusBarHeight, navBarHeight }; };这个公式的意思是胶囊按钮到状态栏顶部的距离乘以2加上胶囊本身高度就是导航栏的总高度。android和iOS用同一套算法就能适配。当时开发同事第一次写的时候直接写死了一个高度结果在iPhone 14 Pro Max和安卓全面屏机型上胶囊按钮直接和自定义标题重叠了最后就是用上面的方案解决的。2.5 请求封装与登录态管理前端所有请求走一个封装好的request.js。核心要点有三个const request (url, method, data, options {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success: (res) { if (res.data.code 0) { resolve(res.data.data); } else if (res.data.code 401) { // token失效重新登录 handleTokenExpired(); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail: (err) reject(err) }); }); };登录态我们采用的是微信wx.login获取code然后传给后端换取自定义token。这个流程和传统的session方案不一样不用在服务端保存会话token无状态适合小程序这种弱会话场景。Token失效处理有个容易忽略的点如果页面同时发了三个请求401会被触发三次导致登录弹窗出现三遍。解决办法是加一个“是否正在刷新token”的标志位在刷新期间把后续请求先缓存起来等token刷新完再统一重放。3. 后端实现接口设计与核心业务逻辑3.1 微信登录接口设计与多角色权限模型后端第一个核心接口是/api/auth/login。前端传来微信code后端拿code去微信接口换取openid和session_key然后做三件事查用户是否存在、不存在则自动注册、生成token返回前端。权限模型这里值得展开讲。装修公司内部有设计师、工长、销售三种角色加上业主一共四类人。我们的设计方式是用户表userid、openid、nickname、avatar、role、phone、status。角色用数字区分1-业主 2-销售 3-设计师 4-工长。接口权限通过Spring Boot拦截器实现在HandlerInterceptor里解析token拿到用户角色后校验接口要求的角色数组。拦截器里有个关键点微信小程序的openid属于敏感信息token里不直接存openid而是存userId后端再从Redis或数据库里查角色信息。这样即使token泄露也不会直接暴露微信身份。3.2 预约量房与线索分配的业务闭环预约量房是装修行业小程序的黄金转化入口。我们的接口设计是POST /api/appointment/submit 参数name, phone, address, communityId, houseArea, appointTime, remark后端拿到数据后校验手机号格式校验预约时间不能是过去时间。写入appointment表状态置为PENDING。通过一个简单的分配规则找到当前负荷最小的销售/量房专员将线索分配给TA。触发一条通知内部用WebSocket推送到管理后台或者通过订阅消息发给员工。这里想提醒一个问题不要在接口里直接做耗时操作。如果分配线索后还需要调用第三方短信接口建议用Spring的Async异步处理防止接口响应时间过长。我们的实际经验是对外接口响应超过2秒小程序的体验就会明显下降。3.3 装修进度状态机设计装修进度是整个业务里最体现行业特色的模块。它的核心是状态流转而不是简单的增删改查。我们把装修过程抽象成一条状态链预约量房 - 方案设计 - 合同签订 - 开工准备 - 水电施工 - 泥瓦工程 - 木工油漆 - 竣工验收每个节点有对应的图片上传要求、质检项、施工人员。后端给前端提供一个状态查询接口同时提供POST /api/progress/update接口工长或设计师可以更新当前节点状态、上传现场照片。状态机这里有一个非常实际的坑状态不能跳变。比如施工中不能直接变成“已完工”必须经过“验收中”。我们在后端做了严格校验更新状态时比对当前状态和目标状态是否相邻。这个逻辑看起来死板但能避免很多施工纠纷——比如验收没过但系统里已经变成完工之后扯皮就说不清了。3.4 文件上传与图片管理装修项目里有大量图片案例图、工地进度照片、户型图。小程序的图片上传走wx.uploadFile后端接的是Spring Boot的文件上传接口。我们的存储方案是用阿里云OSS但做了两层封装前端先请求/api/upload/policy获取上传凭证OSS的STS临时凭证或签名URL。拿到凭证后直传OSS不回源到应用服务器。这样做的原因是应用服务器的带宽和磁盘都很贵图片直接打到应用服务再转发一是慢二是占用大量内存。直传OSS之后应用服务器只负责保存图片URL图片预览走CDN加速。有个细节图片上传后不要直接信任前端传入的URL后端应该校验URL的域名是不是自己的OSS域名防止有人通过接口伪造图片地址塞垃圾数据。3.5 前后端分离中的跨域问题做前后端分离项目实战时“跨域”是绕不开的话题。小程序前端的跨域情况比较特殊微信小程序的wx.request不受浏览器同源策略限制因为压根没有浏览器环境。但我们开发调试的时候经常用Chrome开发者工具的移动模拟器来预览这时候就会遇到跨域问题。我们的后端统一配置了CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }一个小建议线上环境不要把allowedOriginPatterns配置成*应该限定为公司自己的管理后台域名。开发环境宽一点无所谓生产环境安全第一。4. 前后端联调、部署与线上环境配置4.1 本地联调技巧局域网真机调试小程序开发最实用的一套本地联调方案是后端跑在本地电脑小程序开发者工具里把BASE_URL配成局域网IP地址。const BASE_URL http://192.168.1.100:8080/api;这里会碰到一个常见问题真机预览时手机访问不到电脑的局域网IP。排查方向有三个手机和电脑连的是不是同一个WiFi很多人栽在这里。电脑防火墙是否拦截了8080端口。后端服务绑定的地址是不是0.0.0.0如果绑定127.0.0.1局域网是访问不到的。Spring Boot默认端口可以启动时指定java -jar app.jar --server.address0.0.0.0 --server.port8080。4.2 Docker部署前后端线上部署我们用的是Docker Compose把MySQL、Redis、后端服务、前端Nginx全部编排在一起。下面是一个精简版的docker-compose.ymlversion: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: shenlan volumes: - ./data/mysql:/var/lib/mysql ports: - 3306:3306 redis: image: redis:7.0 ports: - 6379:6379 backend: build: ./backend depends_on: - mysql - redis environment: SPRING_PROFILES_ACTIVE: prod ports: - 8080:8080 frontend: image: nginx:alpine volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf - ./frontend/dist:/usr/share/nginx/html ports: - 80:80后端容器化有一个要注意的点数据库地址不能写成localhost要写服务名mysqlDocker Compose内部会做DNS解析。4.3 Nginx配置Vue前端与后端如果你的管理后台是Vue写的那Nginx的配置就要考虑“前端路由history模式和API反向代理”。server { listen 80; server_name admin.shenlan.com; root /usr/share/nginx/html; index index.html; # Vue history 路由重写 location / { try_files $uri $uri/ /index.html; } # 后端接口代理 location /api/ { proxy_pass http://backend:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html;这一行的意思是如果请求的资源不存在就把请求转给index.html由前端的Vue Router接管路由。少了这行Vue的history模式在页面刷新时会出现404。4.4 域名、HTTPS与小程序合法域名配置小程序正式版有个硬性要求所有请求的域名必须是HTTPS并且在小程序后台配置为合法域名。这一步不走完小程序根本没法在正式环境里正常请求数据。申请HTTPS证书的流程很简单各大云服务商都有免费证书一年一换。Nginx配置证书的片段server { listen 443 ssl; server_name api.shenlan.com; ssl_certificate /etc/nginx/cert/api.shenlan.com.pem; ssl_certificate_key /etc/nginx/cert/api.shenlan.com.key; location / { proxy_pass http://backend:8080; } }配置完成后去小程序后台添加request合法域名和uploadFile合法域名前者填https://api.shenlan.com后者填OSS的域名。5. 高频问题速查与实战避坑5.1 微信小程序审核相关问题装修类小程序审核时最容易遇到的一个问题是类目不符。如果小程序里涉及“播放、观看”类内容审核会要求补充“文娱-其他视频类目”而这个类目需要相关资质。我们的案例详情页里有装修过程视频就遇到了这个问题。解决办法是在后台提前选择正确的类目或者把视频功能去掉改成图片轮播 文字描述。对于装修公司来说纯图片展示其实转化效果也不差不要为了一个视频功能卡审核耽误上线。5.2 安卓/iOS兼容性差异小程序在不同端的表现会有差异我们实际踩过的两个问题安卓端wx.getSystemInfoSync()在新版基础库已经废弃要改用wx.getWindowInfo()。老接口在部分安卓机型上返回的statusBarHeight为0导致页面顶上去一块。iOS端new Date(2026-01-01 10:00:00)解析会失败因为iOS不支持带横杠的时间字符串。统一用2026/01/01 10:00:00格式或者时间戳才能保证两端一致。兼容性问题的排查思路很简单多在真机上测别只依赖开发者工具的模拟器。5.3 前后端协作的常见问题排查联调阶段最容易出现“前端无法获取数据”的问题。我们的排查顺序一般是打开开发者工具的Network面板看请求是否发出。看请求的URL是否正确是否有拼写错误。看请求是否被拦截状态码403、404、500各是什么原因。看后端日志确认接口是否被调用到。后端点一下接口测试工具确认接口本身没问题。这里推荐一个效率工具后端开发时用knife4jSwagger增强版直接调试接口前端等接口文档的同时后端可以把接口自测到基本可用再交付减少来回沟通成本。5.4 首屏性能优化建议装修案例的图片普遍比较大首屏加载如果全是高清原图用户等待时间会很长。我们的优化方式图片走CDN并开启OSS的图片处理参数动态生成缩略图。比如原图URL后面加?x-oss-processimage/resize,w_400请求时自动裁剪成400px宽度。首页只请求首屏数据其余内容在上拉加载时再拉取。onReachBottom触底加载时加一个loadingMore锁防止重复请求。最后分享一个项目管理层面的经验小程序前后端分离项目最怕的不是技术难点而是“前端不知道后端返回什么、后端不知道前端需要什么”。我们项目的做法是第一天就把接口文档Swagger/Knife4j跑起来前后端并行开发每完成一个模块就同步一下。这个习惯看起来无所谓实际联调的时候省掉了我至少一半的沟通时间。如果你也在做类似的全栈项目建议把这个流程前置。本文还有配套的精品资源点击获取