MQTT 主题的写法(强烈不推荐以/开头,会形成空层级)

最新推荐文章于 2025-12-04 17:39:28 发布
转载 最新推荐文章于 2025-12-04 17:39:28 发布 · 39 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://www.cnblogs.com/dirgo/p/19206194
文章标签：

#网络

好的，我们来详细讲解 MQTT 主题的写法、规则以及通配符的使用。这是 MQTT 协议中非常核心和灵活的部分。

1. 主题 (Topic) 是什么？

  • 作用： MQTT 主题是一个UTF-8编码的字符串，是消息的地址标签或路由路径。发布者将消息发送到特定的主题，订阅者通过订阅感兴趣的主题来接收相关的消息。Broker 负责根据主题将消息从发布者路由到正确的订阅者。
  • 结构： 主题由一个或多个主题层级组成，层级之间用正斜杠 / 分隔。层级顺序通常从一般到具体（类似于文件路径或 URL）。
    • 例如：home/livingroom/temperature, factory/building1/machine5/rpm, sensors/+/status, $SYS/broker/clients/connected

2. 主题规则与最佳实践

  1. 区分大小写： 主题名称是区分大小写的。home/temp 和 Home/Temp 是两个不同的主题。
  2. 长度限制： MQTT 协议本身没有硬性规定主题的最大长度，但实际实现（Broker 和 Client 库）通常有限制（例如 65535 字节）。设计时应考虑合理长度。
  3. 允许字符： 主题层级可以使用任何 UTF-8 字符（包括中文、日文等），但以下字符有特殊含义或限制，强烈建议避免在普通主题层级中使用：
    • /： 层级分隔符。
    • +： 单层通配符 (不能单独作为主题发布)。
    • #： 多层通配符 (不能单独作为主题发布)。
    • $： 系统主题前缀。以 $SYS/ 开头的主题通常由 Broker 内部使用，用于发布 Broker 自身的状态信息（如客户端连接数、消息统计等）。客户端通常可以订阅这些主题来监控 Broker，但发布消息时避免使用 $ 开头的主题，以免与系统主题冲突。不同 Broker 的 $SYS 主题结构可能不同。
  4. 空层级： 连续的 /（如 home//temperature）或开头/结尾的 /（如 /home/temp 或 home/temp/）会形成空层级。虽然语法上允许，但强烈不推荐，因为它可能导致混淆和通配符匹配问题。尽量使用明确的层级（如 home/temp）。
  5. 最佳实践：
    • 设计有意义的层级结构： 按照业务逻辑或设备属性组织主题（如 区域/位置/设备类型/设备ID/数据项）。
    • 避免主题泛滥： 不要为每个可能的数据点创建独立的主题，合理使用通配符订阅。
    • 保持简洁： 在保证清晰的前提下，主题层级不宜过深过长。
    • 避免敏感信息： 不要在主题中包含密码等敏感信息（主题内容可能被未订阅的客户端嗅探到）。
    • 明确命名： 使用清晰、一致的命名规范。

3. 通配符 (Wildcards)

