简介：这是一套面向小型诊所与基层医疗机构的轻量级HIS系统源码包，基于ASP.NET技术构建，以C#源代码、aspx页面、JavaScript与CSS前端文件为核心，同时包含DLL库、配置文件及少量可执行程序，便于开发者直接编译部署或进行功能扩展。压缩包共451个文件，体积约7.05MB，其中cs源文件数量最多，其次为png/jpg/gif图片素材与js/css页面资源，另有doc/docx说明文档、Excel示例数据以及Contract_Web合同网页文件，目录结构清晰，适合快速浏览和二次修改。目前已有284人学习下载，对于刚开始接触医疗信息化或需要搭建基础HIS系统的中小项目来说，是一份低门槛的参考资料。该简化版覆盖病历管理、挂号、药品、收费、统计报表、医生排班与患者追踪等核心模块，配合界面截图和示例数据，可帮助技术人员理解医院信息系统的业务闭环与典型功能划分，也可作为同类系统开发时的模块参考和基础脚手架。
1. 一个 .rar 里的“商业 HIS”：它解决谁的问题，解决不了谁的问题
先想一个问题：一家只有五六个诊室、日均门诊量不到两百的小机构，要上 HIS 系统，启动成本得是多少？挂一个含实施、培训、接口改造在内的全院级方案，报价经常是几万起步，周期按三个月算。而“超级简单版本商业HIS系统.rar”这个标题指向的，是另一种东西：不到一天能跑起来、只覆盖门诊核心流程、但收费退费日结逻辑完整的一套轻量级系统。它不是给大三甲用的，它服务的是小门诊、社区卫生站、体检中心，以及给这类机构做信息化外包的开发者。
这套东西被冠以“商业”二字，意味着它不是一个只演示界面跳转的教学 Demo——它必须处理发票号连续性、退费校验、日终汇总、药品库存扣减这些真实收费场景里的硬需求。“超级简单”说的是部署和操作门槛低：解压、导数据库、改配置、启动，四步走完就能挂号收费。但它解决不了医保对接、电子病历评级、检验检查设备接入这类复杂集成问题，如果你带着这个预期去拆压缩包，大概率会失望。适合它的读者是两类：一类是自己的小机构想摆脱 Excel 记账，另一类是要快速交付一个可用门诊系统的开发者。这篇笔记就按“拆开之后怎么验证它值不值得用、怎么跑通、怎么改造”这条路来写。
2. HIS 的核心业务闭环：挂号、收费、退费、药房，一个都不能少
2.1 轻量级 HIS 的模块边界：为什么“简单版本”也要保留发药扣库存
很多开发者拿到一个标注“超级简单”的 HIS 源码，第一反应是看登录页漂不漂亮、菜单有多少个。真正决定这套系统能不能在真实门诊用起来的，是它的业务闭环是否完整。一个最小的商业门诊 HIS 至少要包含五个不可拆的环节：挂号建档、医生开方、收费确认、药房发药、日终结账。这五个环节里砍掉任何一个，系统就会退化成“Excel 换皮”。
“商业”两个字和“教学 Demo”最本质的区别就在收费和库存的关系上。教学项目经常允许你直接改数据库里的金额字段，或者收费之后药房库存纹丝不动。商用场景里，收费成功后药品库存必须实时扣减，退费后库存要回补，月底盘点时系统库存要和实物对得上。这个约束决定了数据库表设计里必须有独立的库存表和库存流水表，不能只在药品字典表里放一个“库存数量”字段让人乱改。
从选型角度讲，这套“超级简单版本”通常走的是 Java Web 或者 .NET 的老牌路线，前端是浏览器访问的架构，而不是现在流行的前后端分离加微服务。原因不难理解：小门诊没有专职 IT 人员，部署环境就是一台普通 Windows 电脑加 MySQL/MSSQL；单体应用加上少量网页就足以支撑几十个并发请求，微服务在这种场景下只会增加排障成本。你拿到压缩包后先别急着跑，花十分钟在源码里找到实体类或者数据库脚本，数一下包含多少个业务表——超过二十张表说明它是完整版精简而来，低于十张表你就要警惕它是否砍掉了库存或日结。
2.2 从挂号到日结：一张收费流水表如何撑起整个门诊闭环
整个门诊 HIS 的业务状态，几乎都围绕一张核心的收费主表展开。挂号时产生一条挂号记录，医生开方后生成处方明细，收费确认时把这些明细汇总写入收费主表并标记为“已收费”，药房看到已收费的处方进行发药，同时把处方明细里的药品消耗写入库存流水。到下班前，日结功能把所有已收费记录汇总成一张报表，收费员按这个数把钱交给出纳。
这个闭环里最关键的设计是状态字段。以收费记录为例，通常有“未收费 / 已收费 / 已退费 / 已作废”四种状态。发布为“商业”用途的系统，对这四种状态的流转有严格限制：一张收费记录只有在没有关联发药记录的前提下才能退费；先退费再退药，还是先退药再退费，两种顺序对应不同的库存回补时机。你拿到源码后，去 service 层找一个包含 refund 或 cancel 单词的方法，看它如何在代码里判断状态，就能判断这套系统的收费逻辑是否严谨。
表结构里还有一个容易被忽略却承载核心业务的表：支付方式流水表。即使是“超级简单”版本，也必须区分现金、微信、支付宝、银行卡四种支付方式，因为日结报表要按支付方式分别汇总。支付方式通常不作为收费主表的一个字段，而是单独一张子表，这样一次收费支持组合支付：患者带了一百元现金，剩下八十元扫码，这在真实门诊里非常常见。
除此之外，挂号时要生成一个全局唯一的就诊流水号，这个号在医生站、收费处、药房三处保持一致。我见过最省事的实现是把就诊流水号设计成“日期+当日自增序号”，比如202411260021表示当天第 21 个病人。这样设计对开发者和操作员都直观，但也对并发控制有要求——需要数据库锁或唯一约束保证同一天内不会生成两个同样的序号。验证一个 HIS 是否够“商业”，直接看它对重复号的防御：先到挂号桌面端连续快速挂号，观察是否有重号提示，这是最廉价的测试方法。
3. 本地部署这套 HIS：环境清单与最小启动命令
3.1 解压之后的第一件事：先看清楚目录再动手
双击 .rar 解压之后不要急着找启动按钮。先观察目录结构。一个按标准工程组织方式打包的 HIS，解压后通常会看到下面几类东西：源码目录（Java 的 src 或 C# 的项目文件）、数据库脚本目录（通常是一个 .sql 文件或一个 sql 文件夹）、部署目录（打包好的 war/jar 或 exe）、使用文档。我建议先打开数据库脚本，因为从建表语句里能看出这套系统的真实业务边界。
找到目录里名字叫his.sql或database.sql的脚本后，用文本编辑器打开，搜索关键字。重点搜索三张表的建表语句：药品库存表、收费主表、操作员表。如果三张都能找到，说明业务闭环大体完整。如果只搜到用户表和菜单表，那这套系统的“商业”含量就很低，你只能拿它当作学习素材。目录里还要找配置文件，Java 系统通常是application.yml或jdbc.properties，.NET 系统通常是web.config或App.config，它们记录着数据库连接信息。
这里有个容易踩的坑：有些压缩包解压后里面是另一个压缩包，或者里面套了一层以项目名命名的文件夹。这不是作者故意折腾你，而是因为很多开发者在打包时直接压缩了工程根目录。遇到这种情况不要重复解压到当前文件夹，而是解压到独立目录，否则路径层层嵌套，后续 IDE 导入和命令行定位都会变得混乱。我的习惯是统一解压到D:\work\his_project这种不含中文和空格的路径下，数据库配置和日志输出很多地方会拼接绝对路径，中文路径在某些旧版组件里会直接导致启动失败。
3.2 用两条命令把整套系统跑起来：最小启动顺序
在 Windows 环境部署一个 Java 系的 HIS，最常见方式是把前端资源打包进 Spring Boot 的 jar 里，这样一个 jar 就是完整应用。解压目录里找到以.jar结尾的文件后，先确认本机 JDK 版本。这套老牌技术栈通常要求 JDK 8 或以上，过高版本有时反而不兼容——JDK 17 上运行 JDK 8 编译的旧 jar，在多处反射调用场景下可能抛异常。
先导入数据库，再启动应用，这个顺序不能反，否则应用启动时会因连不上数据库而直接报错退出。数据库导入和启动应用两个动作，用下面两段命令就够了：
# 1. 导入 HIS 数据库脚本到 MySQL mysql -uroot -p --default-character-set=utf8 < D:\work\his_project\database\his.sql # 2. 启动 HIS 服务端应用（Java 单体包） cd /d D:\work\his_project\server java -jar his-server.jar --server.port=8080第一段命令中--default-character-set=utf8是很多第一次部署 HIS 的人最容易漏掉的部分。如果数据库脚本里有中文备注或者初始化菜单数据，缺少这个参数在 Windows 的命令行环境下容易写入乱码，等启动后登录系统，界面里所有菜单都是问号。第二段命令中--server.port=8080是 Spring Boot 参数覆盖的一种写法，它优先于配置文件里的server.port，这样你不用修改 jar 包里的配置文件也能切换端口，便于同时启动两套环境做对比验证。
启动成功的标志不是命令行窗口不报错，而是看到日志输出一行Started HisApplication in xx.xxx seconds或Tomcat started on port(s): 8080。看到这行再打开浏览器访问http://localhost:8080。如果日志停在启动过程一半就停住不动，多半是数据库连接配置有问题，下一节会讲具体排查。
3.3 必调的三个配置项：数据库密码、端口、时区
启动 HIS 之前，你几乎一定要改配置文件。无论是 jar 包旁边的application.yml，还是源码工程里的application-prod.yml，核心配置内容都是一样的。下面这个配置片段是从典型 HIS 工程里提取出来的，注意它是示例，不是某个特定项目的原稿，但配置项名称就是这几个：
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/his_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: "123456" driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true三个最常出问题的地方：第一个是password，数据库密码如果包含特殊字符如@、#、:，必须用双引号包裹，否则会被 Spring 的配置解析器截断。第二个是serverTimezone=Asia/Shanghai这个参数，MySQL 8.0 驱动要求强制指定时区，不指定会在启动时报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized的错，中文环境下经常出现。第三个是useSSL=false这个参数，开发环境默认 MySQL 不开 SSL，但新版驱动默认会尝试使用 SSL 连接，导致首次连接需要额外的时间甚至直接报错，建议在 url 里显式加上。
map-underscore-to-camel-case: true这个配置值得一提。数据库里的字段命名习惯是patient_name、create_time这样的下划线风格，而 Java 实体类里通常是patientName、createTime的驼峰风格。没有这个配置，MyBatis 查询返回的结果里这些字段会为 null，表现是挂号之后患者名字显示为空。如果你看到界面列表其他列都有值，唯独几个带下划线的列是空的，第一个要检查的就是这个配置。
4. 数据库初始化的四个关键维度：药库、收费项目、科室、用户
4.1 药品字典与库存期初：为什么必须先建药品再建收费项目
初始化一个 HIS 系统，大多数人的第一反应是先把用户账号建好登录进去看看界面。但在“商业”场景里，药品字典和收费项目直接决定门诊能否正常开张。如果一个药品没有在药品字典里建档，医生在开方界面就检索不到它，收费处也无法对它收费。更隐蔽的是药品字典和收费项目常常是两张独立的表，通过一个药品 ID 关联。
正确的初始化顺序应该是：先建药品字典，再建收费项目，最后做库存期初。因为收费项目中的药品收费项需要引用药品 ID，引用关系要求在数据上先有被引用的记录。下面的 SQL 展示了典型的两步插入操作：
-- 1. 插入一条药品字典记录 INSERT INTO his_drug (drug_code, drug_name, spec, unit, manufacturer, price, pinyin_code) VALUES ('DY0001', '阿莫西林胶囊', '0.25g*24粒', '盒', '某制药厂', 12.50, 'AMXL'); -- 2. 插入一条对应的收费项目记录，关联药品 ID INSERT INTO his_charge_item (item_code, item_name, category, price, drug_id, status) VALUES ('XM0001', '阿莫西林胶囊(0.25g*24粒)', 'DRUG', 12.50, LAST_INSERT_ID(), 'ENABLED');第一条语句里的pinyin_code是商业 HIS 里特别实用的设计：医生开方时不输入汉字，直接输入药品名称的拼音首字母缩写“AMXL”就能检索到阿莫西林，这个字段对门诊录入效率影响很大。第二条语句里LAST_INSERT_ID()是 MySQL 里的一个语法，它返回上一条 INSERT 语句自增主键的值，这样收费项目通过drug_id关联到药品。如果你在业务界面上操作而不是直接执行 SQL，系统内部也是执行类似的逻辑。
category字段区分收费项目类型：DRUG代表药品，EXAM代表检查，LAB代表检验，TREAT代表治疗。这个分类是日终统计报表的透视维度，也是后续改造医保接口时需要映射的字段。如果一套系统里所有收费项目都是TREAT类型，后续做科室收入统计时你会查得很痛苦——每种项目处方量无从区分。
4.2 科室与用户权限：医生、收费员、药房三种角色别混用
用户初始化有一个新手极易翻车的点：以为只要建一个账号就能让所有人用。商业 HIS 的权限一定分角色，最常见的角色划分是医生、收费员、药房操作员、管理员四类。医生账号登录后只能看到开方和患者列表，收费员账号只能看到收费、退费和日结操作，药房账号只看到待发药处方。如果为了省事把所有账号都设成管理员，系统任何环节出了问题都会分不清责任。
创建角色和用户的 SQL 大体是两条语句，先建角色并授权，再建用户并分配角色：
-- 创建医生角色并赋予开方权限 INSERT INTO his_role (role_code, role_name) VALUES ('DOCTOR', '门诊医生'); INSERT INTO his_role_perm (role_id, perm_code) SELECT r.id, 'patient:list' FROM his_role r WHERE r.role_code = 'DOCTOR' UNION ALL SELECT r.id, 'prescription:add' FROM his_role r WHERE r.role_code = 'DOCTOR'; -- 创建一位医生账号并绑定角色 INSERT INTO his_user (emp_no, real_name, login_name, password_hash, role_code, dept_id) VALUES ('E001', '某医生', 'doctor01', SHA2('123456', 256), 'DOCTOR', 'D001');这里特别提一下password_hash。商业系统里密码不能明文存储，上面用SHA2('123456', 256)是一种简化写法。老系统更常见的是加盐的 MD5，新系统应该用 BCrypt。你拿到源码后，去UserService或LoginController里看一眼登录时的密码校验逻辑，如果看到PasswordEncoder或BCrypt字样，说明这块是合格的；如果看到把数据库密码字段直接拿出来和输入做字符串比较，那这套系统离“商业”还有距离，交付时要先补这个漏洞。
还要检查dept_id和挂号科室是否联动。医生登录后，开方界面默认患者归属的科室就来自这个字段。多个医生共用一个科室是常态，一个医生同时在两个科室坐诊的情况不多见，但“超级简单版本”通常不支持这种复杂排班，如果需要支持，就得通过额外一张关联表实现，这也是评估这套系统二次开发量时的一个重要参考维度。
5. HIS 实施中的常见坑：5 个最容易翻车的点
5.1 药房库存变成负数
现象：某天药房发药后，药品库存表里出现负数，发药记录是成功的，没有报错。到月底盘点时，账面库存比实物少了十几盒。
原因：最常见是收费和发药之间缺少库存预扣机制。收费完成时没有锁库存，药房发药时直接执行库存扣减，却没有任何对库存充足性的判断。两个患者同时交费买同一种药，系统检查库存时都发现余量足够，先后各扣一次，后扣的那次就把库存扣穿为负数。
解决：把库存扣减操作改造成“条件扣减”。一句话解释就是 UPDATE 语句在扣减时检查剩余量，这个动作要在数据库层面完成：
-- 条件扣减：库存充足才扣减，影响行数为 0 说明库存不足 UPDATE his_drug_stock SET stock_qty = stock_qty - 1 WHERE drug_id = 1001 AND stock_qty >= 1;在 Java 代码里执行这条 UPDATE 后，检查返回值：如果影响行数为 1，说明扣减成功；如果为 0，说明库存不足，此时程序应中止发药并提示药房人员。这种“乐观锁”写法避免了先查库存再扣减的竞态窗口，是解决负库存最廉价有效的手段，不需要引入 Redis 分布式锁。
5.2 退费之后发票号对不上
现象：退费一笔 120 元的药品费用后，重新开一张发票，发票号跳了好几号，或者发票号与收费记录号无法一一对应。日终交账时，财务问为什么中间缺号。
原因：系统把发票号的生成放在收费成功时，而退费时复用了原来的发票号，没有重新分配。更常见的做法是发票号和收费流水号共用同一序列，退费的那条记录还占着号，导致后续所有单子的号码都比实际顺序多一位。
解决：如果系统允许退费，就必须区分“收费流水号”和“发票号”两个概念。收费流水号是内部业务标识，一路贯穿挂号、处方、发药；发票号是财务对外凭证，每次收费成功时从发票序列器中取号，退费时将原发票号作废，重新收费时再取新号。验证方法是做一笔退费再重收，重收后的发票号应该是当前新号而不是沿用旧号。如果源码里退费和收费共用同一个取号方法，需要拆分成两个计数器。
5.3 日终汇总不平：收费金额和明细对不上
现象：晚上做日结，收费员交班的现金总额和系统日结报表差了几块钱。报表上显示现金收费 2380 元，收费员口袋里是 2375 元。
原因：对不上不一定是系统错了，先查这几个原因：退费时退还的金额是不是原路退回；患者用组合支付时（比如现金加微信），日结报表是否把两笔拆分正确汇总；还有一种隐蔽原因是收费时患者说不要零头，收费员手动改了金额，系统记录的是改之前的数，交的钱是改之后的数。
解决：日结不平不能靠“看情况”解决，要在系统设计上把改动的后门堵死。收费金额字段在收费完成后应设为不可修改，任何调整只能通过“作废重收”流程处理。日结报表不仅要显示应收金额，还要显示每笔收费的支付方式拆分明细，并在交班界面提供“短款/长款”录入入口——商业系统不是不允许有差异，而是要求差异有记录、有责任人。拿到源码后重点看收费主表上的金额字段是否有更新操作，如果 mapper 里有针对金额字段的update set amount =动态 SQL，就要考虑去掉。
5.4 并发挂号产生重号，患者排到同一个号
现象：上午 9 点到 10 点就诊高峰，两个挂号窗口同时操作，系统里出现了两个相同的就诊流水号。接诊医生端一阵乱：来两个病人都报同一个号。
原因：就诊流水号是由代码里“查当前最大号，再对最大号加一”生成的。两个窗口同时读到最大号 89，各自加一都生成 90，然后先后插入数据库。在无锁、无唯一约束的情况下，第二个人插入不会报错，重复号就这样产生了。
解决：在数据库层面加唯一约束是治本的方法。就诊流水号字段加唯一索引意味着第二次插入相同号码时直接被数据库拒绝，程序捕获异常后重新生成。如果用上一章提到的“日期+当日序号”格式，唯一索引应该建立在(visit_date, visit_seq)联合字段上，而不是只对整串字符串加索引。治标的办法是在生成号之前先对当日挂号表加锁：
-- 先用悲观锁锁住当日最大号，再生成新号 SELECT COALESCE(MAX(visit_seq), 0) + 1 FROM his_registration WHERE visit_date = '2025-01-08' FOR UPDATE;FOR UPDATE锁会阻塞其他窗口的同一查询，直到当前事务提交或回滚。你的判断依据是：如果 HIS 运行在 MySQL 默认的可重复读隔离级别下，这个锁是有效的。如果系统部署在云数据库且开启了读写分离，主从延迟会导致“查最大号”查到旧值，这种情况下只依赖这个办法是不够的，必须辅以唯一索引兜底。
5.5 部署时端口冲突与数据库连接失败
现象：jar 启动后，日志报Port 8080 was already in use。另一台电脑上启动时，日志报Access denied for user 'root'@'localhost'。
原因：端口冲突是因为机器上已有的程序占了 8080 端口，最常见的是其他 Web 开发环境自带的 Tomcat 或 Nginx。数据库连接失败通常是密码错误或数据库名称错误。
解决：端口冲突用一行命令找出占用者：
# 查看 8080 端口被谁占用 netstat -ano | findstr :8080命令输出的最后一列是进程 PID，到任务管理器的“详细信息”里找到对应 PID 的程序名，就能判断是哪个服务占用。如果不是可关闭的服务，就用启动命令里的--server.port=9090换个端口启动。数据库连接失败则确认服务名、用户名、密码、库名四要素逐一核对，不要凭记忆输入密码——直接用命令行客户端测试连接：
mysql -uroot -p -h 127.0.0.1 -P 3306 his_db这个测试能排除程序本身的问题：如果命令行能进入数据库，而应用还是报连接失败，检查目标库是否建表完成——用USE his_db; SHOW TABLES;确认是否为空库。空库或缺少表时应用启动可能不会报错，但登录时提示“操作员不存在”或“菜单加载失败”，往往就是这个原因。
6. 把“超级简单版本”改造成可交付方案：三个必须补强的动作
6.1 把管理员账号改成“最小权限”模式
默认压缩包里通常有一个超级管理员账号，密码固定，角色权限是“全部”。交付给机构时不能保留这个状态，否则每个知道密码的人都能改药品价格、调患者记录、查看日结报表。我的做法是把超级管理员账号降级为“系统维护”角色，只保留字典维护、用户管理和数据库备份查看权限；门诊业务统一用医生、收费员、药房三种角色账号。执行完权限调整后，用收费员账号登录一次，确认看不到医生开方菜单，再用医生账号登录，确认看不到日结按钮。
更彻底的做法是让启动过程强制修改初始密码：在数据库用户表里加一个字段pwd_changed，登录时判断这个字段为 0 就跳转修改密码页面。这个改造对“商业”交付来说不是加分项，而是必选项——很多小机构根本没有安全意识，如果你不拦住他，他会用默认密码用三年。
6.2 用一段 SQL 写日终对账脚本，替代人工盯报表
“超级简单版本”自带的日结报表很可能只做总数展示，不会帮你核对差异。我习惯写一个对账 SQL，每天下班后在数据库里执行，输出结果和收费员交班金额做比对。脚本的核心是把“收费科目”拆到按支付方式统计的粒度：
SELECT DATE(charge_time) AS biz_date, pay_method, COUNT(*) AS charge_count, SUM(amount) AS charge_total FROM his_charge_detail WHERE charge_status = 'PAID' AND DATE(charge_time) = '2025-01-08' GROUP BY biz_date, pay_method ORDER BY pay_method;这个查询输出就是一份最小的日终结账表。注意charge_status = 'PAID'这个过滤条件，它排除了已退费记录，避免把退掉的金额还统计在收入里。实际使用时，我会再加一个refund_total的小查询，单独把当日退费金额汇总出来，并在日结表里单列一列“退费金额”。这样交班时收费员看着报表逐一核对，有差异能瞬间定位是现金短款还是某笔退费记错。
6.3 数据备份与恢复：商业交付里最后一道保险
很多开发者交付 HIS 时忽略备份，这是最危险的习惯。门诊的数据非常真实，患者挂了号、开了药、收了费，这些数据无法在事后重新录入一次。我的习惯是在服务器上放一个定时任务，每日凌晨做一次全量备份，保留最近 7 天的备份文件：
# Windows 计划任务调用的备份脚本 mysqldump -uroot -pYourPassword his_db > D:\backup\his_%date:~0,4%%date:~5,2%%date:~8,2%.sql%date:~0,4%%date:~5,2%%date:~8,2%是 Windows 批次处理里的日期格式化写法，生成的文件名类似his_20250108.sql，按天区分。恢复时执行mysql -uroot -p his_db < 备份文件.sql即可。这个脚本里密码直接写在命令里，虽然不安全，但在内网单机部署场景下是普遍妥协做法；如果你能把备份逻辑改写成配置文件读取密码，会更好。
我自己第一次交付这类系统时，就是忘了一件事：要给机构的人留下“一键恢复”的方法。我写了备份脚本，却没写恢复脚本，结果半年后对方把一台电脑的系统盘格了，数据全丢。后来我把恢复脚本打印出来贴在主机箱上，电话支持时让对方照着敲，十分钟就恢复了。从那以后，凡是我经手的 HIS 交付，恢复步骤永远和备份脚本放在同一个文件夹里，并且用纯文本格式写清步骤，不依赖 PDF。这份细心，也算这套“超级简单版本”走向真正商业交付时最值得保留的习惯之一。希望帮到你。
本文还有配套的精品资源，点击获取
