Matter协议如何统一智能家居？架构原理与开发实战解析-代码聚汇网

Matter协议如何统一智能家居？架构原理与开发实战解析

沈蓁蓁·2026-08-30·阅读 23 GEO检测（免费）

Matter协议智能家居通信协议

|难度：普通|阅读约 39 分钟

1. 智能家居的“协议巴别塔”：为什么我们迫切需要Matter

先描述一个很多人都有过的真实经历：家里装修完，买了A品牌的智能灯泡、B品牌的智能插座、C品牌的门锁，结果发现要用三个APP分别控制。想实现“离家一键关闭所有设备”，只能靠运气或者额外买个昂贵的万能网关。这背后的问题不是硬件不好，而是通信协议各说各话——Zigbee设备听不懂Wi-Fi设备的指令，Z-Wave网络和Thread网络互不相认，蓝牙Mesh更是自成一体。

这就像一个会议室里坐了十几个国家的人，每个人都在用母语发言，谁也不知道对方在说什么。智能家居行业这么多年，缺的不是好设备，而是一个“同声传译”。

Matter协议的出现就是为了解决这件事。它由连接标准联盟（CSA，Connectivity Standards Alliance）主导，前身是Project CHIP（Connected Home over IP），成员包括苹果、谷歌、亚马逊、三星这些巨头。它的定位不是要替代Wi-Fi、Thread、蓝牙这些底层通信协议，而是在这些协议之上建立一个统一的应用层标准。

简单说，Matter做的是“串联”的工作：它定义了一套所有设备都能理解的“共同语言”，不管底层是走Wi-Fi还是Thread，也不管设备是灯、锁、传感器还是空调，只要支持Matter，就能被任意一个Matter生态的APP、语音助手或控制中心统一管理和控制。

对开发者来说，Matter最大的价值在于“一次开发，处处兼容”。以前你要为一个智能插座适配苹果HomeKit、谷歌Home、亚马逊Alexa三套平台，得写三套不同的接口逻辑和认证流程。现在只要按Matter的标准实现一遍，就能同时进入三大生态，而且还能保证本地化运行——不依赖云，不依赖某个厂商的服务器。

这篇文章我会从Matter的架构原理、底层通信协议的接入方式，到实际搭建一个Matter设备的完整流程，再到我踩过的那些坑，尽量讲清楚一件事：Matter到底是怎么把一堆乱七八糟的协议“串”起来的，以及你想上手试一试的话，应该从哪里开始。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. Matter的架构设计：它不是翻译机，而是统一语言

2.1 通信协议的分层逻辑

要理解Matter的“串联”思路，先得明白通信协议本身是分层的。拿互联网做类比，HTTP协议是应用层，TCP是传输层，IP是网络层，Wi-Fi是链路层。每一层各司其职，上层不用关心底层的实现细节。

Matter的做法非常聪明：它选择站在IP之上。不管底层是Wi-Fi、以太网还是Thread，只要这个网络能跑IPv6，Matter就能在上面运行。这样一来，Matter其实是在IP这层“地基”上面盖了一个统一的应用层标准。

这个设计选型非常关键。你看Zigbee为什么难搞？因为它的应用层和网络层是绑定的，且不支持IP，导致它和外界通信必须通过网关做协议转换。Z-Wave更封闭，工作在亚GHz频段，协议栈完全私有。这两种技术想实现跨厂商互联，只能靠第三方桥接，而且桥接的复杂度极高。

而Matter从一开始就抛弃了“私有网络层+私有应用层”的老路，直接拥抱IP。底下的链路层你可以用Wi-Fi、Thread、以太网，甚至未来可能出现的什么新无线技术，只要它支持IPv6，Matter的上层就不用改代码。这对开发者来说简直不要太省心。

2.2 核心架构：一个运行在IP网络上的跨协议应用层

具体拆解Matter的协议栈，它大致分这么几层：

底层传输：IPv6、6LoWPAN（Thread网络中使用）、TCP/UDP。
消息层（Message Layer）：负责Matter消息的路由、加密和可靠性保证，定义了消息头格式、会话管理等。
安全层（Security Layer）：管理设备配网和会话加密，分为PASE（Passcode Authenticated Session Establishment，配对码认证）和CASE（Certificate Authenticated Session Establishment，证书认证）。
交互模型（Interaction Model）：定义设备之间如何交互，比如读取属性（Read）、写入属性（Write）、执行命令（Invoke）和订阅事件（Subscribe）。
数据模型（Data Model）：定义设备的功能结构，以Node（节点）、Endpoint（端点）、Cluster（集群）、Attribute（属性）、Command（命令）为基本元素。