通配符允许订阅者订阅一组符合特定模式的主题，是 MQTT 订阅功能强大的关键。有两种通配符：

  1. 单层通配符 + (Plus)：

    • 含义： 匹配该层级的任意一个字符串。只能匹配一层。
    • 位置： 可以出现在主题订阅的任何层级。
    • 示例：
      • 订阅 home/+/temperature：
        • 匹配：home/livingroom/temperature ( + = livingroom)
        • 匹配：home/kitchen/temperature ( + = kitchen)
        • 不匹配： home/livingroom/thermostat/temperature ( + 只匹配一层，这里是 livingroom，后面还有 thermostat 这一层)
        • 不匹配： home/temperature ( + 需要匹配一层，但 home 和 temperature 之间没有层级了)
      • 订阅 +/status：
        • 匹配：sensor1/status ( + = sensor1)
        • 匹配：machineA/status ( + = machineA)
        • 不匹配： building1/floor2/machineA/status ( + 只匹配了 building1，后面还有多层)
      • 订阅 sensors/+/+/battery：
        • 匹配：sensors/floor1/room101/battery (第一个 + = floor1, 第二个 + = room101)
        • 匹配：sensors/outside/gate/battery (第一个 + = outside, 第二个 + = gate)
        • 不匹配： sensors/device123/battery (需要两个层级，这里只有 device123 一层)
        • 不匹配： sensors/buildingA/floor3/room305/battery (只有两个 +，这里有三层 buildingA/floor3/room305)

  2. 多层通配符 # (Hash/Number Sign/Pound)：

    • 含义： 匹配零个或多个层级。它必须是订阅主题字符串中的最后一个字符，且前面必须有 /（除非它是整个订阅字符串）。
    • 位置： 只能出现在订阅主题的末尾。
    • 示例：
      • 订阅 home/#：
        • 匹配：home/livingroom/temperature ( # 匹配了 /livingroom/temperature)
        • 匹配：home/kitchen/humidity ( # 匹配了 /kitchen/humidity)
        • 匹配：home ( # 匹配了零个层级 - 注意： home 和 home/ 是不同的主题！home/# 会匹配 home/... 但不直接匹配 home，除非 Broker 特殊处理或主题是 home/。更安全的做法是如果需要匹配 home 本身，单独订阅 home 或使用 home 和 home/# 两个订阅。)
        • 不匹配： house/garage/temperature (主题必须以 home 开头)
      • 订阅 sensors/#：
        • 匹配：sensors/temperature ( # 匹配了零个层级？不，sensors/temperature 是 sensors 下的一个层级，# 匹配了 /temperature)
        • 匹配：sensors/building1/floor2/room301/humidity ( # 匹配了 /building1/floor2/room301/humidity)
        • 匹配：sensors (同上 home 的情况，sensors/# 通常不直接匹配 sensors，除非是 sensors/)
      • 订阅 #： (非常危险！谨慎使用！)
        • 匹配：Broker 上所有主题的消息（包括系统主题 $SYS/...）。
        • 后果： 客户端将收到海量可能无关的消息，消耗大量网络带宽、CPU 和内存资源。也可能收到敏感信息。仅在调试或绝对必要时使用，生产环境强烈避免。

4. 重要注意事项

  1. 通配符仅用于订阅： 客户端只能在 SUBSCRIBE 数据包的主题过滤器中使用 + 和 #。在 PUBLISH 数据包的主题名中不能使用通配符！发布主题必须是明确的、不含通配符的字符串。
  2. $SYS 主题与通配符：
    • 订阅 # 或 $SYS/# 会收到 $SYS/... 主题的消息。
    • 订阅 +/monitor 不会匹配 $SYS/broker/monitor，因为 $ 是一个普通字符，+ 匹配了 $SYS，但下一层 broker 没有被匹配到模式 +/monitor (broker/monitor 是两层)。
    • 要订阅所有 $SYS 下的主题，用 $SYS/#。
  3. 匹配是逐层进行的： Broker 在匹配主题时，是严格按照层级和通配符规则逐层比较的。
  4. 性能影响： 大量使用通配符（尤其是 #）订阅会增加 Broker 路由消息的计算开销。设计主题结构时应考虑平衡灵活性和效率。
  5. 安全性： 通配符订阅可能让客户端意外订阅到包含敏感信息的主题（如果主题设计不当或存在恶意发布者）。使用 MQTT 的认证和授权机制（用户名/密码、客户端证书、ACL）来严格控制客户端对主题的发布和订阅权限至关重要。

总结：

  • 主题是地址标签，用 / 分隔层级。
  • + 匹配一层中的任意字符串。
  • # 匹配零层或多层，必须放在订阅主题末尾。
  • 通配符只能用于订阅，不能用于发布。
  • 设计清晰、有层次的主题结构，谨慎使用通配符（特别是 #）。
  • 始终考虑安全性和性能。

理解并熟练运用主题和通配符是构建高效、灵活 MQTT 应用的基础。务必根据你的具体业务场景仔细设计主题命名空间。

MQTT 主题的写法(强烈不推荐以/开头,会形成空层级) - dirgo - 博客园

Mqtt入门之主题与主题过滤器
04stone37
11-28 4466
主题Topic　　主题是一个UTF-8字符串，由一个或多个主题级别组成， 每个主题级别之间由正斜杠（主题级别分隔符）分隔，如下图所示： 主题过滤器TopicFilter　　含有通配符的主题，目的是让客户端同时订阅多个主题。通配符　　当客户端订阅主题时，它可以使用消息发布到的确切主题，或者可以使用通配符同时订阅更多的主题。 通配符只能在订阅主题时使用，并且在发布消息时不允许使用。单级通配符+　　+表
MQTT学习笔记（5）报文分析之SUBSCRIBE
jiang_2018的博客
09-08 7975
SUBSCRIBE（订阅主题） 含义：客户端向服务器该报文用于订阅一个或者一类topic或者多类tpoic。 一.固定报头 0x82 剩余长度 二.可变报头 报文标识符 三.payload 主体过滤器（Tpoic Filter） 服务质量要求（Qos） … 注：payload可以是多个Tpoic Filter，但是每个Tpoic Filter后面要有一个Qos ...
mqtt 获取所有topic_MQTT——订阅报文
weixin_39842682的博客
12-19 4282
我们已经把相关的连接报文搞定了。笔者想来想去还是决定先讲解一下订阅报文(SUBSCRIBE )。如果传统的通信方式是客户端和服务端之间一般就直接传输信息。但是MQTT的通信方式是通过发布/订阅的方式进行的。笔者不知道他是否跟设计模式中的发布订阅模式有没有关系。可是他们思想却有一点相似之处。客户端知道服务上有很多个主题。就好比如说有很多消息的分类一样子。有社会新闻、体育讲坛等。那么客户端只要找到自己...
MQTT主题
Ryan爱吃糖的博客
03-19 1598
MQTT与服务器通讯
weixin_45854148的博客
08-08 1128
摘要：本文详细介绍了MQTT 3.1.1协议的核心功能与实现要点，包括协议特性、消息模型、主题规则、QoS级别、遗嘱机制等关键技术。同时提供了基于STM32+ESP8266的物联网终端实现方案，通过温湿度传感器采集数据并上传至OneNET平台。内容涵盖协议报文解析、主题设计规范、错误处理建议，以及完整的硬件连接方案和代码实现（包括DHT11驱动、ESP8266通信、MQTT报文打包等模块），为物联网开发者提供了从协议理解到落地的完整参考。
C++14中你不可不知的编码利器：二进制字面量与‘之间的性能陷阱（实战案例）
VarPerch的博客
10-31 250
掌握C++14二进制字面量与数字分隔符，提升代码可读性与维护效率。适用于底层开发、配置寄存器等场景，通过0b前缀和单引号分隔增强数值表达清晰度。实战案例揭示潜在性能陷阱及规避方法，值得收藏。
带有“非简单参数”的函数为什么不能包含 "use strict" 指令
weixin_34238642的博客
11-01 226
非简单参数就是 ES6 里新加的参数语法，包括：1.默认参数值、2.剩余参数、3.参数解构。本文接下来要讲的就是 ES7 为什么禁止在使用了非简单参数的函数里使用 "use strict" 指令： function f(foo = "bar") { "use strict" // SyntaxError: Illegal 'use strict' directive in functi...
Java物联网技术知识点总结（持续更新中...）
weixin_44268936的博客
09-13 2109
物联网领域Java开发知识点归纳
IoT开发实战：CoAP卷 学习笔记
WifeJ的博客
03-15 3093
IoT开发实战：CoAP卷第一章REST风格CoAP简介MQTT协议简介第三章IPv4首部IPv6首部 第一章 REST风格 REST（具象状态传输）是Roy Thomas Fielding博士于2000年在他的博士论文“Architectural Styles and the Design of Network-based SoftwareArchitectures”中提出来的一种Web软件架构风格。目前在三种主流的Web服务实现方案中，REST模式与复杂的SOAP和XML-RPC相比更加简洁，越来越多的
在springboot 中 这个值， @Value(“${mqtt.default-topic:health/data}”) private String defaultTopic;。 我想订阅 类似这样 iot/{厂家标识}/{设备类型}/{设备唯一ID}/upload 厂家下所有消息，应该怎么写？
11-06
并且希望**订阅某个厂家下所有设备的所有消息**（即通配整个厂商的层级结构），那么你需要理解 **MQTT 主题通配符** 和 **Spring 的 `@Value` 不支持动态变量替换 `{}`** 这两个关键点。 --- ## 重点说明 1. `@...
MQTT主题命名规范与通配符运用：ESP32项目可扩展性的6大设计原则，90%开发者踩过的坑
![ESP32第一个MQTT通信...一个良好的主题结构不仅需清晰表达语义层级，还需预判未来设备规模增长带来的管理复杂度。随着ESP32等嵌入式平台在智能家居、工业传感等场景的大规模部署，静态、扁平化的主题命名已难以支撑
智能家居中MQTT主题设计的7条黄金法则：实现高效解耦与未来可扩展性
在典型智能家居系统中，MQTT Broker作为消息中枢，连接各类终端设备——从温控器到智能灯泡，所有节点通过预定义的主题（Topic）进行数据交换，形成可扩展、易维护的分布式架构。 ```mermaid graph TD A[智能灯泡]...
vue实现页面不断插入内容并且自动滚动功能
最新发布
weixin_50606255的博客
12-04 279
我们在看视频时经常会看到黑客入侵别人电脑会在屏幕上显示一串代码，并且代码不断插入自动滚动，看起来很厉害的样子，现在就在此纪录实现此功能：
网络安全漏洞之React 框架分析
anquan2233的博客
12-04 1185
昨日爆出的 CVE-2025-55182，CVSS 10.0 满分严重漏洞，影响 React 19 及所有 Next.js 15/16 项目。核心问题是 React Server Components 的 Flight 协议存在不安全反序列化，无需任何认证，攻击者只需向 Server Actions 端点发送一个精心构造的 multipart 请求，即可实现远程代码执行（RCE）。目前已确认多个完整 0day 利用链（包括 vm.runInThisContext 在内），未修补实例基本等于已失陷。
【Android逆向工程】第19章：协议分析与接口还原
w987333120的博客
12-03 419
本文介绍了网络协议分析的关键技术与工具。主要内容包括HTTP/HTTPS协议分析流程、常用抓包工具配置（Charles/Burp Suite）、协议格式解析方法以及签名算法还原技术。通过示例展示了完整的请求/响应分析过程，涵盖请求行、请求头、请求体的解析方法，特别关注签名相关字段的识别。文章还提供了Python代码示例演示如何自动分析HTTP请求结构，帮助逆向工程师理解业务逻辑、还原接口签名算法并实现自动化脚本。
网络安全（黑客技术）—2025自学手册
2401_84760527的博客
11-24 1683
网络安全可以基于攻击和防御视角来分类，我们经常听到的 “红队”、“渗透测试” 等就是研究攻击技术，而“蓝队”、“安全运营”、“安全运维”则研究防御技术。走安全行业的工程方向的，技术上面其实有很大的重叠性，抛开甲乙方、岗位名称、岗位职责等因素来看，作为学技术的，也根据以往我们给学员推荐就业和入职情况来看，只要好好掌握以下几种技术（网络协议与安全设备、Linux操作系统、Web服务部署/开发、主流渗透测试/安全工具、一门及以上的编程语言）中的2到3个，都可以较好的胜任工作需求。
openEuler + Nginx 高性能 Web 服务深度评测
笃行其道的博客
12-03 1053
本文介绍了在openEuler操作系统上部署Nginx集群的性能测试方案。通过优化内核参数、资源限制和系统调优，在32核64GB环境的华为云实例上进行八大维度的压测：静态文件服务测试显示小文件QPS达23万+，大文件传输速率13.97GB/s；反向代理性能测试QPS23万；HTTPS测试降幅仅16%；长连接测试QPS8.6万；压缩测试显示99%压缩率；极限测试支撑10万+并发。测试结果表明，openEuler的网络/I/O优化与Nginx事件驱动架构完美结合，CPU利用率96%且内存占用<10%，延迟
学习：《The QUIC Transport Protocol: Design and Internet-Scale Deployment》
qq_45913654的博客
12-02 815
QUIC协议是基于UDP的新型传输协议，旨在解决TCP协议在互联网环境中的固有缺陷。
【路由器】路由
weixin_43202230的博客
12-03 1214
RIB是"控制平面"的所有候选路由；FIB/CEF是"数据平面"的高效查表，用来线速转发。RIB：保存所有候选与策略，用来"选路"。存"所有可能"。FIB：保存选好的最优结果，用来"高速转发"。存"现在就用的"。每个报文查询的是转发表，而非路由表，只是转发表由路由表更新得到。
MQTT主题esl/+和esl/#的含义有什么不同
08-19
<think>我们正在讨论MQTT主题的通配符问题。用户询问了主题esl/+和esl/#的区别。 根据MQTT协议，主题通配符有两种： 1. 单级通配符：+ 2. 多级通配符：# 具体区别： - esl/+：匹配仅一级子主题，例如： esl/a -> 匹配 esl/b -> 匹配 esl/a/b -> 不匹配（因为有两级） - esl/#：匹配所有子主题（包括零级、一级、多级），例如： esl -> 匹配（注意：esl本身是零级？实际上，按照MQTT规范，esl/#会匹配esl/以及esl/后面的任意多级，但注意esl本身并不匹配，因为#必须匹配至少一个主题层级，且#必须出现在主题分隔符之后。但是，esl/#会匹配esl/开头的所有主题，包括esl/a, esl/a/b等。然而，esl本身不会匹配，因为esl/#需要以/分隔，所以esl/#匹配的是esl/后面跟着任意多级（包括零级？）实际上，根据规范，esl/#可以匹配： esl/（注意，这是一个主题，但通常我们不这样写） 实际上，更准确的说法是：esl/#匹配所有以esl/开头的主题。例如： esl/a esl/a/b esl/a/b/c 但是，它不会匹配主题名为esl（没有斜杠）的主题。 然而，根据MQTT规范（3.1.1）： - 多级通配符（#）必须位于主题过滤器的最后，并且它匹配该级别和所有子级别。例如，主题过滤器"esl/#"将匹配： "esl" -> 不匹配（因为#必须匹配至少一个主题层级，并且#前面有一个分隔符，所以它要求主题在esl后面必须有一个层级，即使这个层级是空字符串也不行？实际上，规范中明确说明：主题层级分隔符是必须的。因此，主题过滤器"esl/#"匹配的主题包括： "esl" -> 不匹配（因为#前面有分隔符，所以它要求主题在esl后面必须有一个分隔符，然后才是任意子级。所以，实际上，主题"esl"不会被匹配） "esl/" -> 匹配（这里有一个层级，即空字符串，但这是一个层级） "esl/a" -> 匹配 "esl/a/b" -> 匹配 但是，通常我们不会使用空层级。所以，更常见的理解是： - esl/# 匹配所有以"esl/"开头的主题（包括后面任意多级，但主题必须以esl/开头，后面可以跟任意多个层级，每个层级可以是任意字符串，包括空字符串？但通常层级不为空） 然而，根据规范，主题层级不能为空（即两个连续的斜杠，或者开头或结尾的斜杠？）。实际上，MQTT主题是UTF-8字符串，主题层级分隔符是斜杠（/），主题层级可以包含空字符串吗？规范中并没有明确禁止，但是实际使用中，我们通常避免使用空字符串作为层级。 因此，为了准确起见，我们重新表述： - 主题过滤器 "esl/+" 匹配： esl/<任意一个非空字符串> （注意：+匹配一个非空的层级？实际上，+匹配一个层级的任意字符串，包括空字符串？但规范中，主题层级可以是空字符串吗？） 规范并没有禁止主题层级为空。但是，在大多数实现中，我们通常使用非空的层级。所以，我们按照规范，+匹配一个层级的任意字符串（包括空字符串），而#匹配后面所有层级的任意字符串。 但是，请注意：主题过滤器"esl/+"可以匹配： "esl/" -> 这个主题的第二个层级是空字符串，所以匹配 "esl/a" -> 匹配 "esl/a/b" -> 不匹配（因为有两个层级） 而主题过滤器"esl/#"匹配： "esl" -> 不匹配（因为#前面有分隔符，所以要求主题必须至少有两个层级：第一个是esl，第二个是任意（包括空）并且后面可以任意） "esl/" -> 匹配（因为#匹配零个或多个层级，这里匹配了一个空层级） "esl/a" -> 匹配 "esl/a/b" -> 匹配 但是，注意：规范中，主题过滤器"esl/#"也会匹配"esl"吗？答案是不匹配。因为主题过滤器"esl/#"中的#表示“所有以esl/开头的主题”，所以主题"esl"并不以esl/开头，因此不匹配。 总结： 通配符 | 匹配规则 ------|--------- + | 匹配一个层级的任意字符串（包括空字符串） # | 匹配零个或多个层级的任意字符串（必须位于主题过滤器末尾，且前面必须有分隔符） 因此： - "esl/+"：匹配主题如"esl/", "esl/a", "esl/b"，但不匹配"esl"（因为没有斜杠后的层级），也不匹配"esl/a/b"（因为有两个层级）。 - "esl/#"：匹配主题如"esl/"（注意：这里有一个空层级）、"esl/a", "esl/a/b", "esl//b"（两个斜杠中间为空）等，但不匹配"esl"（因为缺少斜杠和后面的层级）。 然而，在用户给出的例子中，主题是"esl/+"和"esl/#"，所以： 订阅主题"esl/+"：将接收到所有在esl主题下直接一级子主题的消息（例如：esl/topic1，esl/topic2，但不包括esl/topic1/subtopic）。 订阅主题"esl/#"：将接收到所有以esl/开头的主题的消息（包括多级子主题，例如：esl/topic1, esl/topic1/subtopic, esl/topic2/sub1/sub2等）。 注意：在MQTT中，主题是区分大小写的，并且斜杠（/）是层级分隔符。 引用说明：在回答中，我们参考了MQTT协议规范（3.1.1版本）[^1]。 现在，我们根据用户的问题，给出回答。</think>### MQTT主题 `esl/+` 和 `esl/#` 的区别详解 在MQTT协议中，`+` 和 `#` 是**主题通配符**，用于订阅匹配特定模式的主题。它们的核心区别在于**匹配层级深度**： #### 1. `esl/+`（单级通配符） - **匹配规则**：仅匹配**单一级别**的子主题 - **有效示例**： - `esl/temperature` ✅ - `esl/humidity` ✅ - **无效示例**： - `esl` ❌（缺少子级） - `esl/room1/temperature` ❌（多级子主题） - **特点**：精确匹配单层子主题，类似正则表达式中的单字符匹配 #### 2. `esl/#`（多级通配符） - **匹配规则**：匹配**任意层级（0-N级）** 的子主题 - **有效示例**： - `esl` ✅（零级子主题） - `esl/temperature` ✅ - `esl/room1/sensor/temperature` ✅ - `esl/buildingA/floor3/room5/humidity` ✅ - **限制**：必须位于主题末尾（如 `esl/#` 有效，但 `esl/#/sensor` 无效） - **特点**：类似文件系统的递归目录匹配 --- ### 对比总结 | 特性 | `esl/+` | `esl/#` | |--------------|-----------------------------|-----------------------------| | **匹配深度** | 仅单一级别 | 任意多级（含零级） | | **层级要求** | 必须存在一级子主题 | 可匹配无子主题的情况 | | **类似概念** | 文件系统中的单层目录 | 递归目录匹配 | | **使用场景** | 精确控制单层设备/传感器 | 批量监控多层级设备体系 | --- ### 实际应用示例 假设有以下主题： ```bash esl esl/office esl/office/temp esl/factory/machine1 ``` - **订阅 `esl/+` 将收到**： ```bash esl/office ✅ esl/factory ✅ ``` （不包含 `esl` 或带多级子主题的消息） - **订阅 `esl/#` 将收到所有**： ```bash esl ✅ esl/office ✅ esl/office/temp ✅ esl/factory/machine1 ✅ ``` > ⚠️ **注意**：通配符主题可能引发消息风暴，生产环境中建议配合[主题权限控制](引用[1])使用前缀限制（如 `^{username}-esl/#`）[^1]。 --- ### 相关问题 1. MQTT主题通配符在权限控制中如何与用户名联动？[^1] 2. 如何通过ESL（Event Socket Library）监控MQTT消息？[^2] 3. RabbitMQ中如何配置MQTT主题的访问权限？ 4. 多级通配符 `#` 在大型物联网系统中可能引发哪些性能问题？ [^1]: 主题权限支持变量扩展（如username, vhost）[^1] [^2]: ESL可用于连接消息中间件事件接口[^2]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值