原创文章 · 全文约 6300 字 · 建议阅读 17 分钟 · 技术栈STM32F103C8T6 / NB-IoTM100P/ MQTT / SpringBoot / MySQL / Bootstrap写在前面这套系统解决什么问题。光纤管网的通信人井是城市管线里的「地下节点」井内常年潮湿、通风差一旦积水、缺氧或可燃气体积聚人工下井作业的风险会陡然升高井盖被打开、井内设施被移动这类事件也很难靠人力巡查及时发现。这套系统要做的就是把井下的甲烷、氨气、氧气、水深、电压与温湿度持续送回地面并在越限时立刻声光报警同时给出设备的位置坐标。一句话技术路线。STM32F103C8T6 核心板采集 DHT11 温湿度、MQ-4 甲烷、MQ-137 氨气、AO-03 氧气、电压监测模块、NEO-6M GPS 与 HC-SR04 超声波共七路信号在片内与「参数管理」页下发的五个阈值比对并驱动声光告警模块经银尔达 M100P 走 MQTT 协议上传到自建 emqx服务端为 jeeSite 平台上的 Java / SpringBoot 工程数据落 MySQL前端用 Bootstrap 出 12 项状态卡、两张曲线图、百度地图定位与历史记录列表并把页面改过的阈值与参数反向推回设备。本文的数据从哪来。文中全部引脚分配、参数取值、遥测读数与界面字段逐项取自原理图 PDF 的文字层并用原始出图逐区放大复核、运行中的七张后台截图与三张硬件实拍 —— 不含推测值。凡属按网表或界面归纳之处例如报警判定链均在正文中显式标注为归纳。两处界面取值的口径差异也在文中如实并列、不做合并。一、项目基本情况光纤管网的通信人井是城市管线里的「地下节点」井内常年潮湿、通风条件差既是光缆接头盒的落脚点也是抽水泵与电缆的通道。这一类空间有几个特点让现场维护很被动 ——人下去之前无法确定井内空气是否安全积水、缺氧、可燃气体积聚中的任何一项都可能让一次常规巡检变成事故井盖被打开、井内设施被移动这类事件没有电信号可用主要靠人力巡查周期长、盲区大井内长时间无人供电设备只能靠电池续航因此对功耗与上报节拍都有约束。本项目针对的就是这三点把井下的甲烷、氨气、氧气、水深、供电电压与温湿度持续送回地面在越限时立刻就地声光报警同时把设备位置报到页面上。为了让这套装置在没有市电、也没有网线的井里持续工作技术路线选定了「低功耗主控 NB-IoT 窄带物联网 锂电池供电」这一组合主控只在片内做判定网络只承担「把数据搬过去、把参数搬回来」两件事。1.1 需求方案与技术选型项目的需求方案以一张思维导图的形式确定下来软件、硬件、交付内容三栏都写在同一张图上后续开发即以这张图为依据。图 1 需求方案思维导图软件web / 服务端 / 关键技术、硬件构成 / 关键技术 / 连接模式、交付内容三块图中软件一栏把 web 端的功能写得非常具体一共六项用户注册、用户管理、终端管理、参数设定、实时数据显示、历史数据查询服务端一栏的原文是「后端实现 mqtt 客户端通过与硬件订阅相应的主题实现数据交互」关键技术一栏则点明技术栈为「基于 jeesite 平台java\springboot\mysql\bootstrap 等技术」。硬件一栏分了三层。构成MCU 为 stm32f103传感器包含氨气传感器、甲烷传感器、氧气传感器、超声波传感器、电压检测模块、声光告警模块与 DHT11 温湿度传感器传输模块写的是 C780。关键技术「传输采用 mqtt 协议方式实现服务器采用自建emqx」开发环境为 keil 5。硬件连接模式「扩展板杜邦线连接」—— 也就是说整套装置不需要定制 PCB照着原理图把线插对即可复现。说明方案图「硬件构成」一栏把传输模块写作 C780而原理图里实际使用的是银尔达 M100PNB-IoT 模组项目介绍中写的也是 nbiot_M100。本文与所有自绘图一律以原理图为准写作 M100P原图文字未作改动。1.2 硬件构成与交付内容把方案图与原理图对照起来这套装置的硬件可以分成四组主控、七路采集、通信与告警、电源。七路采集的名单与原理图逐一对应 —— DHT11 温湿度、MQ-4 甲烷、MQ-137 氨气、AO-03 氧气、电压监测模块、NEO-6M GPS 与 HC-SR04 超声波其中超声波承担的是「水深」这一项由井口到水面的距离换算得到因此它同时是一路位置量也是一路液位量。交付内容一栏写了四份材料与一项服务硬件实物、软硬件程序源码、硬件原理图、演示视频以及远程协助环境搭建、程序调试、小修答疑。其中硬件原理图同时提供嘉立创 EDA 的源文件json / schdoc 双格式与 PDF、PNG 出图便于自行改板或复核网表软件开发环境为 Keil 5。这套系统的名称里有「预警」两个字而预警的前提是有一个可改的阈值。原理图上并没有一个拨码开关或电位器来设阈值 —— 所有阈值都在上位机的「参数管理」页里维护经 MQTT 下发到设备。这一点决定了固件侧只能依赖标准 MQTT 语义也决定了「换 broker」这件事的成本只落在通信层。1.3 运行环境与页面清单系统在服务端以 jeeSite 多标签页框架运行本机地址为127.0.0.1:8889共八个可访问路径。下列地址逐字取自浏览器地址栏实际部署时把主机名换成本机地址即可。页面访问地址登录页(c, /a/login)用户注册(c, /account/registerUser)系统主页(c, /a/index)用户管理(c, /a/index#/a/yhgl/yhxx/list#用户管理)终端管理(c, /a/index#/a/zdbh/zdbh/list#终端管理)参数管理(c, /a/index#/a/csox/csox/list#参数管理)实时数据查询(c, /a/index#/a/char/index#实时数据查询)历史数据查询(c, /a/index#/a/facpsp/facpsp/list#历史数据查询)二、系统架构设计2.1 系统功能结构把方案图摊开成三栏能更清楚地看到这套系统里什么是「给用户看的」、什么是「跑在设备上的」、什么是「交付给使用者的」。图 2 系统功能结构Web 上位机功能 / 硬件与通信 / 交付内容第三栏的最后一句是整张图的落点 ——传感器 → STM32 判定 → M100P 上报 → 服务端落库 → 页面出数 → 参数下发。这六个环节构成一条完整闭环缺任何一环系统就退回到「只能看数」或「只能报警」的半成品。本文后续的架构、引脚、报警判定与时序四节都是在把这条闭环逐段摊开。2.2 系统总体架构整套系统自上而下分为五层表现层、服务层、通信层、控制层与数据层。分层的目的不是为了好看而是为了让「换掉其中一层」这件事变得便宜 —— 换 broker、换数据库、改阈值都只需要动一层。图 3 系统总体架构自上而下五层表现层 / 服务层 / 通信层 / 控制层 / 数据层五层之间其实只有两处约定一是上行报文里各分量的顺序二是数据库的表结构。只要这两处不变其余部分都可以独立替换。这也解释了为什么方案图会把 broker 写成「服务器采用自建emqx」而设备侧却毫无特殊处理 —— 在 MQTT 标准语义之下broker 只是一个转发者。值得单独说的是通信层的位置。NB-IoT 在这里不只是「换了一种无线方式」它让设备不依赖现场网线、也不必配一个网关代价是链路带宽小、单次传输的字节数要精打细算因此上行报文只带分量值本身、不带任何冗余描述 —— 分量的顺序与含义由服务端与设备两端共同约定这正是上面说的「第一处约定」。2.3 硬件系统与引脚分配硬件侧的引脚分配是本项目最需要精确的部分。下图中的每一处网络标号都逐条取自原理图 PDF 的文字层含坐标并用原始出图逐区放大核对过 —— 不是为了好看而是因为引脚一旦接错固件写得再对也没用。图 4 硬件系统原理框图七路输入与通信、告警、供电的引脚分配主控引脚连接对象信号类型原理图元件位号PA0MQ-4 甲烷传感器 AO模拟量MQ-4MQ 系列PA1MQ-137 氨气传感器 AO模拟量MQ-137MQ 系列PA2NEO-6M GPS RX串口M1PA3NEO-6M GPS TX串口M1PA4电压监测模块 S模拟量U2PA5AO-03 氧气传感器 AO模拟量U6PA9银尔达 M100P RXD主控 TX串口U3PA10银尔达 M100P TXD主控 RX串口U3PA11DHT11 温湿度 DATA单总线数字量U4PB1声光告警模块数字量输出U5PB10HC-SR04 超声波 TRIG数字量输出HC-SR04PB11HC-SR04 超声波 ECHO数字量输入HC-SR04十二路信号里有四点值得说明。一是模拟量与数字量的分工甲烷、氨气、氧气与电压四路都只用模拟量输出AO 或 S因为这几项要的不只是「有没有」、更是「多少」与之相对超声波用 TRIG / ECHO 两脚纯数字量因为它本质上是「发一次、收回声、量时间差」。二是两个 DO 引脚是悬空的MQ-4 与 MQ-137 的 DO 在图上都空着这不是漏画 —— 既然判定在片内按阈值做就不需要再为两个模块各加一路数字量也不必为它们分别调电位器。三是串口的两处交叉GPS 的 RX 接 PA2、TX 接 PA3M100P 的 RXD 接 PA9、TXD 接 PA10 —— 两处都是「对端收、我端发」交叉接法在这一版原理图上是明确的。四是唯一的输出脚PB1 是全图里唯一用于输出的引脚直接驱动声光告警模块。图 5 嘉立创 EDA 原理图出图STM32F103C8T6 核心板模块、银尔达 M100P、电压监测模块、AO-03 氧气、声光告警模块、升压模块、充放电模块与电池以及 DHT11、MQ-4、MQ-137、GPS、超声波五路传感器原理图右侧的电源部分值得单独看一下因为它解释了这套装置为什么能在没有市电的井里运行。整条链路是3.7V 聚合物锂电池U94000mAh→ 充放电管理模块VIN 5V 输入充电、BAT / BAT- 接电池、VOUT 输出 5V → 5V 轨5V 轨供给主控、DHT11、MQ-4、MQ-137、GPS、超声波与 M100P另有一路 3.3V 升 12V 的升压模块U712V 轨只供 AO-03 氧气模块。电压监测模块本身的 VCC 取自 3.7V 电池测量输入 VO- / VO 跨接在 GND 与 5V 上 —— 也就是说它监测的是 5V 轨的电压这一路读数对应的就是参数表里的「电压阈值 3.6V」。与方案图里「扩展板 杜邦线连接」的描述一致实物形态上并没有定制的载板主控核心板与面包板居中各模块经杜邦线接出。图 6 硬件装置全景STM32F103 核心板与面包板居中四周经杜邦线接出 DHT11 温湿度、MQ-4 甲烷与 MQ-137 氨气传感器绿色载板与金属网探头、HC-SR04 超声波、NEO-6M GPS带 SMA 外接天线、电压监测模块与声光告警模块右侧为蓝色 3.7V 聚合物锂电池由于没有定制 PCB复现门槛很低 —— 照着原理图把线插对即可出问题也容易逐根排查。下面两张是两处最容易被接错的模块特写。图 7 NEO-6M GPS 模块板载陶瓷天线 SMA 外接天线丝印 NEO-6M-001 / UART引脚 VCC / RX / TX / GND / ANT与 HC-SR04 超声波测距模块特写图 8 银尔达 M100P NB-IoT 模组特写模块丝印 M100P-B5屏蔽罩上印 Y100E经杜邦线与核心板相连GPS 模块的两根信号线与天线最容易出问题本图里RX接 PA2、TX接 PA3若接反则表现为「模块上电但一直收不到定位语句」天线必须接上否则在室内几乎定不到位 —— 这也解释了实时数据页上为什么只有地图定位、没有经纬度数字列。2.4 报警判定与参数维护「参数设定」在方案图的 web 功能清单里只是四个字落到实现上却是这套系统里最需要讲清楚的一层。参数管理页一共 7 项配置其中 5 项是阈值恰好对应五路被判定量图 9 报警判定与联动逻辑五个阈值参数氨气 39.54ppm / 甲烷 0.1ppm / 氧气 18% / 电压 3.6V / 水深 45.5cm→ 片内判定链 → 声光告警模块PB1以及参数的两处维护入口参数名称参数项数据库字段类型取值备注氨气阈值thold_nh3139.54—甲烷阈值thold_ch410.1—氧气阈值thold_o2118—电压阈值thold_volte13.6—水深阈值thold_deep145.5—数据间隔thold_interval13—图表数据间隔thold_tbjg210图表显示的数据时间范围(分钟)这 7 项在「参数管理」页可查可改而其中的 5 个阈值与「数据间隔」还能在「实时数据查询」页的阈值设置区直接改每项各有一个「确认」按钮。两条入口对应两种使用场景装机调试时在参数管理页一次配齐运行中临时调整则在实时页上就地改 ——改完点一次确认即下发不必重新烧写固件。「设备定位」也是同一区的设置项可选值为「长鸣」—— 也就是说定位事件靠蜂鸣提示与越限报警共用同一个声光告警模块。这一项名字叫「定位」实际管的是提示方式把它与四项环境阈值放在同一张表里是这套系统里一个容易看漏的设计。说明「越限即声光告警」这一层在本文中属于归纳而非原图直述方案图的硬件清单列了声光告警模块「参数管理」页给了氨气、甲烷、氧气、电压、水深五个阈值恰好对应五路被判定的测量量系统名称也写明「预警」—— 三者合起来指向同一条判定链但原始资料中没有一帧告警视频或报文可直接佐证。阈值并不覆盖全部七路输入这也是需要讲清楚的一点温度与湿度只有显示值、没有阈值项GPS 用于地图定位超声波换算出的水深则确实参与阈值判定。换个角度看七路输入其实分成了三类 ——参与判定甲烷、氨气、氧气、电压、水深、只作观察温度、湿度与只作定位GPS 经纬度。2.5 数据交互时序下面这张时序图把 2.1 节里那条闭环摊开成了一次完整的往返上行从七路采集到页面出数下行从页面改参数到设备下一轮判定。图 10 系统数据交互时序一次采样上报到页面出数再到阈值与参数下发的完整往返上行与下行是两条独立路径。遥测帧由主控主动发阈值与参数由页面发起、经服务端与 broker 到达设备因此断网时设备侧的本地判定仍然照常运行只是页面看不到数、也下不了指令。阈值的往返是闭环里最容易被忽略的一段 —— 页面改完阈值后要先落库、再经下行路径推给设备设备下一轮判定才按新阈值执行。实时页上的 12 项状态卡与上行遥测帧的分量一一对应其中「设备在线」与「电压」两项承载的是链路与供电状态不是环境测量量 —— 前者由服务端按最后上报时间维护后者来自电压监测模块。2.6 软件实现服务端构建在 jeeSite 平台上技术栈为 Java / SpringBoot / MySQL / Bootstrap按方案图的说法服务端要「后端实现 mqtt 客户端通过与硬件订阅相应的主题实现数据交互」。落到实现上服务端的职责可以拆成四件事· 作为 MQTT 客户端订阅上报主题接收设备周期性发来的遥测报文并解析出各传感器分量· 把解析后的采样记录逐条写入数据库同时维护终端的在线状态与最后上报时间· 对外提供查询接口供页面取实时数据与历史记录· 接收页面提交的阈值与参数修改经下发主题推送到设备。前端沿用 jeeSite 的多标签页框架菜单在左、页签在上地址形如/a/index#/a/char/index#实时数据查询切换标签不刷新整页因此在实时数据页停留多久都不会打断数据刷新。页面共八个功能页登录页、用户注册、用户管理、终端管理、参数管理、实时数据查询与历史数据查询以及登录后的系统主页。其中实时数据页右侧直接嵌入了百度地图卫星图把「数据在什么位置」与「数据是多少」放在同一屏里。三、系统界面展示以下七张图取自运行中的系统页面标题、字段名与取值均为原样未作修饰截图中涉及个人信息的姓名、证件号码、电话与家庭住址四列已做不可逆打码处理。3.1 登录页图 11 登录页页面标题「光纤通信管网人井环境监测预警系统」蓝色渐变底表单只保留登录账号与登录密码两项下方另有「注册」入口登录页采用满幅居中版式背景是蓝色渐变表单卡片只保留登录账号与登录密码两项下方「登录」按钮下另有红色「注册」入口通向用户注册页。3.2 用户注册图 12 用户注册页手机号码登记账号、用户姓名、证件号码、联系地址、性别下拉默认「男」、登录密码与再填一次登录密码七项下方为「提交」「返回」用户注册页是一个独立于后台框架的整页表单共七个字段手机号码登记账号、用户姓名、证件号码、联系地址、性别、登录密码与再填一次登录密码。其中手机号码是「登记账号」也就是系统里用户的唯一标识 —— 这一点与后面的用户管理页对得上用户管理页的查询条件正是姓名与电话。3.3 用户管理图 13 用户管理页按姓名与电话检索列为姓名、性别、证件号码、电话、家庭住址、更新时间与操作四列个人信息已打码用户管理页按姓名与电话检索列表共七列姓名、性别、证件号码、电话、家庭住址、更新时间与操作。截面上只有一条记录性别为「男」更新时间为 2025-01-18 16:31姓名、证件号码、电话与家庭住址四列已做不可逆打码。说明这一页是本项目里唯一含真实个人信息的界面。四列 PII 采用「先马赛克再高斯模糊」的不可逆处理性别列「男」与更新时间列保持原样以便正文核对字段结构时仍有可读信息。3.4 终端管理图 14 终端管理页按终端编号、终端名称、安装地址三个条件检索列为终端编号、终端名称、安装地址、online、更新时间与操作当前一条记录终端管理页维持终端与系统的绑定关系查询条件为终端编号、终端名称与安装地址。列表在常见的「编号 / 名称 / 地址」三列之外多了一列online用来直接显示设备是否在线。截面上只有一条记录ZDBH01/ 人井监测终端1安装地址一列显示为「-」online 一列为「在线」更新时间为 2025-01-18 22:07:13。安装地址为空说明该终端尚未登记具体位置 —— 这是可以接受的因为设备自带 GPS实时的位置由地图给出这两个信息是互补的而非重复的。3.5 参数管理图 15 参数管理页标题「配置项管理」7 项配置列为参数名称、类型、参数项、参数值、备注、更新时间与操作参数管理页是整套系统的「控制面」五个阈值、数据间隔与图表数据间隔都在这里。页面标题为「配置项管理」查询条件为配置名称列表共七列参数名称、类型、参数项、参数值、备注、更新时间与操作。七条记录里只有最后一条「图表数据间隔」自带备注原文为「图表显示的数据时间范围(分钟)」—— 也就是说实时页上的曲线并不是全部历史而是按这个分钟数截取的窗口。这也解释了为什么历史页累计已有数千条记录实时页的曲线却只画出一小段。3.6 实时数据查询图 16 实时数据查询页12 项状态卡、阈值设置区氨气 / 甲烷 / 氧气 / 水深 / 数据间隔 设备定位、两张折线图与百度地图 GPS 定位实时数据查询页是这套系统的门面一屏之内解决了三件事看数据、改阈值、看位置。页面标题为「实时状态」顶部给出数据采集时间、更新时间与状态终端下拉框选定「人井监测终端1」后点查询即刷新。该截面采集 2025-01-18 22:07:26、更新 22:07:28的十二项状态如下指标当次取值说明温度27.60℃DHT11 · DATA→PA11湿度14.00%DHT11 · DATA→PA11氨气11.25ppmMQ-137 · AO→PA1甲烷0.03ppmMQ-4 · AO→PA0氧气21.46%AO-03 · AO→PA5水深62.85cmHC-SR04 · TRIG→PB10 / ECHO→PB11电压3.60v电压监测模块 · S→PA4氨气阈值39.53ppm状态卡显示值甲烷阈值0.50ppm状态卡显示值氧气阈值18.50%状态卡显示值水深阈值50.00cm状态卡显示值在线状态设备在线服务端按最后上报时间维护前七项是测量量后四项是阈值最后一项是链路状态 —— 十二张卡片正好把「测到多少」「该到多少」「链路通不通」三件事并列在同一屏。同一屏的下方还有三块内容。阈值设置区氨气 (ppm) 39.54、甲烷 (ppm) 0.1、氧气 (%) 18.0、水深 (cm) 45.5、数据间隔 (秒) 3.0 五组输入框每项各有一个「确认」按钮右侧另有「设备定位」项取值为「长鸣」。图表区并列两张折线图左图标题「温湿度」红线上标出极值点 27.1 与 27、蓝线湿度标出 14右图电化学气体标出 10.66 与 0.03、0.04。所有标注都直接落在曲线上纵轴刻度自适应。地图区右侧是百度地图卫星影像带一枚 GPS 标记标注原文为「【ZDBH01-人井监测终端1 在线 GPS定位】」也就是说「终端 在线状态 GPS 定位」三件事被合并进了同一个标记里。说明页面顶部状态栏在该截面显示「状态正常」而水深实测 62.85cm 高于状态卡上的水深阈值 50.00cm。本文如实并列这两处原文不对二者的判定关系作推断。3.7 历史数据查询图 17 历史数据查询页按终端编号与终端名称检索九列采样记录每页 20 条累计 4855 条历史数据查询页负责回看。查询条件为终端编号与终端名称列表共九列终端编号、终端名称、温度℃、湿度%、氨气ppm、甲烷ppm、氧气%、水深cm与更新时间。与实时页对照可以看到历史表的列就是被持久化的那几路分量 —— GPS 与在线状态没有单独成列前者是定位信息、后者是链路状态都不属于「采样值」。截图首屏可见前两行终端编号温度(℃)湿度(%)氨气(ppm)甲烷(ppm)氧气(%)水深(cm)更新时间ZDBH0127.7014.0011.350.0321.8363.222025-01-18 22:07:31ZDBH0127.6014.0011.250.0321.4662.852025-01-18 22:07:26第 17 行首屏最后一行是27.10 / 14.00 / 11.02 / 0.03 / 21.62 / 64.45时间为 22:06:01 —— 也就是说首屏 17 行全部落在 22:06:01 到 22:07:31 这 90 秒之内与「数据间隔 3 秒」的参数值基本吻合说明采样与落库的节拍是稳定跑着的。页面底部的分页条显示「当前 1 页每页 20 条共 4855 条」页码直达 243 页。按每页 20 条估算这就是连续运行约 4 小时积累下来的采样量对一个无人值守的井下节点来说这个数据量本身也说明采集链路是稳定跑着的。把这一页与实时页对照还能发现一处有意思的细节历史页 22:07:31 一行的水深是 63.22cm而实时页同一时段的读数是 62.85cm两者相差不到 0.4cm甲烷则两处都是 0.03ppm。这说明历史表与实时卡走的是同一条上行链路只是实时卡取的是「最近一次上报」历史表按行累积。四、系统视频展示演示视频完整记录了从设备上电、模组入网到实时数据跳动、在参数管理页与实时页改阈值并生效、越限触发声光告警、地图定位更新的全过程并同时给出上位机页面与硬件装置两侧的画面便于对照「页面上的变化」与「设备上的动作」。图 18 演示视频封面左侧为嘉立创 EDA 打开的原理图右侧为硬件装置实拍视频目录另提供无水印版与水印版两套便于不同用途取用。从封面可以看出演示的组织方式 —— 画面左侧是嘉立创 EDA 打开的原理图右侧是装置实拍演示时把「图纸上怎么接」与「实物上怎么动」放在同一屏里对照复核时不必反复在文档与视频之间来回切换。五、获取方法本文所述系统包含硬件实物、软硬件程序源码、硬件原理图与演示视频四部分材料并可按需提供远程协助环境搭建、程序调试与答疑。如需获取完整资料或就实现细节进一步交流可通过下列方式联系。附界面地址一览下列地址为系统在本机运行时的访问路径端口 8889实际部署时把主机名换成本机地址即可。页面访问地址登录页(c, /a/login)用户注册(c, /account/registerUser)系统主页(c, /a/index)用户管理(c, /a/index#/a/yhgl/yhxx/list#用户管理)终端管理(c, /a/index#/a/zdbh/zdbh/list#终端管理)参数管理(c, /a/index#/a/csox/csox/list#参数管理)实时数据查询(c, /a/index#/a/char/index#实时数据查询)历史数据查询(c, /a/index#/a/facpsp/facpsp/list#历史数据查询)本文为个人开发记录的整理所述系统为面向管网通信人井场景的软硬件一体项目文中所有引脚、参数、取值与界面字段均可在随项目提供的原理图与源码中逐项复核。方案图中把传输模块写作 C780而原理图与实际使用的是银尔达 M100PNB-IoT本文以原理图为准。本文所述系统的引脚分配、参数取值、报文原文与界面字段均逐项取自原理图 PDF 的文字层、运行中的系统截图与硬件实拍不含推测值凡属按网表或界面归纳之处均已在正文中显式标注。