平时开发你不太会直接碰消息层和安全层，更多是操作数据模型层的Cluster。举个例子：一个智能灯泡，它是Node；它内部有一个Endpoint（通常是Endpoint 1）对应“灯泡”这个功能；这个Endpoint下有OnOff Cluster，里面有OnOff属性、On和Off命令；还有LevelControl Cluster，里面有Brightness属性和MoveToLevel命令。Matter通过这套标准化模型，让不同厂商的灯泡都能被同一个控制逻辑操作。

这也是Matter“串联”的精髓：它不关心你的灯是用Zigbee芯片还是Wi-Fi芯片实现的，它只关心你的设备能在应用层提供标准的OnOff Cluster和LevelControl Cluster，至于信号怎么从手机到设备，那是底层协议的事。

2.3 IP网络带来的最大红利：天然支持互联网接入

Matter选择了IP，带来一个巨大的好处——设备天然具备联网能力。Zigbee和Z-Wave设备必须有一个网关把私有协议转换成IP协议，才能被手机APP从云端或局域网控制。Matter设备不需要这层转换，它本身就“长”在IP网络上。

更妙的是，Matter在局域网内的控制完全走本地网络，不依赖云端。你家的路由器正常工作，Matter设备就能通过mDNS（Multicast DNS）被手机自动发现，直接通信。断网也不影响局域网内的控制。这种“本地优先”的架构，对隐私和响应速度都是很大的提升，也是苹果、谷歌这些公司愿意站台的原因之一。

3. 六大底层通信协议的接入方式：Matter是如何“包容”它们的

3.1 Wi-Fi：最省心的“主力通道”

Wi-Fi设备在Matter生态里基本可以“零负担”接入。因为Matter的应用层建立在IPv6之上，一个支持Matter的Wi-Fi设备本质上就是一个跑的IPv6协议栈的嵌入式设备。开发时，你在Matter SDK里配置好Wi-Fi SSID和密码，设备连接路由器后会自动获取IPv6地址，然后通过mDNS广播自己的服务，支持Matter的控制器就可以发现并管理它。

这里有个常见的疑问：为什么Matter在Wi-Fi上强调用IPv6而不是IPv4？因为mDNS在IPv6下的组播实现更成熟，而且Thread等低功耗网络天然基于IPv6，统一到IPv6可以避免两种地址族之间的转换和桥接。而且IPv6的地址自动配置（SLAAC）让设备入网后能很快拿到地址，方便快速建立通信。

不过Wi-Fi设备有一个老问题——功耗。Matter标准里规定Wi-Fi设备必须支持低功耗模式（如Wi-Fi的Target Wake Time技术），但对于电池供电的传感器，Wi-Fi依然不是最优选择。所以Matter生态里，电池设备通常走Thread。

3.2 Thread：低功耗设备的主场

Thread是本次Matter推广中最大的赢家之一。它也是基于IPv6的Mesh网络协议，但和Wi-Fi不同，Thread专为低功耗、低带宽的物联网场景设计。它支持多跳Mesh组网，设备之间可以相互中继消息，覆盖范围比单点Wi-Fi大得多。

Thread网络里有一个特殊的角色叫“边界路由器”（Border Router）。它的作用是把Thread的Mesh网络和常规IP网络（如Wi-Fi或以太网）连接起来。边界路由器可以让Thread设备获得一个全局IPv6地址，这样你从手机控制Thread灯泡时，数据包是走Wi-Fi到边界路由器，再由边界路由器转发到Thread网络的。

你可能听说过Matter over Thread这个说法，它指的是Matter应用层跑在Thread网络上。Thread负责底层的Mesh通信和IP寻址，Matter负责上层的设备模型和交互逻辑。这种组合很适合智能家居里的门窗传感器、温湿度计、智能按钮等电池供电的小设备，续航可以达到一年以上。

