简介昌吉州医保结算系统实施版是一份面向医保信息化管理员、医院信息系统对接人员及结算业务操作员的实操型资源聚焦参保信息管理、费用审核、报销计算、跨区域结算等核心环节在地方医保平台中的落地方式。压缩包共3个文件包含一个htm说明页、一个txt下载说明以及一个pbl程序库文件PowerBuilder应用整体仅929KB轻量但覆盖从环境接入到日常结算处理的关键指引。已有1833人学习下载适合需要快速了解昌吉州医保结算流程或手工核对系统逻辑的读者。透过说明文档可梳理该系统与HIS数据交换、智能审核规则及异地就医结算的处理路径pbl文件则为二次开发或本地部署调试提供了直接参考。1. 医保结算系统到底是做什么的先分清“算费”和“支付”两个世界医院收费窗口背后跑着的从来不是“总费用乘一个比例”那么简单的逻辑。一套医保结算系统真正要接住的是医保目录匹配、起付线封顶线、三段式费用拆分、统筹与个人账户轮流支付以及和医保端结算服务之间的一来一回。它解决的核心问题是把一份医保政策文件翻译成能算、能查、能对账的软件逻辑。适合读这篇的人医院信息科里跟HIS开发商反复确认结算口径的工程师、准备自研医保对接模块的团队、半路接手结算系统想搞清楚边界的运维开发。下面这套拆解是我按实际做过的最小方案来讲的能直接落到代码和配置上。2. 先看懂医保结算的算费模型目录、三段式费用与统筹公式做结算系统之前先别碰代码把算费模型吃透。模型错了后面所有接口、报表、对账全是白干。这一章把医保结算最核心的算费逻辑拆开讲哪些费用能报、能报多少、先扣谁后扣谁。这套模型不只服务于编码也是你将来跟医保端核对结算结果时吵架的依据。2.1 医保目录决定了“哪些钱能报”药品、诊疗项目与服务设施医保结算的第一层过滤来自目录。一次就诊的费用流水里每一笔都要打上“目录类型”“甲乙丙类别”“自付比例”这些标签。常见做法是维护三张目录表药品目录、诊疗项目目录、医疗服务设施目录。字段设计大同小异核心要留住这几个字段作用示例目录编码与费用流水里的项目编码做匹配的唯一键药品国标码、诊疗项目编码目录名称用于人工核对和展示头孢呋辛酯片类别标志甲类/乙类/丙类自费A / B / C乙类自付比例乙类项目先由个人自付的比例0.10 表示先自付10%限定支付范围限儿童、限适应症、限用量不满足则全自费限门诊慢病使用目录版本号区分不同换版周期的目录2025V3第一步实际开发时最容易忽略的是“限定支付范围”。目录匹配上只是第一关还要校验限定条件。我见过一个很典型的场景某药品只限儿童使用结算端校验年龄超过18岁直接按自费处理HIS传过来的费用如果不带年龄字段这笔就会在医保端返回“不在支付范围”患者就得全额自费。所以结算系统里匹配目录时要把就诊人的基本信息带上年龄、性别、诊断编码、就诊类型全部参与匹配判断。2.2 费用从原始流水到“三段式”分类把流水账拆成合规口径目录匹配完之后每笔费用要被归类到三段式里这是医保结算和普通医院计费最大的区别。医院HIS里存的是“收了多少费”医保结算要看的是“这笔钱算什么性质”。三段式分别是全额统筹段甲类项目全额计入医保可报销范围。部分统筹段乙类项目先按自付比例扣掉个人部分剩余部分计入可报销范围。自费段丙类项目或不符合限定条件的项目金额直接进个人自费。这个分类逻辑不复杂但却是全系统最容易出分歧的地方。具体算某笔费用时我的做法是先把费用流水按目录匹配结果划分成三类分别累计金额再把“合规费用”算出来。合规费用就是甲类全额加乙类扣除自付后的剩余部分。注意“合规费用”是后续统筹支付的基数不是最终患者付的钱。用 SQL 建一张费用分类中间表把每笔流水和分类结果落下来整个过程就清晰了CREATE TABLE settle_fee_classify ( id BIGINT AUTO_INCREMENT PRIMARY KEY, settle_req_id VARCHAR(64) NOT NULL COMMENT 结算请求号, fee_item_id VARCHAR(32) NOT NULL COMMENT 费用流水ID, catalog_code VARCHAR(32) NOT NULL COMMENT 目录编码, catalog_type TINYINT COMMENT 1药品 2诊疗 3服务设施, item_category CHAR(1) COMMENT A甲类 B乙类 C自费, self_pay_ratio DECIMAL(5,4) DEFAULT 0 COMMENT 乙类先行自付比例, original_amount DECIMAL(12,2) NOT NULL COMMENT 原始金额, classified_amount DECIMAL(12,2) NOT NULL COMMENT 分类后计入合规费用金额, excluded_amount DECIMAL(12,2) DEFAULT 0 COMMENT 自费/排除金额, catalog_version VARCHAR(20) COMMENT 目录版本号, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_req_item (settle_req_id, fee_item_id) ) COMMENT 结算费用分类中间表;这段 SQL 里有几个关键点。self_pay_ratio存的是乙类先行自付比例它是从目录表带过来的快照不推荐在分类时去实时查目录表因为结算单后续要留痕目录换版后还能追溯当时的比例。classified_amount和excluded_amount之和恒等于original_amount这可以作为一条对账约束防止分类阶段漏记或重复记。如果 A 类分类成 B后面的统筹支付就全错了所以分类阶段一定要留中间表错了能单独查出来。2.3 统筹支付计算顺序起付线、报销比例、封顶线一个都不能跳分类完成之后真正决定“医保出多少钱”的是统筹段计算。这个计算有严格的先后顺序先减起付线再乘报销比例最后看封顶线。顺序错了金额全不对。以住院结算为例标准过程是这样的将合规费用累计求和得到合规总金额。如果合规总金额低于起付线统筹支付为0所有费用走个人账户或自费。如果高于起付线可报销基数等于合规总金额减去起付线。这一步得到的结果乘报销比例得到初步统筹支付。再与历年/当年封顶线比较超过封顶线的部分不进入统筹转入大病保险或自费。最后还要把多个支付段按次序叠加统筹支付先扣再扣大病支付再扣个人账户剩下才是现金自费。这个计算过程落到参数表里不要硬编码。每个统筹区、每个参保类型、每个医院等级起付线、比例、封顶线都可能不一样。我一般会建一张policy_settlement_param表把参数按生效日期和版本管理起来CREATE TABLE policy_settlement_param ( id BIGINT AUTO_INCREMENT PRIMARY KEY, region_code VARCHAR(20) NOT NULL COMMENT 统筹区编码, insure_type VARCHAR(20) NOT NULL COMMENT 参保类型编码, hospital_level VARCHAR(10) NOT NULL COMMENT 医院等级, ded_line DECIMAL(12,2) NOT NULL COMMENT 起付线, reimburse_ratio DECIMAL(5,4) NOT NULL COMMENT 报销比例, cap_line DECIMAL(12,2) NOT NULL COMMENT 封顶线, effective_date DATE NOT NULL COMMENT 生效日期, expire_date DATE DEFAULT NULL COMMENT 失效日期, policy_version VARCHAR(20) NOT NULL COMMENT 政策版本, UNIQUE KEY uk_param (region_code, insure_type, hospital_level, policy_version) ) COMMENT 统筹结算参数表;这张表在线上会遇到一个很微妙的问题政策参数是分版本生效的。患者住院跨月或者跨年入院时的政策版本和出院时的版本如果不一样按哪个算常见做法是“出院时点结算按出院当天有效参数执行”但为了防止争议我会在结算单上记录当时使用的policy_version。对账时如果医保端返回的金额与该参数算出的不一致第一步就是确认双方是否用了同一个政策版本这能省掉大量扯皮时间。3. 从零搭一套最小医保结算服务表结构、结算引擎与代码实现模型立住之后就可以动手写最小可运行版本了。我做这套最小系统只用了三张核心表结算单主表、费用分类中间表上一章已建、以及支付结果明细表。引擎用 Python 写好处是逻辑直白、方便单测真实生产里换成 Java 也只是换一层皮核心计算流程完全一致。3.1 结算单主表一次结算的“档案袋”结算单主表记录的是“这一次结算到底结算了什么、用了哪套参数、出来几个金额”。字段不需要太多但每个字段都要能回答“如果医保端说金额不对这笔是什么时候按什么算的”。我把主表设计成下面这样CREATE TABLE settle_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, settle_code VARCHAR(64) NOT NULL COMMENT 结算单号全局唯一, biz_flow_no VARCHAR(64) NOT NULL COMMENT 业务流水号HIS侧唯一, patient_id VARCHAR(32) NOT NULL COMMENT 患者ID, visit_id VARCHAR(32) NOT NULL COMMENT 就诊ID, visit_type TINYINT COMMENT 1门诊 2住院 3慢病, total_amount DECIMAL(12,2) NOT NULL COMMENT 费用总额, compliant_amount DECIMAL(12,2) NOT NULL COMMENT 合规费用总额, deduct_line_amount DECIMAL(12,2) DEFAULT 0 COMMENT 起付线扣减, reimburse_base DECIMAL(12,2) NOT NULL COMMENT 可报销基数, overall_pay DECIMAL(12,2) NOT NULL COMMENT 统筹支付, big_illness_pay DECIMAL(12,2) DEFAULT 0 COMMENT 大病支付, personal_account_pay DECIMAL(12,2) DEFAULT 0 COMMENT 个人账户支付, cash_pay DECIMAL(12,2) DEFAULT 0 COMMENT 现金自费, policy_version VARCHAR(20) NOT NULL COMMENT 使用的政策参数版本, catalog_version VARCHAR(20) NOT NULL COMMENT 使用的目录版本, settle_status TINYINT COMMENT 0草稿 1已提交 2结算成功 3结算失败, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_biz_flow (biz_flow_no), KEY idx_patient_visit (patient_id, visit_id) ) COMMENT 医保结算记录主表;biz_flow_no上的唯一约束是整个系统防重复结算的关键。HIS 每次发起结算都带同一个业务流水号即使重复请求数据库也会挡住第二次插入。这个字段在设计时就要定好规则我一般用“就诊ID 费用批次号 结算类型”拼接保证一次就诊的一次费用批次只有一次结算。3.2 结算引擎从费用列表到四方支付金额的完整流程下面这段 Python 是结算引擎的核心模拟了从费用分类汇总到起付线、封顶线计算的全过程。为了让代码可运行我把参数表简化成字典传入真实项目里这里是从数据库读取的。from dataclasses import dataclass, field dataclass class FeeItem: 费用项目 item_id: str catalog_code: str category: str # A甲类, B乙类, C自费 self_pay_ratio: float # 乙类先行自付比例甲类为0 amount: float # 原始金额元 dataclass class SettleParam: 结算参数 deduct_line: float # 起付线 reimburse_ratio: float # 报销比例 cap_line: float # 封顶线 class SettleEngine: def __init__(self, param: SettleParam): self.param param def calc(self, fee_items: list[FeeItem]) - dict: compliant 0.0 personal_extra 0.0 # 乙类先行自付累计 self_pay 0.0 # 丙类自费累计 for item in fee_items: if item.category A: compliant item.amount elif item.category B: deduct item.amount * item.self_pay_ratio personal_extra deduct compliant item.amount - deduct elif item.category C: self_pay item.amount # 先减起付线小于0按0处理 base max(0.0, compliant - self.param.deduct_line) overall min(self.param.cap_line, base * self.param.reimburse_ratio) # 剩余部分乙类自付 丙类自费 超封顶部分 cash personal_extra self_pay (base - overall / self.param.reimburse_ratio if overall self.param.cap_line else 0) return { compliant_amount: round(compliant, 2), reimburse_base: round(base, 2), overall_pay: round(overall, 2), cash_pay: round(cash, 2), } # 模拟一次住院费用起付线1000报销比例80%封顶线20000 param SettleParam(deduct_line1000.0, reimburse_ratio0.8, cap_line20000.0) items [ FeeItem(001, YA0001, A, 0.0, 5000.0), FeeItem(002, ZL0002, B, 0.1, 2000.0), FeeItem(003, FW0003, C, 0.0, 800.0), ] result SettleEngine(param).calc(items) print(result)这段代码有几个容易算错的地方。第一compliant累计的是费用金额而不是数量重复累计是常见 bug建议在循环里对每个 item 打标志位避免同一条费用被处理两次。第二乙类自付比例是 0.1 的时候用的是amount * ratio而不是amount - ratio。第三封顶线判断我放在了最后一步超过封顶线的部分要重新倒推回基数里那部分不报销的金额代码里那个三目表达式就是干这个的看着绕但这是很多生产系统里真正的内容。3.3 参数版本与目录版本把“快照”思想贯穿结算全链路这一节在编码阶段最容易被忽略我单独拿出来说。结算引擎算完之后不能只把金额存库必须把当时用到的参数版本、目录版本、乙类自付比例快照一并存下来。原因很简单医保端在结算后可能发起“冲正”或“退费重算”如果当时用的参数变了重算结果会不一样。我习惯在settle_record表上额外加一张settle_snapshot表把入参镜像存一份。这样既不影响主表查询性能又能完整复现当时的计算现场。字段就是入参 JSON加一个settle_code外键。实际开发里这个 JSON 可能很大但一次结算也就几百条费用性能完全不是问题。重点是遇到争议时能直接把快照调出来和医保端逐笔核对。这个快照思想贯穿全链路是结算系统工程师的基本功。4. 对接医保前置与 HIS报文格式、签名与重试机制算费引擎只解决了“钱怎么算”结算系统还得解决“怎么把结果送出去再收回来”。这一章讲 HIS、医院前置服务、医保端结算服务三方之间的交互。核心是报文设计、签名与重试。这三件事在真实项目里踩坑最多也最影响线上稳定性。4.1 前置机部署模式与请求流转路径常见做法是医院信息系统不直接连医保端而是通过本地部署的前置服务转发请求。前置服务负责两件事单向接收医院信息系统推送的结算申请转发到医保端结算接口接收医保端返回的结算结果再回调给医院信息系统。这个模式的优点是医保端只对前置服务暴露接口医院信息系统不用关心网络策略和证书细节。请求流转路径一般是下面这样HIS 收费模块 - 本地前置服务 - 医保端结算接口 ^ | ---- 同步返回 --这里有个容易忽略的点医保端结算接口可能不是同步返回的。实际生产里有些结算请求是异步模式医保端先受理返回一个受理号之后再回调结果。所以前置服务的请求模式要设计成“同步超时 异步查单”双通道。我一般这么处理先同步请求3到5秒内没返回受理结果就启动异步查单流程用受理号轮询医保端结果接口直到拿到最终状态。这个双通道模式很考验超时参数的设计。超时时间设短了正常慢请求全被误判成失败设长了医院收费窗口排队会卡死。我调过一轮之后固定下来的经验值是同步等待4秒轮询间隔2秒最大轮询次数15次。也就是说一次结算从发起到最终确认最长等待约34秒。超过这个时间就标记为“结果未知”不要直接判定失败更不能让医院信息系统自动重发等人工介入确认。4.2 结算请求报文的关键字段与数据类型报文设计是整个对接过程中最需要较真的环节。字段少了医保端无法判断限定支付条件字段类型错了资金结果直接被拒。下面这组字段是从真实对接经验里提炼出来的最小集合基本覆盖门诊和住院结算字段名类型必填说明bizFlowNostring(64)是业务流水号医院信息系统生成全链路唯一patientIdstring(32)是患者唯一标识idCardNostring(18)是身份证号用于医保端实名校验visitTypestring(4)是门诊/住院/慢病类型编码visitDatedatetime是就诊时间dischargeDatedatetime否出院时间住院结算必填totalAmountdecimal(12,2)是费用总额单位元feeDetailListarray是费用明细列表每笔含目录编码、金额、数量、自付比例标志policyVersionstring(20)否本地使用的政策参数版本供医保端核对catalogVersionstring(20)否本地使用的目录版本settleTypestring(4)是正常结算/中途结算/退费冲正特别注意feeDetailList它是医保端做政策审核的唯一依据。医药项目编码、数量、单价、金额、医保目录编码必须逐笔对应。很多患者结算金额对不上根因就出在明细层本地费用总额和明细汇总不一致。所以前置服务在发送前一定要做一次“总额等于明细累计”的校验不等直接拒绝发送并提示医院信息系统排查。4.3 签名、重试与幂等让结算请求“安全地重复”医保端接口对安全性要求高基础签名方案是发送方用私钥对请求体做摘要签名接收方用公钥验签。具体算法一般支持标准 RSA-SHA256密钥对由医院信息科和医保侧提前交换。签名时要注意一个细节报文里的浮点金额要先转成字符串并且去掉尾部多余0否则同一笔金额在 JSON 序列化时出现 100.50 和 100.5 两种表示签名结果就不一致了。下面是一个带幂等和重试的请求发送示例用 Python 写清楚关键逻辑import hashlib, time, requests def generate_sign(payload: dict, private_key_path: str) - str: 按字段排序生成待签名串RSA-SHA256签名 # 1. 剔除空值字段按key字典序拼成 keyvalue... items [] for k, v in sorted(payload.items()): if v is None or v : continue items.append(f{k}{v}) raw .join(items) # 2. 加载私钥签名省略具体库调用生产用file读取 with open(private_key_path, r) as f: private_key f.read() # 3. 返回base64后的签名串示意代码真实实现需处理二进制 return hashlib.sha256(raw.encode()).hexdigest() def send_settle_request(payload: dict, retry_times: int 3): 带重试的结算请求发送 sign generate_sign(payload, /etc/settle/private.pem) payload[sign] sign for attempt in range(retry_times): try: resp requests.post(https://pre.local/settle, jsonpayload, timeout4) if resp.status_code 200: data resp.json() if data.get(resultCode) ACCEPTED: # 受理成功后续查单 return data # 受理失败根据错误码决定是否重试 if data.get(errorCode) in [SYS_BUSY, NET_TIMEOUT]: time.sleep(2 ** attempt) # 指数退避 continue return data except requests.Timeout: # 超时不代表失败交给轮询查单 time.sleep(2 ** attempt) except Exception: time.sleep(2 ** attempt) return {resultCode: UNKNOWN, message: 重试后仍无法确认}这段代码有三层设计值得保留。第一层超时异常不能直接判失败要把结果标记成UNKNOWN交给轮询程序继续查单这是防止医保端已经受理但本地没收到响应而重复结算的关键。第二层指数退避用2 ** attempt第一次重试等1秒第二次等2秒第三次等4秒避免重试流量同时打爆前置机。第三层幂等保障靠的是报文里的bizFlowNo医保端以它作为唯一键重复请求返回第一次的结果所以这里的重试不会产生重复支付。5. 结算系统上线避坑现场5个真实翻车点与排查路径谈完了模型和接口这章写的全是上线后半夜被电话叫醒的踩坑经验。每一条都是真实生产里会发生、而且一旦发生就影响患者结算的故障。按现象、原因、解决的路径来写方便你将来照着排查。5.1 医保目录换版后乙类药品突然全部走自费现象是上午还好好的下午某批乙类药的结算结果突然全变成100%自费患者自付金额暴涨收费窗口被打爆。原因查下来是目录换版医保端切换了新一版目录旧目录里的乙类药编码全部失效。医院本地目录表还留着旧数据匹配时按旧编码匹配成功但医保端用新目录一校发现编码不存在直接按自费处理。解决方式分两步。第一上线前必须确认本地目录表里的版本号和医保端发布的目录版本对齐。第二换版当天要有“过渡匹配”逻辑本地同时保留新旧两个版本优先匹配新版本新版本匹配不上再尝试旧版本并把匹配结果以警告方式记录人工汇总后统一处理。等三天稳定期过了再彻底下掉旧版本。5.2 同一笔费用被结算两次幂等键设计缺失现象是某患者的住院费用出现在两张结算单上医保端和医院都对这笔钱计了费。排查发现是收费员手滑点了两次“结算”医院信息系统发起两次请求第一次医保端已受理但响应超时第二次重发时用了不同的业务流水号。原因就是bizFlowNo生成规则没设计好实时时间戳加随机数导致同一操作的两次重试生成了两个不同流水号。医保端的幂等键失效了。解决方法业务流水号必须从操作上下文生成我用的规则是“就诊ID 费用批次号 结算类型 重试序号”其中重试序号只在真正重试时加一。也就是说同一笔费用不管点几次结算第一次生成的流水号不变重试只是带同一流水号再发一次。5.3 报销金额一分钱对不上账四舍五入时机不对现象是医保端返回的统筹支付金额和本地引擎算出的结果差了几分钱财务对账的时候怎么都对不上。原因出在四舍五入的时机。本地方案是每笔费用明细都先算一次乙类自付金额各自四舍五入到分再汇总医保端是先把所有乙类自付按高精度累加最后统一四舍五入。两种算法在大量费用明细时会差几分钱。解决方法是全链路统一用DECIMAL高精度累计只在最后一步输出金额时四舍五入到分。Python 里不要用 float 做金额运算要用Decimal数据库里金额字段全部用DECIMAL(12,2)中间过程的分类表字段可以放宽到DECIMAL(14,4)最后汇总时再统一保留两位。5.4 患者跨院重复开结算单就诊主索引没打通现象是同一患者在两家医院分别以不同就诊号办理了住院两边各自结算医保端提示重复报销。原因是医保端只认身份证号但医院信息系统内部用就诊号当唯一键没有做身份证号层面的去重。解决方式是建立患者主索引表以身份证号为主键关联本地的多个就诊号。每次新开结算前先查一下该身份证号是否存在未完结的住院结算存在则提示先处理旧的。这个检查放在医院信息系统端做不要依赖医保端的返回。5.5 高峰时段结算大面积超时前置机连接池被耗尽现象是每天上午十点左右的结算高峰窗口反应结算响应要转圈十几秒随后一批请求超时。看前置机日志连接池一直报“连接不可用”。原因是默认连接池配置太保守最大连接数为10而医院信息系统的并发结算请求峰值超过30。请求全部阻塞在等连接上超时后重试又加重阻塞形成雪崩。解决方式是给前置机连接池做容量评估按“窗口数 × 每窗口并发 × 系数”来配。我调过的项目最终配置是最大连接数50空闲超时60秒。同时加上熔断机制连续5次请求异常时直接返回“系统繁忙”给收费端而不是继续把请求打进已经拥堵的连接池等30秒后再降级重试。这个手段主要用来给医院信息系统一个明确的错误信号让收费员能转向手工登记流程。6. 想少填坑先做一个“模拟结算器”和对账脚本最后一章写一个我坚持了很久的习惯任何结算系统上线前先做一个独立的模拟结算器再配一个自动对账脚本。这两个工具加起来不到200行代码但每次政策参数调整、目录换版后它们都是第一道防线。模拟结算器的作用很简单本地输入一批费用明细模拟医保端可能的结算结果输出一张模拟结算单。依赖同一套引擎但故意保留差异——参数表可以临时改、目录匹配可以按旧版跑用来验证“如果医保端算的和本地不一样会是差在哪一步”。自动对账脚本更实用。核心逻辑是医院信息系统的费用明细累计金额应该等于结算记录里的总金额而医保端返回的统筹支付、个账支付、现金自费合计也应该等于结算记录里的实付合计。两边做一个交叉验证import json, sys def check_settlement(settle_file, his_file): 校验本地结算结果与HIS侧费用汇总是否一致 with open(settle_file, r) as f: settle json.load(f) with open(his_file, r) as f: his json.load(f) s_total settle[totalAmount] s_pay (settle[overallPay] settle[personalAccountPay] settle[cashPay]) h_total his[totalAmount] errors [] if abs(s_total - h_total) 0.01: errors.append(f总额不一致: 结算单 {s_total}, HIS {h_total}) if abs(s_total - s_pay) 0.01: errors.append(f费用拆分不平: 总额 {s_total}, 支付合计 {s_pay}) if errors: print(\n.join(errors)) sys.exit(1) print(对账通过) check_settlement(settle_result.json, his_fee.json)这个脚本的输出只有两种结果通过或者明确指出哪一项不平。上线初期我每天都跑一遍跑出来的差异先交给人工判断是引擎问题还是参数问题修正后把规则固化到自动化测试里。后来慢慢形成一套回归用例集每次改参数版本跑一遍全套用例比上线后被医保端拒掉再排查要省太多时间。我做结算系统这几年最大的教训就是不要在患者窗口前试错。所有参数、目录、报文格式的验证都在模拟结算器上先做掉。工具不复杂但能在换版日那一天让你睡得着觉。希望帮到你。本文还有配套的精品资源点击获取