定义
ZeroConf（零配置）指设备通过 mDNS、DHCP 等机制自动发现网络与平台，无需用户手动配置即可完成 Provisioning 入网。适用于局域网设备、消费类 IoT 场景，提升用户体验。
核心技术机制
ZeroConf 依赖多种协议协同工作。mDNS（多播 DNS）使设备在局域网内通过 .local 域名自宣告与发现；DNS-SD（DNS 服务发现）基于 mDNS 扩展，用于发布和解析服务类型与实例；DHCP 可选选项（如 Option 43、Option 66）可向设备推送平台地址或配置服务器 URL；SSDP（简单服务发现协议）在 UPnP 场景下用于设备与服务的发现。设备上电后自动执行发现流程，获取网络参数与平台接入点，完成 Device Onboarding 入网。
与 DMP 的集成
设备管理平台可通过网关或本地代理支持 ZeroConf 设备。网关在局域网内发现 ZeroConf 设备后，代为向 DMP 注册并建立代理连接；或设备通过 DHCP 获取的配置服务器地址，直接拉取平台接入参数。平台侧需提供配置下发接口、设备预注册或动态注册能力，与 Dynamic Registration 动态注册流程配合，实现零配置入网后的自动认证与绑定。
应用场景与局限
ZeroConf 适用于智能家居、办公设备、工业现场局域网设备等场景，可显著降低部署与运维成本。其局限在于依赖局域网环境，跨网段或公网设备需配合网关或隧道；部分企业网络禁用多播或 DHCP 选项，需评估网络策略；高安全场景可能要求额外的人机交互或证书预置，以平衡便利性与安全性。
零配置发现的是局域服务而不是账号
零配置解决的是“在这个本地网络里，对方的接入点叫什么、地址是什么”。设备通过多播名字或地址分配选项得知平台网关、配置服务的位置，然后才开始真正的注册。它不证明这台设备属于哪个使用者，也不发放长期凭证。发现成功之后，仍要走注册或预置凭证的校验。把发现到服务当成已经绑定账号，会使同一局域网里的任何设备都显示为已开通。
宣告的内容应是服务类型、实例名和如何继续连接的参数，不要宣告设备私钥或长期令牌。实例名建议使用可与机身对照的标识，方便现场在多台同时宣告时选中目标。与必须人工指定归属的场合相比，扫码入网多一步确认；零配置则把这一步换成“出现在同一网段的列表里”。列表只是候选，选定之后再进入凭证交换。交换应使用短时材料，并在完成后停止继续对外宣告敏感参数。
多播可达且网络允许服务宣告时
这套机制能用的条件很窄：设备和发现它的一方在允许多播的同一二层网络里，或者地址分配服务被明确配置了平台要求的选项。交换机或无线网络把多播滤掉、客户端隔离打开、或者地址分配由不能改选项的上游负责时，设备会停在等待发现，看起来像没有上电。部署前应在目标网络里验证宣告能否被收到，而不是只在办公网验证过就复制到现场。
跨虚拟局域网、跨公网的设备不在适用范围内。它们应使用预先写好的平台地址、专线网关或已经建好的隧道。若现场必须分段，可以由一台允许做发现的网关在本地收集宣告，再代为向平台注册。网关要记录自己是代注册的，平台上的接入路径才不会被误认成设备直连。发现协议本身没有提供足够的身份保证，生产网络里应在发现之后立刻要求证书或设备级密钥，不能长期只靠“能被发现”就保持连接。需要对照证书做法时见证书认证。
把跨网段设备也交给多播发现
现场最常见的失败是：实验室里手机和设备连同一个路由器能自动出现，到了按楼层划分的网络就不再出现。实施人员继续延长等待时间或反复重启设备，问题却在多播到不了另一段。应先判断报文是否跨出了网段。跨不出去就改用明确地址或网关代理，而不是把发现超时从秒改成分钟，让安装界面一直转圈。
另一个错误是设备在发现到第一个应答后就永久写死那个地址。当时应答的可能是一台临时调试网关，第二天不在了，设备再也连不上正式平台，同时又不再重新发现。发现结果应有有效期，失败后退回发现流程，并允许被正式配置覆盖。多个同类服务同时宣告时，若设备总是选信号最强或最先应答的一个，可能选中错误的试验环境。正式环境应要求实例名或标识匹配预注册清单，匹配不上就拒绝，而不是自动加入第一个回答的平台。关闭发现之后，防火墙规则也应收回为这次调试临时打开的多播许可，避免为了安装方便把隔离永久关掉。
安装检查单写明目标网络是否放行所使用的多播或地址选项，并记录验证时收到宣告的接口。没有这条记录，后续故障会被反复当成设备损坏。正式平台的实例名配置在设备预期清单里，设备忽略清单外的应答。调试结束后关闭设备上的持续宣告，只在按下配网键或上电后的短时间窗内宣告，缩短被错误网络发现的时间。