选择Thread设备时，要注意一个细节：Thread的边界路由器并不是由Matter标准定义的，而是由Thread Group的规范单独认证的。市面上有些路由器或智能音箱内置了Thread边界路由器功能，但必须确认它同时支持Matter桥接，否则你的Thread设备即使能接入Thread网络，也可能无法被Matter控制器正常发现和管理。

3.3 BLE：只是“敲门砖”，不做长期通道

Matter对蓝牙（BLE）的定位非常明确：它只用于配网，不用于日常数据通信。

Matter设备首次入网时，通常通过BLE广播自己的Matter配对信息。你在手机上打开Matter APP，手机通过BLE发现设备，然后双方进行PASE配对，交换配网凭证（Wi-Fi密码或Thread网络凭据），之后设备就连上Wi-Fi或Thread网络，BLE连接随即断开。后续所有操作都走Wi-Fi或Thread。

这种设计很聪明。BLE的带宽和通信距离都不适合做设备日常控制，但它的低功耗广播和已经普及的手机支持率，让它成为最方便的配网通道。而且BLE配网采用的PASE机制，通过设备上显示的PIN码或二维码进行密钥协商，能有效防止中间人攻击。

实际开发中，很多工程师会纠结要不要加上BLE配网功能。我的建议是：如果你的产品已经有屏幕或NFC，可以考虑用NFC交换配网信息；否则老老实实加BLE支持，这是Matter标准推荐的最通用方式，也最容易通过认证。

3.4 桥接设备：让老旧Zigbee和Z-Wave产品“再就业”

Matter在设计时给了一个很有诚意的“后门”——桥接模式。它允许非Matter设备（比如Zigbee和Z-Wave设备）通过一个“桥”设备接入Matter生态。这个桥设备本身是Matter兼容的，它一边连接Zigbee/Z-Wave子设备（作为网关），一边以Matter节点的身份对外提供统一的设备模型。

这意味着你家已经买了的Zigbee智能灯泡、Z-Wave门锁，不用全部扔掉，只要买一个支持Matter桥接的Zigbee/Z-Wave网关，就能把它们“翻译”成Matter设备，被苹果Home、谷歌Home这些生态统一控制。

桥接的实现细节很有意思。桥设备内部维护着一张映射表，每个Zigbee子设备对应Matter的一个Endpoint。Zigbee的Endpoint和Cluster会翻译成Matter的Endpoint和Cluster。比如Zigbee的OnOff Cluster映射到Matter的OnOff Cluster，Zigbee的LevelControl映射到Matter的LevelControl。从Matter控制器的视角看，这些桥接设备看起来和原生Matter设备几乎一模一样。

但桥接模式有一个绕不开的缺点：延迟增加。指令从手机发到Matter桥，再由桥转换成Zigbee命令发给子设备，中间多了一跳，响应速度会变慢。不过好在Zigbee本地的响应速度足够快，对于大多数灯光控制场景，用户几乎感知不到延迟。

3.5 以太网和未来的其他协议

以太网在Matter里是一个比较“低调”的选项。常见的支持Matter的以太网设备主要是音箱、路由器、智能中枢等固定设备。它们通过有线网络接入，功耗和带宽都不是问题，非常适合做Matter控制器（Controller）或边界路由器。

另外，Matter的标准架构决定了它具备良好的扩展性：只要一种网络技术能承载IPv6，理论上都可以接入Matter。比如未来如果出现新的低功耗广域网技术，只要实现IPv6适配，Matter的上层标准无需改动就能运行。

我们回过头来看这几种接入方式，它们各司其职：Wi-Fi负责高带宽的主力设备，Thread负责低功耗传感器，BLE负责配网，桥接负责兼容存量设备，以太网负责固定中枢。这五者组合在一起，基本覆盖了智能家居的绝大多数场景。

为了看得更清楚，我把它们的侧重点整理成了一个表格：

底层协议	在Matter中的角色	优势	典型设备	局限性
Wi-Fi	主要数据通道	带宽大，直连路由器，开发简单	智能灯、插座、摄像头	功耗较高，不适合电池设备
Thread	低功耗Mesh数据通道	低功耗、Mesh自组网、覆盖广	传感器、门锁、按钮	需要边界路由器转发
BLE	配网通道	手机原生支持，低功耗	配网阶段使用	通信距离短，带宽小
Zigbee/Z-Wave	桥接接入	兼容存量设备	旧网关、旧灯泡	需桥接，延迟增加
Ethernet	固定设备连接	稳定、大带宽	智能中枢、音箱	布线限制

