★ FEATURED ARTICLE 简介《开放光传输系统光电产品软件白皮书2020》由开放数据中心委员会ODCC发布面向光传输系统研发、运维及标准化从业人员旨在规范光电产品软件层面的开放性与智能化管理。白皮书聚焦YANG数据建模语言在系统管理中的应用系统阐述OCyang模型、ODCC yang模型及全局性原则并详细定义了platform标准中的组件命名规则、subcomponent关系以及各类共性参数如type、admin-state、oper-status、led、vendor-type等为设备识别、状态监控和兼容性保障提供完整框架。资源包为单个PDF文档大小约4.03MB共1个文件格式为官方标准文本适合研读和检索。已有135人学习下载可作为理解开放光传输架构、优化数据中心运维效率的参考依据。1. 开放光传输系统软件白皮书它到底把光电设备的什么管起来了开放光传输系统的软件难点不在单个设备的功能而在设备型号一多、接口各自为战之后上层管理系统很难用同一套模型把它们统一管起来。ODCC 这份编号 ODCC-2020-03002B 的《开放光传输系统光电产品软件白皮书》要解决的就是这件事用 YANG 模型把光电产品软件层的骨架固定下来组件怎么命名、共性参数有哪些、告警事件怎么上报、软件升级走哪些 RPC全程有明确约定。换句话说只要设备符合规范你就能用同一套 netconf/telemetry 接口完成接入和运维这正是开放光传输系统解决互操作性问题的核心手段。适合三类人读开发设备软件和 netconf 接口的工程师、设计数据中心光网络管理面的规划人员以及每天面对光功率告警的运维。这份 PDF 白皮书是标准文档可复现性在于把其中的模型要求和参数约定落到自己的设备、模拟器或测试脚本里验证。2. YANG 模型结构概览OCyang 与 ODCC yang 的兼容边界和全局性原则2.1 OCyang 与 ODCC yang95% 兼容背后的扩展逻辑YANG 是 NETCONF 的数据建模语言OpenConfig 工作组先制定了一套面向网络设备的开源模型覆盖网络协议、设备组件结构、端口等。ODCC 在这套模型基础上结合数据中心光传输的真实业务场景做扩展保持 OC YANG 模型 95% 以上的完整和一致性。这个数字很关键意味着厂商如果已经实现了 OpenConfig 模型迁移到 ODCC 规范的成本很低对上层网管来说也不必为不同厂商各写一套适配器。扩展方式是“文件增加、节点增加、结构明确和细化”三类。文件增加最容易理解OpenConfig 的 optical-transport 目录偏重通用光模块参数而 EDFA 的增益控制、OSC 监控通道、OLP 保护这类 WDM 特有组件在 OC 模型里没有完整容器。ODCC 的做法是把 OCM、EDFA、OLP、OTDR 的特性参数单独建模再通过 name 的 leaf reference 与 platform 体系建立关联。这样 platform 树仍然干净光层模块的细节又有独立的扩展空间。调整方式典型场景说明文件增加光层组件无现成定义EDFA/OCM/OLP/OTDR 单独建 yang 文件节点增加平台缺字段在 OC 原模型基础上 augment 新节点结构明确/细化命名、状态语义模糊明确 component 命名规则和 config/state 行为理解“leaf reference”对写查询路径很重要。查 EDFA 的增益不是在一个文件里从头读到尾而是先通过 platform 的 component 定位到 name再进 EDFA 特性容器取参数。两个文件配合着看字段才能对齐这也是 YANG 模型扩展的标准姿态augment 不改原结构只挂新分支。2.2 全局性原则config/state 双容器、CLI 与 netconf 同一数据库OCyang 中节点分 config 和 state 两种状态参数可读时存在 state 容器下参数可配时存在 config 容器下。最容易被忽略的约定是当模型要求某个节点可配置但设备实际不支持配置时config 容器下仍要显示该节点配置时返回错误或不可配置。这样设计的目的很直白——上层应用拿到的模型永远是完整的不会因为某个厂商缺字段导致遍历中断。另一条硬性要求是 CLI 与 netconf 操作同一个数据库。过去很多设备 CLI 走私有协议、netconf 走另一套配置通道两边状态经常对不上。白皮书明确要求CLI 下发配置后通过 netconf 查 config 文件夹必须看到一致结果。对自动化平台来说这是最基础的信任前提如果这条不成立配置核查脚本写出来也是废的。还有几个编制层面的硬约束string 类型数据长度优选 64 字节不得超过remark、text 类节点优选 256 字节不得超过。component 体系下所有 name 统一使用大写目的是避免设备与上层交互时大小写转换带来的麻烦。发送的 XML 中 namespace 遵循 RFC 6020notification 报文遵循 RFC 5277。下面是一个典型的 get-config 请求注意 name 全大写写法!-- 通过 netconf get-config 读取单板管理状态name 为 component 的 key必须大写 -- rpc message-id101 xmlnsurn:ietf:params:xml:ns:netconf:base:1.0 get-config source running/ /source filter typesubtree components xmlnshttp://openconfig.net/yang/platform component nameLINE-1/name config admin-state/ /config /component /components /filter /get-config /rpc这里读的是 running 配置库admin-state 被包在 config 下表示管理状态可配。如果设备实际上不支持配置该参数按规范节点仍然存在但返回错误。遇到这种情况先别怀疑报文格式用 get-state 对比运行状态多半能定位问题。提示config 与 state 不一致是允许存在的状态。排障时先 get-config 看“配置被要求成什么样”再 get-state 看“设备实际跑成什么样”两者对不上时以 state 为准定位问题。2.3 模型文件关系platform、system 与 optical-transport 各管哪一段模型文件之间的关系可以用一句话概括platform.yang 定义物理层 component 树system 管系统参数和告警体系optical-transport 下放功能配置与性能监测telemetry 负责流式数据采集各光层特性参数文件 augment 回 platform 体系。记住这个分层找字段时就不至于在几十个 yang 文件里瞎翻。文件/目录职责常见节点platform.yang整机组件树component、subcomponentsystem系统参数、告警体系alarm、eventoptical-transport光层功能配置、性能监测optical-channel、physical-channeltelemetry流式数据采集订阅与采样EDFA/OCM/OLP/OTDR 特性文件光层模块细化参数通过 name leaf reference 关联 platform落到操作上拿到一台新设备先 get-config 拉一遍 platform 的 component 列表确认设备上报了哪些组件再按组件类型去对应特性容器里查细节。不要试图从根节点一次性拿到全部数据netconf 的树很深把过滤条件写在 filter 里更稳。2.4 模型结构理解的三个常见误区第一个误区是以为 config 和 state 必须一致。规范明确允许两者暂时不一致设备可能由于硬件故障、告警抑制等原因没有落实配置这时候强行认为“配置成功就是运行成功”排障方向就偏了。第二个误区是忽视 name 大小写。规范要求所有 name 大写但实际现场偶尔能看到厂商实现不规范上报小写或混写。上层数据库设计时要留一手把 name 当唯一键的先对设备做一致性检查别等数据跑起来才发现重复键。第三个误区是直接把 OpenConfig 模型套用到光层。OC 原生模型对 EDFA、OLP、OSC 覆盖很弱直接用会丢字段。凡涉及光放大、光保护、光监控的场景必须按 ODCC 扩展模型找字段这是规范存在的根本原因。3. platform 标准落地component 命名规则、共性参数与特性参数怎么建模platform 是整个设备结构模型的主体。子架、电源、风扇、主控、业务板卡、模块、端口以及 EDFA 组件、OSC 组件、OCM 组件、OTDR 组件全部例化成 component。名称是 component 的 key 值统一的命名规则让模型的使用和数据的解析更便捷。这一章的实质是把物理设备翻译成一张可查询的表每个硬件单元一行记录公共字段放前头特有字段放扩展列。3.1 component 命名规则电层盒式设备与光层盒式设备的命名差异白皮书把命名分成电层盒式设备和光层盒式设备两个方向。电层设备处理客户业务信号像 OTU 板卡命名一般体现业务类型和槽位信息光层设备处理 WDM 波长和放大像 OA 光放板卡、OLP 保护板卡命名更多体现光模块功能。文档 4.1 节给了完整清单这里按缩略语表做一个常见拆解具体前缀以厂商实现为准组件类别常见命名前缀功能定位供电电源组件PSU为设备供电风扇单元FAU散热主控单元MCU系统控制与管理光放大器OA/OLA光信号放大光纤线路保护OLP主备光路倒换光监控通道OSC带外监控通道光时域反射仪OTDR光纤链路测量光传送单元OTU客户业务接入与映射命名最常见的坑是大小写和槽位号格式不统一。规范说得很明确component 体系下所有 name 统一大写。有些设备上报时用 slug 格式、有的用纯大写解析层不统一就是事故。设计上层数据库时我一般把 component name 直接当唯一键存不做大小写归一因为设备侧按规范必须大写如果哪天发现重复键先怀疑设备上报不符合标准而不是改程序兜底。另一个容易被忽略的是 subcomponent 关系。命名解决“叫什么”subcomponent 解决“挂在哪里”。一个光放板卡下面挂着 EDFA 组件、OSC 组件、OCM 组件主控板下面挂着风扇子卡这些层级关系都通过 subcomponent 表达。运维查故障时顺着 subcomponent 树从上往下找比在平铺列表里碰运气快得多。3.2 共性参数type、admin-state、oper-status、remark、led、vendor-type共性参数是每个 component 都必须支持的字段相当于所有组件的“公共头”。白皮书列了 type、admin-state、oper-status、remark、led、vendor-type外加 component 通用 description 编写规则。我的理解是这相当于一张设备数据库的通用表结构不管什么组件先塞进这几列再往各自的特性表里补扩展列。参数含义使用要点type组件类型标识区分电源、风扇、板卡、端口等admin-state管理状态enable/disable表示“想不想让它跑”oper-status运行状态up/down 等表示“实际跑没跑起来”remark备注字段上限 256 字节放维护人信息和标签led指示灯定义网管可视化远程展示灯色和闪烁模式vendor-type厂商自有类型标识保留字段兼容厂商差异化能力description通用描述按 4.3.6 规则统一格式便于跨厂商解析admin-state 和 oper-status 的组合是健康判断的核心。运维里经常看到 admin-stateenable、oper-statusdown 的情况一种原因是配置没下到硬件另一种是板卡物理故障。排障时先看这两列再往下钻取特性的告警如果两者都是 disable/down多半是管理面主动关断不用急着报障。led 这列容易被当成小事但对机房无人值守很关键。网管端展示的“灯状态”就是从 led 字段读的厂商如果不按规范上报灯色和闪烁模式远程可视化就是摆设。vendor-type 则是专门留给厂商做差异的标准模型管不了的扩展能力放这里上层应用按需解析不阻塞标准字段。3.3 特性参数从 port 到 optical-channel八类组件的参数字段特性参数按组件类型分文件定义再 augment 进 platform 体系。目录里给出的类型有 port、power-supply、fan、cpu、transceiver、physical-channel、linecard、optical-channel每类字段的侧重点完全不同。port 是端口通用参数速率、协商、FEC 这类power-supply 管电源模块的输入输出电压电流fan 管转速和状态cpu 管主控占用率和温度transceiver 是可插拔光模块重点是收发光功率、温度、偏置电流——这是排查光路劣化的第一手数据。举一个我常遇到的场景线路侧误码率上升先查 transceiver 的收光功率是否接近灵敏度阈值再看物理通道的 FEC 纠错计数两步就能圈定问题在光模块还是在光纤链路。physical-channel 和 optical-channel 容易混淆。我的理解是physical-channel 是电层物理传输通道负责把客户侧业务映射到线路侧optical-channel 是 WDM 层面的光通道对应一个波长及其目标功率。OTN 业务创建时逻辑通道要同时绑定这两类通道缺一个业务都起不来。linecard 则是业务板卡自身的硬件信息槽位、硬件版本、功耗都归它管。特性参数的查询路径有规律共性参数在 platform/component 容器下特性参数在各自的 augment 容器下但都靠 component name 关联。写自动化脚本时先拉 component 列表拿到 name再按 name 拼出特性参数的过滤路径这是我用了很久的稳定套路。4. 定制化光层标准OA/OLA、EDFA、OSC、OCM、OTDR 与 OLP 的建模要点光层是全白皮书定制化程度最高的部分。OpenConfig 对电层以太网和路由覆盖得多对光放大、光监控、光保护这些 WDM 特有的组件建模很少所以 ODCC 自己定义了 OA/OLA 光放板卡、OLP 保护板卡的结构和参数还给了倒换逻辑和默认配置。这一章解决的是“光层设备怎么表达、怎么控制”的问题。4.1 OA/OLA 光放板卡结构、共性参数与 EDFA 特性OA 光放大器和 OLA 光线路放大器在结构上都是光放板卡。板卡内部通常包含 EDFA 掺铒光纤放大器、OSC 光监控通道组件、OCM 光通道监测组件部分还集成 OTDR。把这些全部例化成 component就是第 3 章讲的建模思路板卡是一个 componentEDFA、OSC、OCM 是它下面的 subcomponent。EDFA 特性要关注几个关键量增益、输出光功率、泵浦状态。白皮书里 EDFA 与 VGA 可变增益放大器相关意思是增益可以是固定值也可以动态调节调节依据一般来自 OCM 的功率反馈。工程安全还有个更重要的点AOSD 自动光功率关闭和 APR 自动功率降低。当检测到光纤链路异常时APR 先把输出功率降到安全水平AOSD 更激进直接关断泵浦。这两个机制不是摆设光纤被外力挖断时如果不降功率断点处会有强光射出对巡线维护人员是真实的伤害风险。注意涉及 AOSD/APR 的板卡验收时一定要实测拔掉输入光纤或加衰减观察输出功率是否在阈值内下降或关断。只配置不验证等于没配。默认配置在文档 5.1.7。上线前一般要确认几项OSC 是否使能、EDFA 增益默认值、告警阈值、AOSD/APR 默认开关。设备出厂默认往往偏保守会开启保护功能如果开局调试时需要更高输出功率再按场景临时调整调试完记得恢复。4.2 OSC 模型与 OCM/OTDR 数据格式OSC 光监控通道是带外管理通道的底层承载网管数据、告警、OSC 端口的 LLDP 都走它。OSC 接口在 interface 标准里有单独定义对应文档 7.2 节。如果 OSC 断了网管对整条光路失联此时只能从带外管理口登录设备查光放板卡状态。所以 OSC 的配置虽然不起眼却是整个管理面的命脉。OCM 光通道监测负责逐波监控功率数据格式在附录六OTDR 光时域反射仪负责测光纤链路能给出事件距离、损耗、反射率数据格式在附录五。两者是光路质量的两类证据OCM 告诉你“哪个波长功率不对”OTDR 告诉你“断点在大概多少公里处”。配合起来定位光路故障比逐段拔纤试效率高很多。模块核心职责主要数据字段OCM通道功率监测通道号、波长、功率、状态OTDR光纤链路测量事件距离、事件类型、损耗、反射率、衰减系数实际使用里有个习惯OCM 数据按周期采集明显超出历史基线时提前预警这往往在误码率恶化之前就能看到是最早期的劣化信号。OTDR 不常开启动测试会短暂占用资源用 start-otdr RPC 触发、stop-otdr 停止结果按附录五格式解析。4.3 OLP 保护板卡结构、参数与倒换逻辑OLP 光纤线路保护用于主备光路的自动切换。结构上包含光开关、分光器、监测模块实际业务走工作路保护路热备。白皮书 5.2 节定义了保护板卡结构、共性参数、特性参数、默认配置和倒换逻辑是光层里逻辑最完整的一块。倒换逻辑分两种触发自动倒换工作路收光功率低于阈值或丢失信号时触发手动倒换用 switch-olp RPC 强制切换。运维做保护倒换演练时一般不会去拔纤而是直接下发手动倒换验证保护路可用后再切回。下面是 switch-olp RPC 的示意报文!-- 手动将 OLP 保护组倒换到保护路验证保护链路可用 -- rpc message-id102 xmlnsurn:ietf:params:xml:ns:netconf:base:1.0 switch-olp xmlnsurn:odcc:yang:olp nameOLP-1/name directionprotect/direction /switch-olp /rpcname 是 OLP 板卡在 platform 里的 component keydirection 取值常见为 working 或 protect按厂商实现还会带 mode 字段区分自动、手动、强制。下发后不要立刻下结论等设备上报倒换完成的事件或用 get-config 核对倒换状态再确认业务没有中断。倒换演练有个坑有些设备倒换是硬切换毫秒级网管上看不到业务中断有些是软切换会有几十毫秒闪断。验收保护功能时除了看 OLP 状态更要看客户侧端口有没有误码这才是业务真正关心的指标。4.4 默认配置与上线检查清单光层板卡默认配置直接决定开局是否顺利。文档里 OLP 和 OA/OLA 都有专门的小节描述默认配置涉及的共同点包括默认增益范围、OSC 的使能状态、保护组的初始方向、告警阈值。开局时先按默认配置把板卡跑起来再根据实际光功率做微调最后把微调结果固化到配置文件里。我一般会给每块光层板卡做一份简短的上线检查清单一、板卡 LED 状态正常二、OCM 各通道功率在阈值内三、EDFA 增益与目标值偏差小于 0.5dB四、AOSD/APR 保护功能实测有效五、OLP 自动和手动倒换各演练一次。这五条过完光层板卡才算真正交付。5. 告警、事件、RPC 接口三个接口层的常见问题与排查方法5.1 Alarm 与 Event 模型type-id、告警描述与 CONFIG-CHANGE 事件告警和事件是两个不同概念。告警代表当前存在的故障状态需要恢复比如光功率越限事件是一次性操作记录比如配置变更、板卡插拔本身不需要恢复。白皮书第九章把两者分开建模Alarm 模型定义 type-id 类型说明和告警描述Event 模型定义事件分类、格式CONFIG-CHANGE 事件专门记录配置变更。附录一、二、三、四分别给了光层和电层的告警事件清单排障时查清单比猜 type-id 快得多。告警通知走 RFC 5277 的 notification 机制。下面是告警报文结构的示意!-- 告警通知示意光通道功率越限resource 指向具体组件路径 -- notification xmlnsurn:ietf:params:xml:ns:netconf:notification:1.0 eventTime2025-01-15T10:30:00Z/eventTime alarm xmlnsurn:odcc:yang:system type-idOPT-POWER-LOW/type-id severitymajor/severity resource/components/component[nameOCM-1]/resource textchannel 5 optical power below threshold/text /alarm /notificationtype-id 是告警类型标识具体值以附录一、三的清单为准这里用 OPT-POWER-LOW 做示意severity 表示严重级别resource 指向告警源通常是 component 路径。自动化平台订阅 notification 后第一件事就是解析 resource 把告警挂到正确的组件上别只按 text 打标签否则告警关联会乱。CONFIG-CHANGE 事件用于审计记录谁在什么时间改了哪个节点适合回滚溯源。事件格式在 9.2.2 有统一定义自动化系统最好把这类事件单独归档不跟告警混在一起查历史变更时才翻得出来。5.2 interface 标准客户侧、OSC、带外管理、LOOPBACK 四类端口interface 标准覆盖四类端口客户侧端口 interface、OSC 端口 interface、带外管理端口 interface、LOOPBACK 端口 interface。客户侧端口就是 OTU 板卡上对接业务设备的接口速率和 FEC 参数在这定义OSC 端口是光监控通道的接口带外管理端口是 IP 网管口LOOPBACK 端口用于测试环回。接口类型承载内容配置要点客户侧端口业务信号速率、协商模式、FECOSC 端口网管开销波长、使能状态带外管理端口IP 网管IP、网关、VLANLOOPBACK 端口测试环回配合 loopback-mode 使用客户侧端口环回是开局自测的常用手段。loopback-mode 的取值常见为 no-loopback、facility-loopback、terminal-loopback分别代表不环回、设备内部环回、终端侧环回。做通断测试时先配 facility-loopback 验设备内部转发再连测试仪打流验外部链路逐段缩小范围。test-signal 测试信号配合使用可以在没有业务时填 PRBS 码流验证链路误码。5.3 RPC 接口总览13 个接口怎么组合RPC 接口是设备对外提供的操作入口白皮书定义了 reboot、download、get-download-status、upload、remove-file、activate-file、get-activate-status、get-pm-data、switch-olp、start-otdr、stop-otdr、get-log、set-datetime 共 13 个。它们不是孤立的软件升级和运维操作都是多个 RPC 组合出来的。RPC用途典型组合场景reboot重启设备/板卡升级完成后调用download下载软件包到设备与 get-download-status 配对get-download-status查询下载状态download 后轮询upload上传文件日志与配置上传remove-file删除文件清理旧版本软件包activate-file激活软件与 get-activate-status 配对get-activate-status查询激活状态activate 后轮询get-pm-data拉取性能数据业务验收、劣化分析switch-olpOLP 倒换保护演练start-otdr / stop-otdr启动/停止 OTDR 测试光纤链路测量get-log获取设备日志排障set-datetime设置设备时间开局、对时软件升级的标准动作是 download → get-download-status → activate-file → get-activate-status → reboot。很多人图省事把 download 和 activate 合在一起一旦下载不完整直接激活设备可能起不来。血泪经验是激活前必查 get-download-status 确认文件完整激活后等 get-activate-status 返回成功再 reboot顺序不能乱。5.4 常见问题排查现象、原因、解决现象一刚插上新板卡立刻 get-config 查不到 component。原因板卡识别和模型初始化需要时间设备还没把新组件挂进 platform 树或者板卡处于预配置状态只有配置没有实体硬件。解决等设备上报插卡事件或轮询 component 列表确认出现新 name 后再下发配置别在初始化空窗期做操作。现象二config 下发成功oper-status 一直不 up。原因config 和 state 允许暂时不一致配置可能没被硬件接受或存在抑制性告警。解决用 get-config 和 get-state 分别核对确认配置值确实生效再看该组件是否有告警比如光模块收无光、供电异常最后确认 CLI 与 netconf 是否操作同一数据库有些老设备两边不同步。现象三拔板再插回之前的 admin-state、remark 全丢了。原因人工拔板不等于删除板卡但如果网管侧做了删除操作config 就被清了插回时按新板卡初始化。解决删除板卡前先备份 component 的 config拔板维护时只拔不删插回后 config 还在插回后先 get-config 比对别急着配业务。现象四OTDR 测试结果全是乱码或空数据。原因测试被中途打断或数据格式没按附录五的约定解析或者波长类型不匹配。解决start-otdr 之后确保链路稳定测完用 stop-otdr 正常结束解析时严格按附录里的字段顺序和单位换算同一链路不同波长的结果不能混用。现象五订阅了 notification但告警里找不到具体端口。原因部分实现只在 resource 里带 component name不带 interface 名或者告警源挂在了父板卡上。解决先解析 resource 定位到 component再用该组件的 subcomponent 关系往下找端口同时把 led 字段拉出来结合告警时间和光功率数据反推物理位置。6. 从板卡插拔到 OTN 业务创建用 get-config 和 get-pm-data 做落地验证6.1 板卡操作场景初始、插入、拔板、插回、删除、预配置板卡操作场景是理解 platform 模型行为的入门题。文档 12.1 节把整个过程分成初始状态、初次插入、人工拔板、板卡插回、删除板卡、预配置六种场景关键差异在 config 和 state 两个文件夹上。场景config 表现state 表现初始状态无该组件无该组件初次插入空配置或默认配置硬件信息上报人工拔板保留组件离线或 oper-status down板卡插回仍保留恢复 up删除板卡被清除消失预配置可先下发无实际硬件最常见的误操作是把拔板和删除混为一谈。拔板只是物理动作配置应该保留删除是管理动作会清掉 config。文档 12.1.7 专门提到 config 和 state 文件夹的显示问题有些设备在板卡拔出时 state 文件夹消失、config 文件夹还在这是正常的如果两者同时消失说明是删除语义别急着报障。6.2 OTN 业务创建从 OTU 板卡模型到性能验证OTN 通道建立逻辑在文档第 14 章核心是三层模型OTU 板卡业务端口模型、逻辑通道模型、业务创建流程。业务端口对应客户侧物理口逻辑通道承载 ODU 映射logical-channel-assignments 定义映射关系operational-mode 决定工作模式ingress 关联关系把客户侧流量引到线路侧。我的验证步骤是固定的。第一步get-config 拉平台 component 列表确认 OTU 板卡和端口都存在且 oper-status up第二步配置逻辑通道与客户侧端口映射核对 operational-mode 是否匹配对端设备第三步下发业务后用 get-config 核对映射关系再拉 get-pm-data 看客户侧和线路侧性能计数第四步如果出现误码先看 transceiver 收发光功率再查 FEC 纠错和物理通道状态。从那以后我每次上一块 OTU 板卡都强制走一遍“插板 → 等 notification → get-config 核对 → 下发业务 → get-pm-data 验证”的流程软件升级也一样把 download 和 activate 拆开一步步确认状态绝不把关键操作压进一个脚本里图省事。这套习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
