想象一下这样一个场景：你是一家智能家居设备厂商的老板，产品在亚马逊上卖得不错，北美的用户反馈也不错，但你的技术团队最近却被一个叫Matter的东西折腾得够呛——海外客户开始问“你们支持Matter吗”，渠道商也把“Matter Ready”当成选品关键词，甚至连开箱视频里测评博主第一句话都问“能不能接入Apple Home”。这个曾经只在小圈子讨论的协议，现在成了出海绕不开的门槛。
先说结论：Matter协议确实正在成为智能家居出海的新基建，不夸张地说，它是继Wi-Fi配网、蓝牙一键配置之后，智能家居行业最值得关注的基础设施级变化。这篇文章我想从实际做产品的角度，把Matter到底是什么、它为什么能卡住出海设备的脖子、以及作为开发者或产品负责人你该怎么接、怎么避坑，一次性说透。
我不打算给你讲一堆枯燥的规范文档，而是想结合自己折腾过智能家居开源系统、嵌入式方案（包括那个经典的基于STM32F103C8T6的智能家居安防系统）、以及配合Matter协议调试设备时踩过的坑，聊聊这个“新基建”到底意味着什么，以及你要怎么跟上这班车。
1. Matter协议到底是什么，为什么突然就成了“基础设施”
1.1 别被各种概念绕晕：Matter、Thread、Wi-Fi、蓝牙到底什么关系
很多人第一次接触Matter就懵了，因为相关的名词实在太多：CSA（Connectivity Standards Alliance，连接标准联盟）、Zigbee、Thread、Wi-Fi、蓝牙、Apple Home、Google Home……到底谁是Matter？谁支持Matter？哪个是协议？哪个是生态？
我用一个比较朴素的方式给它们分工：Matter本身是一个应用层协议，它定义了智能家居设备之间“怎么打招呼”“怎么报状态”“怎么控制”这些抽象规则。它不限定设备的通信管道，但当前标准里主要跑在Wi-Fi、Thread这两种传输层上，Thread网通过边界路由器接入家庭网络，然后Matter控制器通过Wi-Fi或者Thread去控制设备。蓝牙的作用则主要是在设备配网阶段，用来把Wi-Fi凭据或Thread网络信息从手机传给你的灯泡或者传感器。
用生活类比来说：Matter是“通用普通话”，Thread是“光纤传输线路”，Wi-Fi是“家里的宽带网线”，蓝牙则是“你递给陌生人的一张写有Wi-Fi密码的小纸条”。设备之间能不能沟通，关键看它们说的是不是同一种普通话，而CSA这个机构就是制定普通话标准并负责发证书的。
Zigbee和Z-Wave则是上一辈子的“方言”。很多存量智能家居设备都是Zigbee的，它们没法直接说Matter的“普通话”。现在行业里也在做Zigbee和Matter之间的桥接，但那是另一套思路了。至少对你准备出海的新产品来说，直接做支持Matter的原生设备，远远比做桥接要清爽。
1.2 为什么出海设备尤其绕不开Matter
我自己在对接海外客户时感受特别明显。海外智能家居市场和国内有非常大的差异：国内用户习惯一个App或者一个音箱打通全屋，比如米家就是最大的控制中枢；但海外用户家里大概率同时有Alexa、Google Assistant、Apple Home，甚至还有一个SmartThings的Hub。他们的第一反应不是“你的设备能不能用你家品牌App控制”，而是“你的设备能不能被我现有的系统控制”。
这就是Matter出海的底层逻辑：你不做Matter，你就得同时适配Alexa、Google Home、Apple Home两到三套生态的私有协议，开发和认证成本极高；你做了Matter，一套协议同时打通三大生态，用户只要扫一个二维码，就能在他的默认家居App里用上你的设备。
从渠道商和零售商的角度看，支持Matter也意味着更低的退货率和客服成本。因为用户不再需要下载你的专用App、注册账号、用一个不熟悉的界面操作设备——这一切都可以用他早已习惯的Apple Home或Google Home完成。对出海品牌来说，这意味着用户从“买回家到用起来”的路径大大缩短了。
1.3 Matter“新基建”的身份体现在哪
把Matter称为“新基建”，是因为它改变了行业的“建设方式”。过去每个品牌自建云、自建App、自建协议，就像修了一条只属于自己的私有铁路，用户的每一节车厢都得在你这条铁路上跑。然而不同铁路之间无法互通，导致用户被困在站台上。
Matter的野心是把这些私有铁路统一成全国性轨道的标准：轨道规格统一，调度规则一致，接口通用，任何符合规范的车厢都能在这张网上跑。对开发者来说，这意味着同一份固件可以同时供应多个生态；对消费者来说，这意味着不再被单一品牌生态绑定；对芯片和模组厂商来说，这意味着他们可以做出更标准化的模块，进一步降低终端设备的开发成本。
2. 出海设备接入Matter的实操路径：认证分类与方案选型
2.1 不同设备类型对应不同认证分类，先定位你的产品
做Matter不是一句“我支持Matter”就完事的。在CSA的体系里，你的设备要先定清楚自己属于哪类“设备类型”，然后按照对应规范提交测试和认证。我在刚开始接触时就吃过没搞清楚分类的亏，白白多烧了一轮测试费用。
目前常见分类包括灯与照明、插座与开关、传感器（如温湿度、人体传感器）、门锁与安防、安防摄像头、温控器、窗帘电机等。每一类都有对应的Cluster（重要术语：Cluster是Matter里定义设备能力的数据模型，比如OnOff Cluster代表开关能力，Level Control Cluster代表调光能力）。你的产品必须实现对应Cluster里规定的必选属性，比如一个灯泡必须有OnOff Cluster，一个可调光灯泡还必须要有Level Control Cluster。
这里有个容易踩的坑：**同一个硬件产品可能存在多种形态。**比如一个带USB充电口的智能插座，它既可以当插座用，也可能带电量统计功能。这时候你要思考它要暴露哪些能力给系统——是仅仅做开关，还是连功率统计、用电量历史也一起暴露？能力暴露越多，意味着你要实现的Cluster越多，测试项也越多，成本和控制复杂度都会上升。出海产品建议第一版尽量做最小可用功能，先把基础的开关、状态上报跑通，后续再OTA升级增加更多Cluster。
2.2 选Wi-Fi还是Thread：这是最关键的硬件决策
Matter设备目前两大主线是Wi-Fi和Thread，选哪条线直接决定了你的模组成本、功耗和联网体验。
Wi-Fi Matter设备的优点是实现简单、成本成熟、用户路由器就有通信基础设施。你的设备本身支持Wi-Fi，配网时通过蓝牙将Wi-Fi账号密码传过去，之后设备直接和家庭网络通信。几乎所有第一代Matter智能插座和灯泡都选了这条路线，因为芯片方案已经很成熟，用的也是大家熟悉的ESP32、BK7231这类模组。
Thread Matter设备则是另一套逻辑。Thread本身是低功耗Mesh网络技术，设计目标是让电池类设备也能长时间在线（比如门磁传感器、温湿度计），同时具备Mesh级自恢复能力。Thread设备不能直接接入家庭Wi-Fi，它需要Thread边界路由器（比如Apple HomePod mini或某些支持Thread的路由器）来桥接到家庭网络。这对用户来说多了一层依赖，但换来的是更低的功耗和更稳定的Mesh覆盖。
我的建议取决于设备供电和形态：
| 设备类型 | 推荐网络方案 | 主要理由 |
|---|---|---|
| 插电类（灯泡、插座、空调伴侣） | Wi-Fi | 成本低，电路成熟，无需额外边界路由器 |
| 电池类（门磁、温湿度计、按钮） | Thread | 低功耗优势明显，电池续航更久 |
| 安防摄像头类（高带宽需求） | Wi-Fi（甚至直接用自有网络） | Thread传输带宽有限，不适合视频流 |
| 锁类（既要低功耗又要稳定） | Thread为主 | 可在无Wi-Fi覆盖区域通过Mesh组网 |
那Wi-Fi vs Thread到底哪个更适合出海？如果你做的是插电类产品，我建议优先Wi-Fi，原因很现实：**当前海外家庭里真正支持Thread的边界路由器数量仍然有限，而Wi-Fi协议是普遍的。**虽然Thread是那个“更有未来”的方向，但作为出海厂商，第一版产品要尽量减少用户对额外硬件的依赖，这可是直接影响转化率的。
2.3 芯片与模组选型经验：别只看宣传的“支持Matter”
市面上的Matter模块越来越多，但每个模组的“支持Matter”程度差异其实很大。很多模组只是硬件上能满足，软件SDK和认证预认证是否完整才是关键。
我体验过几种主流方案的差别：使用乐鑫ESP32系列时，好处是社区资料极多，ESP-Matter-SDK可以快速构建原型，配网和OTA链路相对完整，适合中小团队快速落地；使用NXP、Silicon Labs的Thread SoC时，低功耗特性明显更优，但学习曲线陡峭，Nicknaming上配置Thread网络也有不少细节。除此之外，市面上各家模组厂商还会直接提供“预认证模块”，这能大幅减少你的认证周期。
我的经验是：**如果你团队里的嵌入式工程师人数不超过2个人，不要轻易挑战做Thread原生设备。**选一颗已有Matter认证、有成熟参考固件的Wi-Fi模组，会让你的产品从立项到上市缩短至少3个月。等团队熟悉了Matter的开发模型，再规划第二阶段的Thread产品线。
2.4 DCL（分布式合规账本）和认证流程：不只是交钱拿证书
Matter设备的认证流程与过去的Zigbee认证有相似之处，但引入了DCL（Distributed Compliance Ledger，分布式合规账本）这一重要机制。简单说，DCL是一个分布式的设备认证数据库，设备在出厂时会有唯一的认证信息（包括产品证书、设备公钥等）写入设备中的受信任存储区域，当用户配网时，手机App或Matter控制器会查询DCL验证设备的“合法身份”。这能从源头防止杂牌设备伪造身份混入用户家庭网络。
对开发者来说，这意味着三件事：第一，你必须在量产阶段为每台设备写入合法的产品认证证书和设备证书；第二，这些证书私钥必须放在安全芯片或具备安全存储能力的MCU区域里；第三，你的生产流程里要有一套完整的证书灌装和管理流程。这不是买个NFC标签贴上去就行，稍有不慎，整个批次可能会被Matter系统拒之门外。
顺便说一句，Matter认证并不是一劳永逸。如果后续OTA版本改变了设备功能、增加了Cluster或者修改了配网流程，很可能需要重新做合规评估，甚至重新测试。所以在产品发布时，别急着一次性把所有未来功能都做进去，合理规划每个版本的功能范围，能帮你省下大笔认证费用。
3. 从开发到量产：Matter设备怎么实现、怎么测、怎么发版
3.1 最小系统搭建：一个Wi-Fi Matter灯泡的软硬件组成
我用一个做过的Wi-Fi Matter灯泡项目为例，说说做一个原生Matter设备需要的软硬件全貌。
硬件部分其实和普通Wi-Fi智能灯泡差不多：ESP32-C3模组（内置Wi-Fi和蓝牙），一颗开关电源驱动LED灯板，一颗电流采样电阻做灯的状态反馈。关键差异在于，你要选用的模组必须支持Matter要求的安全存储能力，因为Matter设备的身份私钥必须存储在不容易被读取的区域。如果模组没有安全区，可以外挂一颗ECC安全芯片。
软件部分则是另一套逻辑了。Matter官方的connectedhomeip SDK是一个超大的C++库，里面包含了设备发现、消息加密、交互模型、配网流程、OTA升级等全部机制。用ESP-Matter-SDK或者用乐鑫提供的Arduino兼容开发方式，可以把很多底层细节包装掉。但不管你用哪套SDK，以下几个模块永远是必做的：
- 配网服务：初始时设备处于未配网状态，需要周期性通过蓝牙广播自己的Discriminator/Passcode信息，用户扫码或者输数字后，手机App通过蓝牙将Wi-Fi或Thread网络凭据传给设备。
- 网络接入：设备拿到凭据后连接家庭Wi-Fi，然后通过mDNS广播，让控制器发现它。
- Cluster服务：灯泡最基本的OnOff Cluster和Level Cluster，用官方SDK里的DataModel接口实现，同时在状态变化时上报到控制器。
- OTA升级接口：Matter定义了自己的OTA Cluster机制，你可以通过家庭网络直接给设备做固件升级，非常方便。
3.2 开发中的关键细节：配网凭据与二维码的正确姿势
你以为Matter二维码只是个简单的URL？实际上，Matter配网二维码里编码的是手工配对码（Manual Pairing Code）和可选信息（比如Discriminator、PIN），格式有严格规定。如果你随便生成一个二维码给用户扫，大概率用户手机直接提示无法识别。
我做过的设备里有两种二维码模式：
- 一种是把二维码直接印在设备外壳或说明书上，这是绝大多数产品的做法。这个码的内容由产品证书里的Discriminator和PIN决定，生成后基本不能变。
- 另一种是动态屏幕显示配网码，适用于带屏设备或家电（比如洗衣机、空调），但这种环境下需要使用Matter的“基于显示器的配网码”模式，相关信息会在用户激活配网时显示出来。
无论哪种方式，**产品证书（PAI, Product Attestation Intermediate）和Device Attestation Certificate（DAC）必须在产线上写入每台设备的存储区域。**我在帮助一个工厂做量产程序时发现，很多同事以为直接用什么软件在电脑上生成证书再烧录就行，但实际上DAC是有一个严格的证书链结构的，根CA由CSA持有，产品证书由你向认证机构申请，设备证书则要在产线签发。这些证书文件之间要链得通，配网时才能通过DCL校验。
3.3 测试和调试：没有Matter认证平台，照样可以本地验证
很多团队一听Matter测试就头疼，觉得一定得到第三方实验室。其实在正式提交认证前，你自己完全可以在办公室里搭一套Matter测试环境。
第一步是准备一个Matter控制器。最简单的是用Google Home App或者Apple Home App配合对应生态的智能音箱，让它们作为Matter控制器去发现和配对设备。测试时确定一个流程：设备重置->控制器搜索->扫码或输码配对->开关控制->断电恢复->重新配对。在这个流程里观察设备的mDNS广播、配网超时、状态同步等问题。
第二步是用官方工具。Matter SDK里带了chip-tool（一个命令行工具），你可以在一台Linux设备（树莓派或PC）上编译运行它，通过命令行来执行配对、发送OnOff命令、读取Attribute等操作，这对我们嵌入式工程师排查问题非常好用——因为它能精确地告诉你哪一步失败了，错误码到底是什么。
我最常踩的坑集中在：
- 配网时的BLE广播间隔设置过短，导致手机搜不到设备，解决方法是把广播间隔调到20~40ms之间。
- Thread边界路由器没配好，导致Thread设备能配对但控制器无法访问，这个要检查Thread网络是否有健康的Leader节点。
- Verifying Attestation信息失败，大概率是DAC证书文件路径或格式不对，检查PEM/DER格式与ProductID是否匹配。
3.4 量产注意事项：每台设备都要有唯一“身份证”
如果只是打样几台，证书怎么折腾都行。一旦进入量产，你必须有一条稳定的产线灌装流程。具体来说：
- 产线工装里要集成证书生成与烧录工具，每次烧录时自动生成唯一的DAC。
- 要确保DAC私钥不被泄露。比较稳妥的做法是买个支持安全存储的SE芯片，把私钥烧进去后锁死芯片的调试接口。
- 需要建立设备唯一标识和出厂记录的数据库，方便后续追溯每一台设备是哪个批次生产的、用的哪张证书。
我们当时有一个合作伙伴图省事，在产线上把同一张DAC复制给了1000台设备，结果用户配对时DCL直接报出重复ID，所有设备都无法完成正规配网流程。最后只能重新烧录，损失了一个批次的物料和工时。这个坑你要特别记住。
4. 配合开源HA系统：Matter时代，系统集成者的进退之道
4.1 Home Assistant对Matter设备的支持：既是桥也是大后方
近年来，智能家居开源HA系统（Home Assistant，简称HA）越来越火，很多喜欢折腾的用户会在树莓派或NAS上自己搭建HA来统一管理家里的各种智能设备。Matter和HA之间的关系非常微妙：HA是一个强大的本地自动化平台，它支持Zigbee、Z-Wave等协议，但Matter给了它一个更“标准”的设备接入通道。
HA新版已经内置了Matter Server (基于Python的Matter控制协议)，它的角色相当于一个Matter控制器/管理员，可以扫描QR码配对Matter设备，然后把它们变成HA里的实体，再通过HA的自动化引擎对这些设备统一控制。
对用户来说，HA的意义在于：你可以同时配对Apple Home里不支持的品牌设备、买到的非Matter协议设备（通过Zigbee USB Dongle接入），再通过HA把它们统一暴露给Matter生态。简而言之，HA是那些不想受制于任何一个商业生态的用户的“大后方”。
对我这种爱折腾的人来说，HA还有一个很大优势——它可以在不依赖云的情况下做本地控制。智能家居用久了你会发现，很多海外大牌的App一旦网络波动或服务器出问题，本地设备竟然也会“卡住”。而HA作为本地化控制核心，能把这个问题抹平。
4.2 从STM32F103C8T6安防系统到Matter：低成本设备的接入思路
有朋友可能会问：我做的是那个很经典的基于STM32F103C8T6的智能家居安防系统，这种低成本MCU能支持Matter吗？
坦率说，STM32F103系列本身资源非常有限，RAM和Flash都不足以跑一个完整的Matter协议栈。Matter的SDK对资源要求至少要几百KB的Flash，以及一定的网络安全和密钥存储能力，所以让F103直接原生跑Matter是不太现实的。
不过这不代表老设计就废了。我建议的接入思路有两种：
- 方案一：MCU+Matter模组。原来的STM32F103C8T6继续做它擅长的传感器采集、继电器控制、报警逻辑；外接一个支持Matter的通信模组（例如ESP32-C3模块），两者通过UART与自定义指令协议通信。同时模组将收到的Matter控制指令翻译成UART指令交给STM32去执行，再将STM32上报的状态同步到Matter网络中。这是目前最稳妥的低成本升级路径。
- 方案二：换主控方案。如果你的产品还在早期设计阶段，并且整体逻辑不算特别复杂，可以直接把主控升级成ESP32-S3或RTL8720系列，让它同时承担应用逻辑和Matter协议栈。这样电路板会更紧凑，但代价是应用代码要和Matter SDK跑在同一个芯片上，调试复杂度会更高。
我做安防系统时的切身体会是：F103的强项是外设丰富、代码简单、稳定性好，但它不适合跑现代的IoT协议栈。Matter需要的不只是协议解释，还需要DTLS加密、证书管理、mDNS/DNS-SD服务发现等能力。把这部分摊给通信模组自己处理，既能让老代码继续沿用，又能快速跟上Matter新基建，是一种非常划算的过渡架构。
4.3 桥接设备还是一个悬而未决的大生意
除了原生Matter设备，市面上有一批厂商在做Matter桥接器，把经典Zigbee或者私有RF协议设备“翻译”给Matter系统。比如用户家里的Zigbee温度计、Zigbee门磁传感器，通过一个Matter桥接网关接入Apple Home或者HA。这套方案对存量设备非常友好，也是目前智能家居圈比较火的方向。
但桥接有个绕不开的问题：Matter桥接器必须为桥下的每个设备生成动态的Matter端点和Cluster映射，桥接开发复杂度不低。如果一个Zigbee灯泡同时支持On/Off和Level功能，桥接器就要把它映射成Matter设备里对应的两个Cluster，这样Apple Home才能当成可调光灯泡来用。拿我自己做的桥接器测试来说，光是把几种常见Zigbee设备类型映射清楚，就花了一两个周末，更别提异常掉线时的状态同步了。
所以如果你想做Matter出海生态里的生意，除了做原生设备，桥接网关也是一个非常有价值的品类。海外家庭存量Zigbee/Z-Wave设备非常多，而新用户大概率买的又是Apple Home/Google Home设备，没有桥接，这些存量设备就只能沦为摆设。
5. 实际踩坑与故障排查：Matter设备开发的九个高频问题
5.1 配网、发现与控制阶段的问题速查
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 手机App扫不到设备 | BLE广播未开，或广播参数不合适 | 确认广播开启，间隔调到20~40ms，查看日志中是否有广播事件 |
| 扫码后提示设备无响应 | TCP端口错误或mDNS服务未注册 | 检查Matter主服务端口，确认mDNS-TXT记录正确 |
| 配网后控制超时 | Wi-Fi路由组播隔离 | 关闭路由器的AP隔离，或为IoT设备单独开放UDP端口 |
| 设备在App里离线 | 电源供电不足导致重启 | 特别在电池设备中检查峰流；插电类设备检查启动时序 |
| 无法完成OTA | OTA Provider节点不稳定或分包超时 | 确认控制器/手机App一直在线，检查OTA分包大小及等待时间 |
5.2 我踩过最深的坑：Thread边界路由器的组合问题
在做Thread设备测试时，我被一个诡异问题卡了两天：Thread温湿度计在A用户家里配对正常，但放到B用户家里后一直处于“不可用”状态。后来排查了很久才发现，问题不在设备，而是两个家庭的边界路由器类型不同。
Matter Thread网络对边界路由器的要求是必须开启Thread功能，并且边界路由器的软件版本和Mesh网络的Composition规则必须满足Matter要求。如果用户家里只有一款老固件的路由，它虽然能创建Thread网络，但该网络可能不符合Matter的OpenThread版本，设备连进去后控制器无法读取数据。设备端是看不出错误的，只能通过抓包分析才能看出网络层数据没有真正出口。
这个经历提醒我：Thread产品的测试必须覆盖多种常见边界路由器组合（Apple生态、Google生态、Amazon生态、第三方路由器），而且要在产品说明书里明确提示用户需要“支持Thread的边界路由器”。否则用户买回去连不上，再好的产品体验也会被差评淹没。
5.3 安全性与隐私合规：Matter设备的“出海番外篇”
Matter本身在传输安全上做了很多工作：所有控制消息都是AES加密的，设备身份通过证书链验证，命令都有时间戳和随机挑战码防止重放。可以说，Matter网络安全性从协议层面比老一代智能家居系统要强很多。
但作为出海产品，协议安全只是基础，你还得考虑当地市场的合规：比如面向欧洲市场需要遵守GDPR，面向美国市场要注意FCC认证，而且现在很多海外渠道还要求设备可以禁用人脸识别等隐私敏感功能。这些合规要求叠加到Matter设备上，会使你不仅要保证协议认证，还要对数据流做隐私设计。
我特别建议出海团队在产品立项时就把隐私合规要求写进功能范围。很多人以为“Matter通过认证=万事大吉”，实际上Matter认证是协议互通性认证，它不替代各国家和地区的安全合规认证。如果你做门锁加摄像头，除了Matter认证之外，还必须过美国加州或欧盟的摄像头产品合规测试，这两条线要并行推进。
5.4 向用户交付：说明书和售后响应也要“Matter化”
成品出厂后，最容易出问题的不是设备本身，而是用户的使用期望。Matter设备虽然开箱配对简单，但如果你说明书里还写着“请下载我们的App并注册账号”，用户会非常困惑：我扫码后苹果手机怎么直接配对了？是不是产品坏了？这时候如果售后响应不及时，退货率就可能飙升。
比较好的做法是：
- 说明书首页就写“Works with Apple Home, Google Home, Amazon Alexa”，并且印出对应生态的配对二维码图标。
- 提供简短视频或图文配对指南，特别是Thread设备要标注清楚“需要HomePod mini或Thread边缘路由”。
- 售后客服要接受Matter基础培训，至少能听懂用户说的“在Apple Home里搜不到”这类问题，并快速给出判断方向。
我见过太多技术牛人做出的硬件产品，死在用户不懂怎么配对这个“最后一米”。Matter新基建的初衷是把用户体验拉到极致简单，如果你交付给用户的说明书比协议本身还复杂，那就只能怪自己没把产品当完整体验来做。
6. 个人实操体会：Matter出海赛道的未来机会，以及在哪个环节更适合切入
我陆陆续续折腾智能家居设备也有好几年了，从最早的433MHz RF开关，到Zigbee全家桶，再到现在的Matter，最大的感受是这个行业终于开始向“标准”收敛。Matter或许不是十年后唯一的协议，但它已经给行业建立起一套从设备认证、数据模型到交互安全的高度一致的通信范式。对出海品牌来说，不计成本地死磕多平台私有接入，远不如一套Matter认证省事。
从产业机会来看，我比较看好这几个方向：一个是支持Matter的传感器和低功耗门磁设备，尤其Thread路线的产品现在还是一块蓝海，竞争远没Wi-Fi插座那么卷；另一个是Matter窗帘电机/通断器这类安装型产品，这类产品因为线下安装服务链条复杂，反而更看重标准化协议，Matter能显著降低安装商的学习成本；再一个就是存量Zigbee设备的Matter桥接器，海外家庭里存量设备数量巨大，谁先把桥接体验做好，谁就握住了替换成本优势。
最后再提一个很多人容易忽略的细节：不要在产品发布前一周才开始准备Matter认证材料。从产品立项开始，就应该确认好DCL账户、Submitter信息、选择第三方测试实验室并排期。Matter认证从预测试到正式测试，通常需要至少两个月时间，而且越到旺季实验室slot越紧张。你在开发上省下来的时间，很可能全被认证排期吞掉。
作为开发者，如果这个阶段你还没有开始学Matter，我真的建议尽早动手。早期学习和试错的成本是最低的，等生态全面普及、所有厂商都涌进来时，出海的船票恐怕就要看谁的红利时段先结束了。我现在再看自家那把用了多年的射频遥控开关，就会想：如果当初它支持Matter，也许现在还会更多地被我手机里的Apple Home调用。