这张表解答了一个新手常见的问题：Matter设备是不是必须支持所有协议？完全不是。一个Matter设备只需要支持“路由器或边界路由器提供的底层网络”即可，绝大多数设备只需要挑一种适合自己的通道。协议之间怎么互通，是Matter控制器和边界路由器的事，对设备来说透明。

4. 实战：从零搭建一个Matter设备，打通Wi-Fi和Thread两种链路

4.1 前置准备：选择你的硬件和开发环境

理论讲再多，不如动手做一遍。我在实际开发中选择了一套性价比很高的组合：ESP32-C3开发板 + 树莓派4B + Home Assistant作为Matter控制器。分开说为什么要这样选：

ESP32-C3 是我日常用来做Matter设备开发的主力模组。它基于RISC-V架构，支持2.4GHz Wi-Fi和BLE 5.0，官方通过ESP-IDF提供了完整的Matter SDK适配，价格便宜，烧录方便，非常适合验证Matter设备端逻辑。如果后面要测Thread相关功能，可以再买一块带Thread射频的板子，比如基于Silicon Labs EFR32系列或Nordic nRF52840的开发板。
树莓派4B 用它来做两类事：跑Home Assistant（作为Matter Controller），以及配置成OpenThread Border Router（OTBR），让Thread设备能接入整个网络。
Home Assistant 是目前对Matter支持最成熟的开源智能家居平台之一。你可以在树莓派上通过Docker方式安装，再安装Matter Server组件，这样手机Home APP或谷歌音箱等就可以通过它来控制所有Matter设备。对开发者来说，Home Assistant还提供了很直观的调试日志界面，能看到Matter设备的配对和交互细节。

如果你的网络条件受限，不装Home Assistant也能测Matter，直接用手机上的谷歌Home或苹果Home APP配合支持Matter的控制器硬件即可。但Home Assistant胜在跨平台、可自定义、日志丰富，适合第一次上手的人摸清整个流程。

4.2 编译Matter设备端固件：以ESP32-C3为例

第一步是搭建构建环境。Matter SDK基于C++，依赖了一些工具链，推荐在Linux环境或WSL下编译。你需要安装的工具有：

gn（生成Ninja构建文件）
ninja（编译）
gcc / g++
clang
Python3 和 pip
esp-idf 及对应的ESP32工具链

用命令初始化Matter SDK：

bash复制git clone --recurse-submodules https://github.com/project-chip/connectedhomeip.git
cd connectedhomeip
./scripts/checkout_submodules.sh
source scripts/activate.sh  # 激活Python虚拟环境

然后安装ESP-IDF环境。ESP-IDF自己也有一个安装脚本：

bash复制git clone -b v5.0.2 --recursive https://github.com/espressif/esp-idf.git
cd esp-idf
./install.sh esp32c3
source export.sh

环境就绪后，设置Matter SDK里针对ESP32的构建参数。Matter仓库里有一个examples/lighting-app/esp32示例工程，直接用它编译：

bash复制cd examples/lighting-app/esp32
set -x IDF_PATH=/path/to/esp-idf
set -x IDF_PLATFORM=esp32
source ../../scripts/examples/matter_esp_example_export.sh
idf.py set-target esp32c3
idf.py build

这一步会拉取Matter里大量的中间件源码，首次编译会比较久，耐心等。编完之后固件生成在build/lighting-app.elf 和 build/lighting-app.bin。

将固件烧录到ESP32-C3：

bash复制idf.py -p /dev/ttyUSB0 flash monitor

打开串口监控，你会看到设备开机后进入广播状态，打印类似CHIP Device information的日志，其中包含一个Discriminator和一个配对PIN码（默认通常是20202021），后面配网要用。

4.3 使用Home Assistant进行Matter配网和跨协议控制

设备固件烧录完成后，在Home Assistant后台添加Matter控制器。如果你是用的Home Assistant OS或容器版，直接安装Matter Server集成，它会自动创建一个Matter Fabric（可以理解为一个信任域）。

然后在Home Assistant后台的“设备与服务”里点击“添加Matter设备”，此时手机或浏览器会提示输入配对码。你看到ESP32-C3串口日志里打印的PIN码后输入，配对就开始了：

