集中式空调需求响应信息模型：从统一建模到可削减功率计算

简介这份PDF文档是T/CEC 239.1—2019《电力需求响应信息模型 第1部分集中式空调系统》标准原文面向电力需求响应终端与接口研发、智能电网负荷调控、集中式空调系统集成等岗位的技术人员也可供高校电气与能源类专业师生查阅。标准围绕建模原则、数据类型、通用包和专用包展开明确自动需求响应终端及接口设计所需的信息类、属性与类间关系并给出需求响应能力计算方法的资料性附录可用于评估集中式空调负荷的调节潜力。资源包共1个PDF文件大小约396KB内容完整、便于检索适合在方案设计、设备接入和软件开发时对照查阅对终端数据点定义、通信接口联调及节能控制策略落地均有直接参考意义。目前已有306人学习可作为理解集中式空调参与需求响应业务建模与接口实现的参考文本。1. 一条削峰指令卡在对点表上集中式空调需求响应模型要解决的问题一栋五万平方米的商业综合体夏季午后主机加上冷冻水泵、冷却水泵、冷却塔风机能占到整栋楼用电的四成以上。电网侧下发一条削峰指令楼宇自控那边给的是现场总线点位需求响应主站要的却是“这台机组接下来两小时能削减多少千瓦、能撑多久”——两边的字段对不上项目就卡在对点表上每换一栋楼、每换一个品牌重新对一遍。电力需求响应信息模型要收束的正是这件事把集中式空调系统参与需求响应的对象、属性、关联关系用一套统一的类描述出来让自动需求响应终端和接口按同一份语言开发数据一次建模、多处复用。它服务的读者很具体做需求响应终端或主站接口开发的工程师以及拿这个方向做毕设、课设、课程设计的学生。集中式空调是这套系列模型的第一部分也是最有代表性的一部分因为它同时包含刚性启停和柔性调节两类可调能力。2. 建模原则与数据类型四条约束如何定住一套可复用类型2.1 实用性、便捷性、适用性、扩展性分别约束了什么建模原则听起来像套话但在这个领域每条都对应一个真实的设计取舍落不到代码上就会在联调阶段加倍还回来。实用性约束的是“模型要能直接支撑终端和接口开发”。这意味着不能把模型写成设备说明书的电子化版本属性必须能映射到终端采集点上。比如实时信息类里只保留电压、电流、频率、有功、无功、主机负载率六项是因为这六项在主流终端上都有现成的采集通道再加就会逼着开发者去造数据。便捷性约束的是“参数要能从现场拿到”。额定参数里选的是建筑面积、平均层高、COP、EER、建筑物能量损失系数这些在竣工图纸和设备铭牌上都有出处。反过来像“围护结构传热系数”这种需要做热工计算才能反推的量建模时就不会放进来——放了等于给现场出难题。适用性要求覆盖水冷、风冷、多联机这三类主流形式并且能对接不同品牌的机组。所以集中式空调类型被单独抽成枚举组成部件被拆成主机机组、冷热水泵、冷却水泵这样通用性最强的几类而不是按某个厂家的内部编号来建。扩展性是最容易被忽略、又最容易被现场逼出来的一条。每条枚举末尾都留了x-{User-defined}形式的扩展位含义是标准覆盖不到的设备形态允许用自定义字面量补但必须带x-前缀这样解析端可以按前缀分流既不破坏已有取值也不用每来一个新设备就改一版规范。提示扩展位不是随便加的。我一般要求团队在写扩展值时同步维护一张映射表记录x-后面的自定义名对应哪家设备、哪个型号否则半年后没人认得这些字段。2.2 复合型的 value/unit/multiplier 三段式功率为什么不能只写一个数数据类型分三层基本型、复合型、枚举型。基本型只有六种——整型、字符串UTF-8 编码、浮点、布尔、日期时间、持续时间。前四种没什么可说的后两种的格式坑留到避坑章展开。真正决定模型能不能跨系统交换的是复合型。以有功功率为例它不是简单一个 Float而是由value、unit、multiplier三个属性组成value是浮点数值unit固定为瓦特multiplier从乘数单位枚举里选表示量纲缩放。这样设计的好处是单位永远不变、缩放单独表达避免出现“这个字段到底是 kW 还是 W”的扯皮。from dataclasses import dataclass from enum import Enum class UnitMultiplier(Enum): 乘数单位对应标准中的 UnitMultiplier 枚举 m 1e-3 # 毫千分之一 c 1e-2 # 厘百分之一 d 1e-1 # 十分之一 k 1e3 # 千 M 1e6 # 兆 G 1e9 # 吉 dataclass class ActivePower: 有功功率复合类型value 固定单位 W 乘数单位 value: float multiplier: UnitMultiplier UnitMultiplier.k # 现场习惯按 kW 上报 property def unit(self) - str: # unit 是常量业务侧不允许改成 kW否则跨系统对不齐 return W def to_watt(self) - float: 统一折算到瓦特用于入库和比对 return self.value * self.multiplier.value def to_kw(self) - float: return self.to_watt() / 1000.0这段代码的逻辑是unit被固定成常量任何折算都通过multiplier完成。参数上要注意两点一是multiplier的默认值选k是因为国内终端上报功率普遍用 kW但存库和计算必须回到 W二是to_watt()出来的值才是可比对的基准所有跨设备的求和、排序都应该先走这一步。踩过的坑是有人在解析时直接把value当瓦特用结果一台 800 kW 的机组被当成 800 W需求响应能力直接缩水一千倍。按同样的结构电压、电流、频率、视在功率、有功电能、无功功率、温度、比热容、热阻、压力、容积、密度、流量、风速、光照强度、热值、转速都各自定义成复合类型。它们的unit都是常量唯一能变的是multiplier这就把“单位一致性”这件事从业务代码里彻底抽走了。2.3 枚举型与扩展位单位符号、乘数单位和用户类型枚举型分两类用途。一类是给复合型服务的比如单位符号枚举列出伏安、瓦特、乏、瓦时、伏特、安培、摄氏度、帕、赫兹、摄氏度每瓦特、焦耳每千克每开尔文、立方米每秒、立方米、千克每立方米、转每分钟、米每秒、勒克斯、焦耳每千克这些字面量另一类是给业务对象服务的比如用户类型分工业、商业、居民通信方式分本地人机界面、本地通信端口、本地无线、本地有线、远程无线。业务枚举里最值得单独说三个。第一个是通信方式它其实是在回答“这台设备的数据从哪来”本地通信端口指向 RS232/RS485 这类串口本地无线指向 WiFi、蓝牙或微功率无线远程无线指向 4G 这类通道建模时选错会让终端误判走哪条链路。第二个是底层通信协议只列了以太网传输控制协议、工业现场总线、楼宇自控网络数据通信协议三项加扩展位这个粒度是刻意的——再往下细分到波特率、寄存器地址就不属于信息模型的范畴了。第三个是需求响应项目类型分时电价、尖峰电价、实时电价、可中断响应、直接负荷控制、需求侧竞价这决定了合约信息类里能关联哪些项目。{ EqName: 离心式冷水机组, EqID: AC-01-MAIN, SupplierName: 某设备厂商, BrandName: 示例品牌, DeviceModel: MODEL-X, ProductNum: SN20240001, ProductDate: 2024-03-15T09:30:00.00008:00 }上面这段是设备出厂信息类的最小报文示例字段与属性表一一对应。要注意ProductDate用的是带时区偏移的日期时间格式T分隔日期和时间毫秒保留三位末尾的08:00表示本地时区相对协调时间的偏移。写成2024-03-15 09:30:00这种数据库风格在跨系统解析时大概率会失败。3. 通用包拆解设备、用户、自动化能力与合约四类信息3.1 EQProductInfo 与 EQUserInfo设备身份和用户身份必须分开建通用包解决的是“所有负荷类型都绕不开”的那部分信息所以它不放在专用包里。设备出厂信息类管设备身份用户信息类管用户身份两者拆开是有意为之。设备出厂信息类包含设备通用名称、设备 ID、生产厂家名称、品牌、型号、出厂编号、出厂日期。其中设备 ID、生产厂家名称是必选品牌、出厂编号、出厂日期是可选项。这个必选/可选的划分在实施时很有讲究设备 ID 必须全局唯一且稳定我一般要求用“楼栋-楼层-机组类型-序号”的拼接规则避免和厂家序列号混用品牌做可选是因为部分项目采购的是集成商贴牌机组铭牌上根本没有独立品牌信息。用户信息类包含用户名称、用户类型、所属行业、用户编号、关口电表表号、用户地址外加经纬度和设备启用日期两个可选项。这里的关键约束是用户编号必须与电网侧分配给用户的用电客户编号一致关口电表表号必须与计量档案一致。这两条不是技术选择是业务硬约束——对不上需求响应指令就无法落到结算主体上。注意用户地址和经纬度在模型里是两套并存的定位信息经纬度可选但不能用来替代地址。实测过一些终端只存经纬度结果在生成响应报告时因为缺少行政区划信息被退回。3.2 EQAutoAbilityInfo判断一台空调能不能被调度这个类是整个模型里最有“前置体检”味道的一个。它用四个布尔量和三个枚举回答一个问题这台设备具备什么样的自动化能力。通信能力布尔量表示设备是否支持与外界通信支持则为真。通信方式枚举对应前面说的五种通道。需求响应协议枚举表示设备直接与远程主站交互时用的协议取值包括上一层的行业信息交换规范、开放自动需求响应标准的两个版本以及扩展位。底层通信协议枚举表示设备与本地终端、网关之间或与远程主站之间的传输协议。剩下三个布尔量是能力判定的核心刚性控制能力表示设备是否支持启停这类开关式控制柔性调节能力表示设备是否支持功率连续调节第三方平台标志表示设备是否已经接入某个第三方主站平台。这三项组合起来基本能推出这台设备适合参与哪种需求响应项目——只有刚性能力的走直接负荷控制有柔性能力的才谈得上可中断响应和需求侧竞价已经接了第三方平台的要先解决指令归属问题再谈接入。def classify_capability(info: dict) - str: 根据自动化能力信息给出可参与的项目类型建议 info 需包含 ComAbility、On-OffAbility、Flexability、ThirdPartyPlatform if not info.get(ComAbility): return 不具备远程调度条件仅可做本地控制 if info.get(ThirdPartyPlatform): return 已接入第三方平台需先明确指令优先级 on_off info.get(On-OffAbility, False) flex info.get(Flexability, False) if on_off and flex: return 可参与刚性控制与柔性调节类项目 if on_off: return 仅可参与直接负荷控制类项目 if flex: return 仅可参与功率调节类项目 return 无可调度能力这段判断逻辑把三个布尔量的组合穷举了一遍参数说明上要注意ThirdPartyPlatform的优先级高于能力判断——设备能力再强指令通道被别人占着也用不了。实际项目里最常见的误判是只看柔性调节能力就下结论忽略了刚性控制能力缺失会导致设备无法执行“先停机再启动”的兜底策略。3.3 UserDRContract合约次数与需求响应项目类型的关联用户需求响应合约信息类只有两个属性理想状态下设备每年参与需求响应的最大次数以及设备已经参与的次数。字段少但它承担的是合规校验职责——终端在下发指令前要判断本次响应会不会让参与次数超出合约上限。这个类真正的信息量在关联关系上。它与需求响应项目类型之间是“一个合约对多个项目类型”的关联也就是说一份合约可以同时覆盖分时电价、尖峰电价、直接负荷控制等多个项目。建模时不能把项目类型做成合约的属性字段否则一份合约只能绑一个项目扩展性直接归零。实施时我通常要求把已参与次数做成只增不减的计数器每次响应结束后由主站回执触发累加而不是让终端自己算。终端侧只做校验不做出账这样在终端掉线、重装、换机的场景下次数不会丢。4. 专用包落地从运行状态到可削减功率的十类对象4.1 设备类型与运行状态水冷、风冷、多联机怎么分专用包的第一层是四个基础枚举它们定义了后续所有参数的取值空间。工作模式枚举只有制冷和制热两个主值加扩展位。这个粒度是合适的因为需求响应的能力计算只区分制冷工况和制热工况再细分到除湿、送风对功率计算没有实质帮助。运行状态枚举分停机、运行、待机、故障四个值。这四个值的区别在联调时很关键待机不等于停机待机状态下设备仍有控制电路功耗且可以在秒级内响应启动指令故障状态下任何需求响应指令都不应下发但要上报告警。集中式空调类型枚举分水冷、风冷、多联机。这个分类直接决定额定参数里 COP 和 EER 的取值口径——水冷机组的能效比通常高于风冷多联机的部分负荷特性又和离心式机组完全不同。类型选错后面算出来的可削减功率就全是错的。设备类型枚举描述的是系统内部组成部件包括主机机组、冷热水泵、冷却水泵加扩展位。这个枚举是部件级额定参数的主键每一行额定参数都要标明它描述的是哪类部件。4.2 额定参数的两级拆分系统级与部件级额定参数被拆成两个类一个描述系统整体一个描述组成部件这是整个模型里最有工程价值的设计之一。系统级额定参数包含空调类型、室内制冷或采暖面积、室内平均高度、制热工况能效比、制冷工况能效比、所在建筑物能量损失系数。前三个是几何参数中间两个是能效参数最后一个是建筑热工参数。这六项合起来构成了需求响应能力计算的全部输入——后面附录里的公式只用到这些量。部件级额定参数包含部件类型、数量、额定电流、额定电压、额定运行功率、额定频率外加一个可选的负荷率限定值。这里的“数量”字段容易被忽略但它承担的是备用部件的表达一个系统里可能配三台主机、两台运行一台备用数量字段写三运行策略由终端根据负荷率限定值决定。参数层级关键字段典型来源是否参与能力计算系统级面积、层高、COP、EER竣工图纸、铭牌是部件级数量、额定功率、负荷率限定值设备铭牌、运行规程否用于校验上限表格里的最后一列是我加上去的判断依据部件级参数不直接进公式但用来做结果校验。算出可削减功率后要和主机额定功率乘数量做比对超出就说明输入参数有问题。4.3 实时信息与温湿度参数采集口径先定死实时信息类只有六个属性实时单相或三相电压、实时电流、实时频率、实时总有功功率、实时总无功功率、主机负载率。前五项是电气量最后一项是运行量。采集口径要在开发前就定死——电压电流是取单相还是三相取哪一相取瞬时值还是周期平均值这些不写清楚两个终端上报的数据就没法比。温湿度参数类的字段最多分三组。第一组是室内侧制冷或制热温度设定值、室内平均温度、室内平均相对湿度。第二组是室外侧室外平均温度、室外平均相对湿度。第三组是换热侧冷凝器进出口温度即冷却水进出水温度、蒸发器进出口温度即冷冻水进出水温度、采暖水送水温度和回水温度。第三组的可选项标注值得注意冷凝器进出口温度是可选项蒸发器进出口温度在原文里没有标可选。这个差异反映的是采集难度——冷冻水温度在机房侧普遍有现成传感器冷却水温度则常常缺失。建模时按可选项处理实施时可以降级。提示室内平均温度这个字段的计算口径要在接口文档里写清楚。是按面积加权、按测点算术平均还是取中位数三种算法在同一栋楼里能差出一度以上直接影响可削减功率的计算结果。4.4 需求响应能力计算附录 A 公式落成代码需求响应能力类只有三个属性参与响应时可增加的有功功率、可削减的有功功率、响应持续时间。这三个值不是设备自己报的是算出来的计算方法放在资料性附录里。制冷工况下假设响应前系统已处于平稳运行状态制冷量与建筑冷量消耗匹配可削减功率与持续时间的关系是空气密度乘以空气定压比热容乘以建筑面积乘以平均层高再乘以室内允许最高温度与设定制冷温度之差除以制冷能效比与持续时间的乘积。制热工况的可削减功率方向相反用的是设定采暖温度与允许最低温度之差除以制热能效比。可增加功率则用允许温度与设定温度的反向差值。AIR_DENSITY 1.177 # kg/m3300K 干空气密度 AIR_HEAT_CAP 1.005 # kJ/(kg*K)300K 空气定压比热容 def cooling_decreased_power(area, height, t_set, t_limit, eer, duration_s): 制冷工况可削减有功功率对应附录 A.3 area 室内制冷面积m2 height 室内平均高度m t_set 用户设定的制冷温度degC t_limit 用户可承受的室内最高温度degC必须高于 t_set eer 制冷工况能效比 duration_s 需求响应持续时间s 返回 可削减有功功率kW if t_limit t_set: raise ValueError(制冷工况下允许温度必须高于设定温度) if eer 0: raise ValueError(EER 必须为正数) delta_t t_limit - t_set # 量纲kg/m3 * kJ/(kg*K) * m2 * m * K / s kJ/s kW return AIR_DENSITY * AIR_HEAT_CAP * area * height * delta_t / (eer * duration_s) def heating_decreased_power(area, height, t_set, t_limit, cop, duration_s): 制热工况可削减有功功率对应附录 A.1 t_set 设定采暖温度degC t_limit 允许最低温度degC必须低于 t_set cop 制热工况能效比 if t_limit t_set: raise ValueError(制热工况下允许温度必须低于设定温度) delta_t t_set - t_limit return AIR_DENSITY * AIR_HEAT_CAP * area * height * delta_t / (cop * duration_s) def heating_increased_power(area, height, t_set, t_limit, cop, duration_s): 制热工况可增加有功功率对应附录 A.2 t_limit 允许最高温度degC必须高于 t_set if t_limit t_set: raise ValueError(可增加功率计算中允许温度必须高于设定温度) delta_t t_limit - t_set return AIR_DENSITY * AIR_HEAT_CAP * area * height * delta_t / (cop * duration_s)三个函数共用同一套物理量差别只在温差方向和分母用 COP 还是 EER。参数上有三处必须校验温度上下限关系、能效比为正、持续时间不为零。返回值的单位是千瓦量纲推导写在注释里是因为这一段最容易被质疑“凭什么这么算”。拿一组数字验算面积两万平方米、层高四米、设定制冷温度二十六度、允许最高温度二十八度、EER 取三点二、持续时间两小时。算出来可削减功率约四百八十千瓦。这个量级和一台中型离心机的出力对得上说明公式没有量纲错误。4.5 DRAbility 与计算结果的对账算出来的值最终要落到需求响应能力类的三个属性上。这里的工程习惯是可削减功率和可增加功率分别写入持续时间单独写三者构成一个完整的可调度承诺。主站做指令分配时会拿这三个值和合约里的次数上限一起做约束。对账环节不能省。我一般要求做两层校验第一层是结果与额定功率比对可削减功率不得超过主机额定功率乘数量第二层是结果与实时功率比对可削减功率不得超过当前实时总有功功率。第一层挡住参数录入错误第二层挡住运行工况不匹配——设备半载运行时按满负荷算出来的可削减量是不可能兑现的。5. 避坑与排查联调阶段最容易翻车的五个点5.1 功率差一千倍单位与乘数没对齐现象是主站收到的可削减功率比预期小三个数量级或者大三个数量级但两边的原始报文看起来都“正常”。原因基本锁定在复合类型的解析上。有功功率的unit固定为瓦特实际数值靠multiplier缩放如果发送端填了value800, multiplierk接收端忽略乘数直接取value就会把八百千瓦读成八百瓦。反过来发送端把已经折算成瓦特的数值再乘一次千就会放大一千倍。解决办法是在解析层强制走统一入口。所有复合类型进入业务逻辑前必须先调用折算函数回到基本单位禁止在业务代码里直接读value字段。同时要在接口文档里明确一条unit字段只做校验不做运算发现取值不是常量值就判定为报文非法直接拒收而不是尝试纠正。5.2 时间字段解析失败日期时间与持续时间的格式坑现象是终端上报的数据在主站侧时间显示为空或者跳到几十年前日志里能看到解析异常但被吞掉了。原因有两类。日期时间要求形如yyyy-mm-ddThh:mm:ss.sss用T分隔、毫秒补三位指定协调时间时用Z结尾本地时区要在末尾带±hh:mm偏移。很多开发者习惯用数据库的yyyy-mm-dd hh:mm:ss格式缺了T和毫秒严格解析器直接报错。持续时间要求形如PnYnMnDTnHnMnST前面是年月日、后面是时分秒秒可以有小数但其他必须是整数写成120min或2h都不合法。解决办法是在序列化层统一封装两个转换函数输入输出都走同一套格式化逻辑并且在单元测试里覆盖带时区、不带时区、带毫秒、不带毫秒四种组合。跨时区项目还要额外确认设备本地时区偏移是否随夏令时变化变化时上报的时间戳会不会出现重复或跳跃。5.3 可削减功率算出负数温度上下限写反、工况取错现象是能力计算结果为负或者算出来明显偏大但公式照抄没改。原因通常是三个。第一温度上下限关系写反制冷工况要求允许最高温度高于设定温度制热工况要求允许最低温度低于设定温度反过来就是负温差。第二工况和能效比取错制冷用 EER、制热用 COP拿错分母不只是数值偏差量级都会不对。第三持续时间单位混用公式里的持续时间按秒参与运算如果传进去的是小时结果会放大三千六百倍。解决办法是把校验前置到函数入口温度关系不满足、能效比非正、持续时间非正一律抛异常而不是返回默认值。同时在计算结果出来之后加一道合理性区间判断比如可削减功率落在额定功率的百分之五到百分之百之间才放行超出区间就打日志人工确认。这道拦截拦下过好几次参数录错的事故。5.4 扩展枚举被当成非法值扩展前缀没做兜底现象是新接入的一个品牌的机组某些字段上报后被主站判为非法枚举整条报文被丢弃。原因是模型里每条枚举都留了x-{User-defined}形式的扩展位但接收端的校验逻辑是白名单式的只认标准里列出的字面量遇到带扩展前缀的值直接拒绝。解决办法是把枚举校验从“值匹配”改成“值匹配加前缀分流”。标准取值走原有分支以扩展前缀开头的值走另一条分支记录到扩展字段表里不参与严格校验但保留原始值。同时在数据字典里维护一张扩展值登记表新出现的扩展值必须登记后才能进入生产环境。这个机制的价值在于既不让扩展值污染标准语义也不让新设备因为一个枚举被整体挡在门外。5.5 合约次数对不上已参与次数没人累加现象是月底对账时发现某台设备参与的响应次数超过了合约上限或者明显少于实际执行次数。原因在于已参与次数这个字段的维护责任没定清楚。有的实现让终端自己加终端重装或者换机后计数归零有的实现让主站加但主站只在正常回执时累加异常终止的响应没有计入还有的两边都加导致翻倍。解决办法是明确单一出账方。合约次数以主站为准终端只做校验不做出账每次响应无论正常结束还是异常终止都由主站根据响应记录生成一条计数凭证再累加终端侧缓存一个只读副本用于下发前预判。这个规则要写进接口文档并且在联调阶段专门构造一次异常终止场景验证计数是否正确。6. 验收与答辩用一张自查表把模型链路跑通6.1 交付前的五项自检模型的验收不是看代码能不能跑是看一条完整链路上每个环节的数据是否自洽。我一般按下面这张表逐项过任何一项不过就不提交。检查项检查方法不通过的典型表现类型完整性遍历所有必选属性构造最小报文必选字段缺失但未报错单位一致性抽查功率、温度、流量三类复合值折算后量级偏差三个数量级枚举扩展注入一个扩展值跑全流程整条报文被丢弃公式边界温度上下限取等、持续时间为零返回负值或除零异常合约校验构造超次数下发指令被放行且无告警第一项检查的核心是必选属性。设备出厂信息类里设备 ID 和生产厂家名称是必选用户信息类里用户编号和关口电表表号是必选漏一个就说明序列化层没有做强约束。第二项要覆盖复合类型的折算路径重点看multiplier有没有被忽略。第三项前面说过注入扩展值验证前缀分流。第四项要构造极端输入看校验函数是否真的拦住。第五项验证合约次数校验是否在指令下发前生效而不是事后补告警。6.2 答辩时怎么讲一条完整链路答辩最容易犯的错是按章节顺序念属性表念到一半评委就失去耐心。有效的讲法是选一台具体设备把链路走一遍。我会挑一台水冷离心机组从设备出厂信息类录入开始讲清设备 ID 的编码规则和必选字段接着讲自动化能力信息怎么判定它具备柔性和刚性两种能力据此推出它适合参与哪类项目然后讲系统级额定参数里的面积、层高、能效比从哪来部件级参数怎么标数量再往下是实时信息和温湿度参数说明采集口径最后现场算一遍可削减功率把数字和主机额定功率、实时功率做一次对账。整条链路讲完模型的完整性、公式的正确性、参数的可获得性三件事同时被证明了。评委常追问的两个点要提前准备。一个是“为什么可削减功率不能超过实时功率”答案在半载工况下按满负荷计算无法兑现。另一个是“扩展枚举会不会破坏互操作性”答案在前缀分流加登记表这套机制上。从那以后我每次带这类项目都强制在提交前把那张自查表走一遍尤其是公式边界那一项早年被除零异常坑过一次之后就没再省过。希望帮到你。本文还有配套的精品资源点击获取