简介：一款参照米家APP布局与样式开发的智能家居微信小程序源码包，面向学习微信小程序、物联网前端以及智能家居UI设计的开发者。项目覆盖微信小程序完整技术链路：WXML/WXSS结构样式、JavaScript业务逻辑，以及wx.request、WebSocket等API交互；同时涉及MQTT/CoAP等物联网通信协议、本地缓存与云端数据库、权限管理和CSS3动画等知识点，适合作为从零搭建智能家居控制端的练手项目。压缩包为ZIP格式，大小2.67MB，内含项目文件及配置信息，具体文件清单需解压查看。资源发布后已有668人学习，对希望在移动端复刻米家风格交互、理解设备状态同步与事件监听机制的读者具有明确参考价值。
1. 从米家到智能家居微信小程序：复刻布局之前先复刻信息密度
大多数团队拿到"参照米家APP写一套智能家居小程序"这类需求，第一反应是找一张米家首页截图，然后把色值、圆角、图标抄一遍。这个做法方向对，但漏掉了最关键的一层：米家真正让人"用着顺手"的点不在单个像素，而在信息密度的层级控制。它把设备状态、房间维度、快捷操作三种信息通过统一的卡片语言压进同一屏,用户不需要思考就能找到入口。
这也是本文要拆的问题：当手里只有一份"smart-home-master.zip"这类工程模板时，如何从布局坐标系、组件状态、数据流三个层面把米家的"顺手感"复刻出来，而不是只抄个皮。下面按"设计基线 → 首页搭建 → 控制面板与状态同步 → 加载性能"这条线推进，中间穿插可落地的微信小程序代码和参数说明，适合已经能跑通基础小程序、但想把界面和数据交互做扎实的开发者在现有工程里直接改造。
2. 布局坐标系：用 Flex 与间距规范搭出米家式首页骨架
2.1 米家首页的视觉层级拆解：灰白底、卡片块、纵向节奏
米家首页看着"干净"，核心不是白色用得多，而是同一层级的视觉元素重量完全一致。设备卡片统一圆角(约16rpx到24rpx)、统一阴影(通常用#E0E0E0左右的浅投影)、统一内边距(约24rpx到32rpx)。在同一视觉重量下，眼睛会自然按"从左到右、从上到下"的Z字形扫视，这就是布局的底层逻辑。
微信小程序里实现这套体系的成本很低：Flex 布局天然适合卡片流，加上rpx单位做等比例缩放，就能在不同屏幕宽度下保持比例一致。相比 H5 的vw/vh，rpx在微信里按 750 设计稿宽度换算，正好对应米家这类以 iPhone 宽度为基准的设计稿。
2.2 用 Flex 网格排布房间与常用设备入口
首页顶部通常会放"房间切换"和"常用设备"两个横向区域。房间切换用横向滚动，常用设备用 4 列网格。这里的核心参数是flex-wrap: wrap与justify-content: space-between。space-between 在最后一行不满 4 个时会出现"向左靠齐"的问题，所以更稳的做法是给每个卡片一个固定比例宽度，例如width: 23%，并允许margin-right留出间隙。
<!-- pages/home/index.wxml --> <view class="device-grid"> <block wx:for="{{deviceList}}" wx:key="id"> <view class="device-card {{item.status === 'online' ? 'device-card--online' : 'device-card--offline'}}" bindtap="handleDeviceTap">/* pages/home/index.wxss */ .device-grid { display: flex; flex-wrap: wrap; margin: 24rpx 0; } .device-card { width: 23%; margin: 0 1% 20rpx 1%; background: #F9F9F9; border-radius: 20rpx; padding: 24rpx 0; display: flex; flex-direction: column; align-items: center; transition: transform 0.2s ease; } .device-card--online { background: #FFFFFF; box-shadow: 0 4rpx 12rpx rgba(0, 0, 0, 0.04); } .device-card--offline { opacity: 0.5; }这里width: 23%是为了在 4 列布局下留出 1% 的左右间隙，加上外层容器的padding，最终呈现的间距约等于设计稿的 20rpx。bindtap绑定设备点击事件，><scroll-view scroll-x enhanced show-scrollbar="{{false}}" style="white-space: nowrap;"> <view class="scene-list"> <view class="scene-item" wx:for="{{sceneList}}" wx:key="sceneId" bindtap="handleSceneTap"> <text class="scene-item__name">{{item.sceneName}}</text> <text class="scene-item__desc">{{item.tip}}</text> </view> </view> </scroll-view>
enhanced属性是微信基础库 2.11.0 之后的特性，它允许在 iOS 上使用原生滚动，减少白屏卡顿。show-scrollbar="{{false}}"用来隐藏滚动条，视觉上更接近米家"无痕横向滑动"的手感。注意：如果 scoll-view 内部要放image组件，建议给图片显式设置width高度，否则图片加载前横向滚动长度会计算不准。
3. 组件状态与数据流：让设备卡片拥有"在线/离线/控制中"三种状态
3.1 设备状态机的数据设计，而不是一堆布尔变量
很多小程序写着写着，设备状态就变成isOnline: true、isLocked: false这样的平铺布尔值。设备一多，判断逻辑散落在模板和事件处理函数里，加一个新状态要改七八处。
参照米家的交互，一个设备卡片至少要表达：在线、离线、控制中(指令下发后等待回执)。用一个status字段统一管理，模板里只根据 status 渲染样式，逻辑里只通过changeDeviceStatus方法改变状态值。
// pages/home/index.js Page({ data: { deviceList: [ { id: 'ac-001', name: '客厅空调', status: 'online', icon: '/assets/ac.png' }, { id: 'light-002', name: '卧室灯', status: 'offline', icon: '/assets/light.png' }, { id: 'tv-003', name: '电视', status: 'online', icon: '/assets/tv.png' }, ], }, handleDeviceTap(e) { const deviceId = e.currentTarget.dataset.id; const targetDevice = this.data.deviceList.find(item => item.id === deviceId); if (targetDevice && targetDevice.status === 'offline') { wx.showToast({ title: '设备离线，请检查网络', icon: 'none' }); return; } // 跳转设备详情或控制面板 wx.navigateTo({ url: `/pages/device/control?deviceId=${deviceId}` }); }, });find方法在数据量小(家庭场景一般不会超过几十个设备)时性能足够，不需要额外引入key索引。wx.showToast的icon: 'none'是纯文本提示，避免离线时弹一个红色错误图标给用户造成"系统崩了"的错觉。
3.2 wx:if 与 hidden 的选择：渲染开销和状态切换频率
设备列表里每个卡片有在线/离线两种表现，有人直接用wx:if动态切换。wx:if会真正销毁和重建节点，频繁切换时会产生布局抖动。对于状态切换频率较高的设备(例如插座、灯)，用hidden属性更好，它只是切换display: none，节点保留在渲染树里。
但在"首次加载页面"的场景下，wx:if反而能减少无效渲染。一个折中方案是：列表首屏用wx:if判断是否有数据，卡片内部的状态切换用hidden或纯 class 切换。这个思路对应到代码里就是外层wx:if="{{deviceList.length > 0}}"，内层卡片样式通过device-card--online这样的 class 切换。
3.2.1 控制指令下发与本地状态乐观更新
米家的控制体验是"点了立刻有反应"。但这个反应不是真实设备状态，而是前端把界面先切到目标状态，等设备回执后再校正。这种模式叫乐观更新(Optimistic Update)，在智能家居小程序里几乎是必备手段。
toggleDevice(e) { const { id, targetState } = e.currentTarget.dataset; // 1. 本地状态先行 this.setData({ [`deviceList[${this.getDeviceIndex(id)}].status`]: 'controlling', }); // 2. 发送指令到后端/硬件网关 wx.request({ url: 'https://api.example.com/device/control', method: 'POST', data: { deviceId: id, targetState }, success: (res) => { if (res.data.success) { this.updateDeviceStatus(id, 'online'); } else { this.updateDeviceStatus(id, 'offline'); wx.showToast({ title: '控制失败', icon: 'none' }); } }, fail: () => { this.updateDeviceStatus(id, 'offline'); }, }); }setData里使用deviceList[${index}].status这种路径写法时，路径字符串会由微信自己解析，不要自己拼数组再整体赋值，那样会触发整个列表重渲染。如果设备数量超过 20 个，建议给每个设备独立设置一个setData路径，而不是deviceList整体替换。这个方案在硬件回执慢的场景下很管用，但要注意加一个超时兜底，比如 8 秒后如果还没收到回执，强制把状态改回"离线"。
3.3 房间与设备分组的 tab 切换
米家APP底部的"设备"和"场景"两个标签页，本质是同一份设备数据的不同聚合维度。小程序里实现起来有两种路径：一种是用微信原生的swiper+scroll-view，另一种是tabBar页面。米家的设备列表通常是顶部一个横向 tab 切房间，这用自定义组件或页面内scroll-view实现更灵活。
<view class="room-tabs"> <scroll-view scroll-x enhanced show-scrollbar="{{false}}"> <view class="room-tab {{currentRoom === item.name ? 'room-tab--active' : ''}}" wx:for="{{roomList}}" wx:key="name" bindtap="switchRoom">// pages/device/control.js Page({ onLoad(options) { this.deviceId = options.deviceId; const deviceInfo = this.findDeviceById(this.deviceId); this.setData({ device: deviceInfo, brightness: deviceInfo.brightness || 70, }); }, findDeviceById(id) { const globalDevices = getApp().globalData.deviceList || []; return globalDevices.find(item => item.id === id) || {}; }, });findDeviceById是同步查找，前提是globalData.deviceList已经在启动时加载完毕。如果控制面板页可能被分享给其他人打开，这里要加一个"查不到就重新拉取"的兜底逻辑，否则分享场景下页面会白屏。
4.2 slider 亮度/温度调节与节流控制
米家的灯光和空调面板都有滑杆调节，微信小程序用slider组件实现。slider的bindchanging事件在手指滑动时高频触发，如果每次触发都发请求到后端，网关和硬件都受不了。常规做法是changing时只更新本地 UI，change(松手)时才发控制指令。
<slider min="0" max="100" step="1" value="{{brightness}}" activeColor="#007AFF" block-size="24" bindchanging="onBrightnessChanging" bindchange="onBrightnessChange" />onBrightnessChanging(e) { this.setData({ brightness: e.detail.value }); }, onBrightnessChange(e) { const brightness = e.detail.value; wx.request({ url: 'https://api.example.com/device/brightness', method: 'POST', data: { deviceId: this.deviceId, brightness }, }); },block-size决定滑杆圆点的大小，米家用的是偏大的圆点(约 28rpx)，因为手指操作需要足够大的触摸面积。step="1"是精度控制，灯光亮度用 1% 的步进足够，温度调节通常用 0.5 或 1 的步进。
4.3 状态回显：WebSocket 还是定时轮询？
4.3.1 两者的取舍
家庭局域网内的设备状态变化，通常来自两个方向：用户主动控制、设备自身状态变化(比如空调达到设定温度后压缩机停机)。后者不会主动通知前端，所以需要一种推送机制。
局域网环境下，首选 WebSocket 连接网关或设备固件。但如果网关不支持 WebSocket，退而求其次用setInterval定时轮询。轮询间隔推荐 3 到 5 秒，太短会加大网关压力，太长则状态刷新有明显延迟。
4.3.2 轮询代码的注意事项
startPolling(deviceId) { this.pollTimer = setInterval(() => { wx.request({ url: `https://api.example.com/device/state?deviceId=${deviceId}`, success: (res) => { if (res.data.state !== this.data.device.status) { this.setData({ 'device.status': res.data.state, }); } }, }); }, 3000); }, onUnload() { if (this.pollTimer) { clearInterval(this.pollTimer); } },onUnload里必须清理定时器。小程序页面栈不销毁，定时器就会一直挂在后台，消耗电量且产生无意义的请求。加一个if (this.pollTimer)是为了避免极端情况下clearInterval传入了undefined导致报错。
5. 上线前用骨架屏与微信小程序分包把首屏载荷压下去
5.1 开发版与真机的感官差异在于骨架屏
开发工具里页面几乎秒开，真机上却经常白屏 1 到 2 秒。原因无非是首页 WXML 节点多、图片资源大、网络慢。米家的做法是骨架屏：在数据加载完成前，先用灰色色块按最终布局占位，让用户感觉页面"结构已经出来了"。
微信小程序实现骨架屏有两个主流路径：一是手写wx:if控制灰色占位块，二是使用第三方组件。手写方式对老工程侵入最小。
<view class="skeleton" wx:if="{{loading}}"> <view class="skeleton__room-bar"></view> <view class="skeleton__grid"> <view class="skeleton__card" wx:for="{{[1, 2, 3, 4]}}" wx:key="*this"></view> </view> </view> <view class="device-grid" wx:else> <!-- 正常设备列表 --> </view>.skeleton__card { width: 23%; height: 200rpx; margin: 0 1% 20rpx 1%; border-radius: 20rpx; background: linear-gradient(90deg, #f0f0f0 25%, #e8e8e8 37%, #f0f0f0 63%); background-size: 400% 100%; animation: skeleton-loading 1.4s ease infinite; } @keyframes skeleton-loading { 0% { background-position: 100% 50%; } 100% { background-position: 0 50%; } }wx:key="*this"用于循环渲染纯数字数组时的 key 值，*this表示使用每一项自身作为 key。骨架屏动画用background-size: 400%拉起一个横向移动的光影效果，这是目前成本最低的 loading 动效。
5.2 分包加载：控制面板与设置页不拖累首页
智能家居小程序的首页是流量入口，其他页面(设备设置、固件升级、历史记录)使用频率低。微信小程序的主包有 2MB 大小限制(截至基础库 2.x 时代，后续优化到更大，但保守按 2MB 控制没坏处)，把低频页面挂进subpackages是官方推荐做法。
{ "pages": [ "pages/home/index", "pages/device/control" ], "subpackages": [ { "root": "pages/settings", "pages": [ "device-setting", "firmware-update", "history-log" ] } ] }root字段定义分包根目录，分包内的页面路径以root为前缀。这样首页只打包必须的pages/home和pages/device，其余页面在用户真正访问时才下载。注意：跳转分包页面时，wx.navigateTo的 URL 要写全路径，例如/pages/settings/device-setting?deviceId=x。
5.3 收尾检查表：从页面栈到分享链路
快上线时，可以按这个清单过一遍工程：首页onShow里是否需要刷新设备状态；wx.navigateTo的页面层级不要超过 10 层，设备控制面板和设置之间建议用wx.redirectTo避免栈堆积；分享功能若需要携带设备 ID，放进onShareAppMessage的path参数里。这套方案不依赖任何私有组件库，手写在任意原生小程序工程里都能落地，后续接真实硬件网关时，只需要把wx.request的 URL 替换成内网网关地址即可。
本文还有配套的精品资源，点击获取