手机/Home Assistant通过BLE扫描到正在广播的Matter设备。
双方建立PASE安全会话，交换配网信息。
设备拿到你家里Wi-Fi的SSID和密码，主动连接路由器。
设备在Wi-Fi上完成CASE认证，正式加入Matter Fabric。
Home Assistant发现设备支持OnOff和LevelControl这两个Cluster，自动生成灯的实体。

到这里，你就通过Matter把一个ESP32变成了“智能灯泡”，可以用Home Assistant的开关按钮控制它。如果你想从苹果Home控制它，只需在Home Assistant里把设备桥接给HomeKit，或者在同一个Fabric里再配置一个苹果家庭中枢。

4.4 加入Thread链路：让线程边界路由器“搭桥”

再往下走一步，我想验证Thread设备能不能真正融入整个Matter网络。这里我用了另一块基于Silicon Labs EFR32MG24的开发板，它同时支持Thread和BLE。同样刷入Matter SDK里的lighting-app示例，只不过配置成Thread模式。

然后树莓派上搭建OTBR（OpenThread Border Router）：

bash复制sudo apt-get install docker.io
git clone https://github.com/openthread/ot-br-posix.git
cd ot-br-posix
sudo ./script/bootstrap
sudo INFRA_IF_NAME=eth0 ./script/setup

OTBR启动后，它会创建一个Thread网络，并把这个网络桥接到树莓派所在的以太网或Wi-Fi。此时ESP32-C3（Wi-Fi设备）和EFR32（Thread设备）都在同一个IP网络里，它们之间是可以通过Matter互通的。

我在Home Assistant里分别把两个设备配对进来。配对时Thread设备也是先走BLE配网，但Device Role选择“Thread设备”，配网后设备会加入Thread网络而不是Wi-Fi。配对完成后，Home Assistant里出现两个智能灯实体。我做一个测试：创建一个自动化，当Thread灯打开时，同时打开Wi-Fi灯。结果显示，从发出命令到Wi-Fi灯响应，差不多100毫秒左右，完全在可接受范围内。

这个实验最能说明Matter“串联”的意义：设备A跑Wi-Fi，设备B跑Thread，底层协议完全不同，但应用层因为都遵循Matter标准，所以它们可以在同一个控制界面里被统一操作，互相之间还能按规则联动，不用各自配网关。

4.5 小实验：用手机验证跨厂商控制

如果你没有Home Assistant，直接用手机也可以验证：安装谷歌Home APP，它会引导你创建一个Matter Home，然后添加设备。谷歌Home作为Matter控制器，能自动发现设备并配对。你再装一个苹果Home APP，把设备添加到同一个Fabric中（苹果Home同样支持Matter），两个APP能同时控制同一个设备，不会冲突。这就是Matter“一次开发，多生态兼容”的直接体验。

5. 踩坑实录：开发者最容易栽的四个地方

5.1 边界路由器与Thread网络的分区冲突

我第一次搭OTBR时遇到一个很隐蔽的问题：树莓派重启之后，EFR32设备仍然在Thread网络上，但Home Assistant突然找不到它了。排查了半天，发现是OTBR在每次重启时创建了不同的Thread网络分区，设备没能自动重新加入。

解决方法是固定Thread网络的分区ID和网络名，把它们写入OTBR的配置文件：

bash复制sudo ot-ctl dataset networkkey 
sudo ot-ctl dataset commit active

每次重启后确保dataset保持一致。另外边界路由器最好用有线网络连接主路由器，避免无线回程造成的组播包丢失。

5.2 mDNS发现超时：跨VLAN设备的“隐形墙”

Matter的设备发现依赖mDNS。我的路由器开了访客网络隔离，把IoT设备放在一个VLAN，手机和Home Assistant在另一个VLAN。结果Matter设备始终无法被发现，即使手动添加IP也无法配对。

原因很简单：mDNS默认只在同一二层广播域内传播，跨VLAN需要配置mDNS反射器，或者用支持mDNS跨VLAN的路由器固件。如果你不希望折腾网络，最简单的办法是把所有Matter设备、手机、控制中枢放在同一个SSID和同一个网段下。IoT设备对网络隔离的友好程度，目前Matter还远没到能无缝穿越复杂网络的程度。

5.3 BLE配网失败和PIN码输入超时

