能否在Info.plist的Bonjour服务配置中使用通配符？动态服务名适配咨询

iOS14及以上版本的Bonjour权限校验是系统层静态白名单机制，NSBonjourServices字段仅支持精确的服务类型字符串匹配，完全不支持通配符语法。只要你尝试发布或浏览的服务类型不在Info.plist的精确声明列表里，系统会直接在网络栈层面拦截请求，不会给任何运行时权限——这也是之前尝试用_*._tcp通配符定义服务类型完全不生效的核心原因。
同时原来的设计把完整本地IP作为服务类型后缀，本质上是不可枚举的（单是常见的192.168.x.x网段就有超过6万个可能的服务类型值），根本不可能在Info.plist里穷举所有值，本身就和iOS14的权限规则存在天然冲突。

方案1：将动态IP标识从服务类型迁移到TXT记录（推荐） #

这是Bonjour服务最标准的用法，改动量小，兼容性最好：

• 全局定义一个固定不变的合规Bonjour服务类型（比如_yourapplocal._tcp），把这个字符串加入所有新老版本App对应的NSBonjourServices数组中，后续不管网络环境怎么变，这个服务类型永远不会调整。
• 原来需要拼在服务类型里的IP地址、设备标识这类动态信息，不要嵌入服务类型，改成在服务发布时，通过TXT记录的键值对挂载：比如在A设备发布服务时，设置TXT记录内容为["deviceIP": "192.168.33.20", "deviceUniqueID": "xxx"]。
• B设备不需要动态拼接服务类型，直接浏览这个固定的全局服务类型即可，扫描到同类型的所有在线服务后，读取每个服务附带的TXT记录，匹配目标IP对应的设备完成连接。
• 兼容旧版本的过渡逻辑：新版本的A设备可以同时发布两个服务——一个是新的固定全局服务类型（带TXT动态标识），另一个是旧版本逻辑对应的动态长IP服务类型。这样没升级的旧版B设备，还是能按原来的规则搜到A设备，不会出现连接中断。等旧版本用户占比降到极低水平后，再移除旧的动态服务发布逻辑即可。

方案2：如果坚持保留IP作为服务后缀的设计，可压缩服务类型长度做静态枚举 #

Bonjour服务类型的规范要求，服务名部分（就是下划线后、传输协议前的部分）最长不能超过15个字符，原来拼完整12位IP的写法本身就已经接近长度上限，完全没有枚举空间。

• 调整服务名规则，只取本地IP的最后一段（范围1-255）作为服务名，比如IP为192.168.33.20时，对应服务类型为_20._tcp，这个长度完全符合规范。
• 把_1._tcp到_255._tcp一共255个精确的服务类型字符串，全部添加到新版本App的NSBonjourServices数组中。苹果没有限制这个数组的元素数量，255个短字符串对Info.plist的体积影响可以忽略，完全不会有性能问题。
• 兼容旧版本的逻辑：新版本A设备继续保留旧的长IP服务类型发布逻辑，这样旧版B设备还是能正常发现A设备；等所有用户升级到新版本后，再根据上线节奏调整B设备的搜索规则，从搜索长IP类型切换到搜索短后缀类型即可。

• 很多开发者误以为NSBonjourServices只需要声明浏览的服务类型，实际上系统规则是：不管是发布还是浏览的服务，只要不在这个数组里，都会被系统拦截。如果A设备要发布动态服务类型，必须把对应类型加入plist的声明列表，不然iOS14以上的系统根本不会让你的服务发布成功。
• TXT记录的单条服务总大小限制为1KB，存IP、设备名这类小字段完全够用，不要往TXT记录里塞大体积的内容，否则会导致服务发布失败。
• 不要尝试用动态修改Info.plist、调用运行时接口拿权限的方式绕过校验，这个校验是在系统网络框架层做的，没有公开的运行时接口可以绕过，所有不经过plist静态声明的服务类型请求，都会被系统直接拒绝。

内容的提问来源于stack exchange，提问作者May