ESP32设备在配网时BLE广播是有超时限制的，默认大概10分钟。如果你在烧录后先去干别的，回来再配对，设备可能已经停止了BLE广播。重新按一下设备上的按钮，或者重新上电，能重新进入配网模式。

另外，Matter的配对码是6位数字，但很多设备打印日志时中间会有空行，容易看错数字。我在一次演示中把PIN码看错一位，导致配网失败，又浪费了2分钟调试。建议在工程日志里把PIN码重点标出，并且在配对前要确保手机距离设备足够近（BLE信号弱会导致配网超时）。

5.4 DCL认证问题：合规设备列表的依赖

Matter在设备认证时，需要从DCL（Distributed Compliance Ledger，分布式合规账本）查询设备是否通过认证。如果你的开发板没有正式认证的VID/PID，或者测试网络无法访问DCL，配对时会出现认证失败。

解决办法是在开发过程中关闭或绕过认证检查，具体取决于你的Matter Controller。在Home Assistant的Matter Server配置里，可以设置auto_unpaired调试选项，或者为设备指定一个测试VID/PID。但请注意，这只适用于开发用途，正式产品上市时，必须通过CSA认证并正确配置VID/PID和DCL信息，否则无法在主流生态中合法使用Matter兼容标识。

6. 测试工具和调试技巧：工程师的“战场侦察兵”

做Matter开发，光靠看日志很难发现跨设备的深层次问题。这里推荐几个我常用的工具和调试方法。

Wireshark + nRF Sniffer：如果你想抓取BLE配网包或Thread网络包，这是最直接的方案。Wireshark可以解析Matter的多种协议层，包括BLE配网阶段的pase协议、mDNS发现报文以及后续的CASE会话。抓包时要注意加密原因——Matter消息本身是加密的，Wireshark的解密功能需要你导入会话密钥，否则只能看到包头，看不到具体内容。

Chip Tool：这是Matter官方提供的一个命令行测试工具，可以用来模拟一个Matter Controller，对设备进行发现、配对、读写属性等操作。如果在Home Assistant里排查问题不方便，Chip Tool是最接近底层的调试入口。你可以在SDK的scripts/tests目录下找到它，编译后通过命令行和设备直接交互。

实测结论与心得：上面这套流程跑通之后，我最大的感受是，Matter已经不是一个“未来技术”，而是完全可以在当下落地开发的标准了。硬件成本、开发工具链、调试手段都相对成熟。最花时间的地方不是协议本身，而是跨设备的组网环境问题——网络隔离、边界路由配置、VLAN这些，反而是实际工程中占比最高的“隐形工作量”。

7. 我的实操体会和给新手的建议

最后分享几点我自己的体会。

第一，不要试图理解Matter的每一行协议细节再动手。直接找一个Matter SDK的示例工程，烧录到开发板上电跑通，通过配网、控制、联动这整个流程，你对Matter的理解会远超读十天文档的收获。

第二，硬件选型上，新手建议直接从ESP32-C3入门，它便宜、资料多、环境容易搭。跑通Wi-Fi设备后，再买一块Thread开发板来玩边界路由，千万不要一上来就搞Thread和复杂的Mesh组网，那是拿自己仅有的一点耐心去测试协议的成熟度。

第三，网络环境至关重要。如果你的最终目标是把Matter设备部署在真实家庭环境，提前检查家里的路由器是否支持IPv6、是否启用了AP隔离、mDNS是否正常转发。很多“配对失败”案例最后都发现是路由器配置问题，而不是设备或代码的问题。

第四，Matter还在快速迭代，不同版本的SDK在API上有一些差异。我踩过的坑包括某次升级后配对流程变化、某些Cluster属性命名调整，所以遇到问题时建议先查当前版本的官方迁移文档，再上网搜答案，否则会被旧教程带偏。

整体看下来，Matter虽然顶着“智能家居大一统”的光环，但它本质上不是一个万能钥匙，而是一套“只要大家都说IP，就能互相听懂”的标准。它的成功不取决于协议本身的技术含量，而取决于生态里的每一方是否愿意放弃私有协议带来的绑定优势。至少从目前的厂商支持力度来看，这个方向算是踩准了。如果你正准备开发一款智能家居设备，或者只是想把家里的设备统一到一个控制面板里，Matter值得你花时间深入了解，并且现在动手并不算晚。