企业官网建设流程全解析

简介：这份数据库设计案例文档围绕酒店管理系统展开，覆盖总经理、财务、住宿、娱乐四大子系统的功能划分与数据表设计，面向数据库初学者、高校相关专业学生及需要完成课程设计或毕业设计的开发者。文档共1个doc文件，压缩包大小约233KB，内容以文字说明加数据字典为主，便于直接阅读、复制和二次修改。文中对每张表都列出了字段名称与含义，如职工信息表、部门信息表、收入支出登记表、客人信息表、房间管理表、娱乐项目表等，并给出各子系统的业务处理流程，能够帮助读者理解从需求分析到概念结构、逻辑设计的完整思路。该资料已有256人浏览学习，适合作为课堂补充或自学的参考资料，可按自身项目需求提取其中的表结构、关系划分和数据字典撰写方法。

1. 数据库设计不是画图：酒店管理系统设计稿的价值点在哪

先给结论：这份酒店管理系统数据库设计文档最值钱的部分不在那张总 E-R 图，而在从部门需求一路走到范式判定的完整推导链。它把中等规模酒店的业务抽象成四个子系统，再从分 E-R 图集成到全局 E-R 图，最后逐张表分析 BCNF、3NF 和冗余取舍——每一步都有明确理由，而不是画完图直接丢出“表就这么多”。适合三类人：做毕业设计需要数据库设计文档的，刚学完范式理论想看看实战怎么用的，以及要评审数据库设计报告的业务开发。我拆完整份文档后发现，它几乎完整复刻了教材里概念结构设计到物理结构设计的每个环节，连视图集成的三类冲突都逐条排查过。下面按设计流程的推进顺序来拆。

2. 从部门划分到分E-R图：四个子系统建模决策与实体划分

先看需求怎么切。原文按物理部门把酒店业务拆成四块：饮食、住宿、娱乐、经理。多数人拿到这个需求会直接按四个部门建表，但这份设计做了两件关键的事。第一，饮食部门除了财务，其余操作全部放弃入库，理由是实时性强、数据无需长期保留，手工登记比电脑录入更高效；第二，四个部门各自的财务处理被抽出来合并成一个统一的财务子系统。这个抽象是整个设计的支点，后面所有分 E-R 图都围绕它展开。

2.1 子系统职责边界：哪些业务入库、哪些业务弃用

饮食部门的实时性判断值得单独说。餐饮场景里，顾客点菜、加菜、退菜是高并发短事务，而且菜品信息没有跨期查询需求，强行入库反而增加录入成本和数据噪音。所以设计稿只保留饮食的财务结果，菜品种类、消费明细全部不进数据库。这个决策的边界在于：它默认酒店不做菜品成本分析和原料库存核算。如果有食材供应链、促销活动或会员积分需求，这套简化就必须推翻重做。

住宿部门则相反，所有信息都适合入库。来客登记、房间状态、收费标准、客满程度、部门财务流动，这些数据既要实时更新又要长期保留，是典型的事务型数据。娱乐部门介于两者之间，需要入库的是收费标准、项目信息和财务收支，而具体娱乐消费过程同饮食部门一样被舍弃。经理部门的职责集中在职工、部门、工资和财务核算上，全部需要入库。

四个子系统的职责边界确定后，原文做了一次重要归并：各子系统内部都有财务处理，且结构相似，干脆统一抽到一个财务子系统里。饮食子系统被取消，因为它的所有功能已经并入财务子系统。最终系统分为总经理子系统、财务子系统、住宿子系统、娱乐子系统四部分。这个设计手法值得注意——它不是按物理组织架构硬切，而是按数据特征和功能重叠度重新划分边界。

2.2 分E-R图的属性与实体划分：三条调整准则

在经理部门的分 E-R 图里，原文给出了三条具体调整，这三条是“属性和实体划分”准则的实战样例。

第一条，职工本应对应领导关系，但为了简便，用职工的“等级”属性来表示职工之间的领导关系。这在小型系统里是合理的。领导关系本身没有额外的描述信息，比如任职时间、分管范围、汇报线，那么它就只是一个属性级的概念，不值得单独建实体。若哪天要查“张三从什么时候开始当经理、管哪几个部门”，这个简化就不够用了。

第二条，工资本应作为职工的一个属性，但这里需要强调职工对应的出勤工资，而且出勤工资由考勤情况决定，所以把工资单独作为一个实体。判断标准很清晰：一个信息是否还需要被进一步描述。如果工资只是职工表里的一个数字字段，那放在职工表里没问题；但出勤工资需要记录基本工资、出勤工资、实际工资的构成逻辑，独立实体更合理。

第三条，各部门对应的账单先在子系统中进行财务总结，因此账单也作为一个实体。这里的设计意图是让每个子系统先完成局部财务汇总，再交给财务子系统做全局合并，避免财务子系统变成一个所有明细数据的堆积点。

娱乐子系统的分 E-R 图沿用同样的调整逻辑。顾客、项目、职工、账单、款项、折扣规则被列为实体，其中“款项”本可以作为顾客的一个属性，但为了记录折扣计算过程，单独提升为实体；顾客被加了一个“级别”属性，用来对应折扣规则。这个处理手法在业务上有点简化过头——真实酒店的折扣通常由协议价、会员等级、季节浮动综合决定，单一级别字段只能覆盖最简单场景，扩容时会产生额外改造。

2.3 住宿子系统的实体边界：订单、客房与顾客的三角关系

住宿子系统比前面几个复杂，分 E-R 图里出现了顾客、客房、职工、订单、款项、折扣规则、账单七个实体，核心关系围绕“入住与预订”展开。

顾客和客房之间存在 n:m 的住宿联系，因为一个顾客可以多次入住不同房间，一个房间在不同时间接待不同顾客。顾客和订单是 1:1 联系，一次预订对应一个订单记录。订单和客房形成 n:m 的预约联系——一个订单可以预约多个客房，一个客房也可以被多个订单在不同时间段预约。这里订单实体承担的核心职责是预订动作本身，它不关心入住后的财务计算，只记录订单号、时间、房间号、经手人和备注。

住宿子系统的实体属性定义里有个细节，客人信息中“多人同住一个房间只作一个记录”，以联系人为记录主对象。这在数据库建模上是把“房间-入住批次”当做一个事实记录处理，而不是把每个住客都注册为客户主数据。对于公安实名登记要求严格的场景，这个设计需要改造，但作为校园级设计案例，它的口径是自洽的。

下表把四个子系统对应的核心关系模式做了一张映射，方便对照原文的分 E-R 图到最终关系模式的走向：

各分 E-R 图设计完成后，下一步是集成。但这里要记住一个前提：分 E-R 图的质量决定集成的工作量。原文之所以后续冲突排查很快，就是因为前面把该提级为实体的属性都提完了，该合并的联系都合并了，集成阶段自然顺畅。

3. 视图集成与联系转化：冲突处理、关系模式与范式权衡

四个分 E-R 图画完，进入视图集成阶段。原文声称系统简单、分 E-R 图规模小，所以直接一次集成，分两步走：先合并解决各分图之间的冲突，生成初步 E-R 图；再消除不必要的冗余，生成基本 E-R 图。其中第二步因为本来冗余就少，初步 E-R 图直接当基本 E-R 图用，没有再调整。

3.1 视图集成冲突排查：属性、命名、结构三类逐一过

视图集成中最容易被低估的是冲突排查。原文把冲突归成三类，每类都做了检查，这个检查清单值得保留下来复用到自己的项目里。

属性冲突包含属性域冲突和取值单位冲突。属性域冲突指的是属性值的类型、取值范围或取值集合不同。例如“客房号”在住宿子系统里定义为数字串，在财务子系统里可能被引用为字符串；如果两个子系统都用“客房号”这个字段名但底层类型不一致，合并时就会出现属性域冲突。原文说系统简单所以不存在这类冲突，但真实项目里这种冲突非常常见，比如一套系统里有的部门用“房间编号 R001”的格式，另一个部门用纯数字“1”，集成时必须统一。

命名冲突包含同名异义和异名同义。同名异义是同一个字段名在不同部门含义完全不同，最典型的是“编号”——住宿子系统的“编号”指房间号，财务子系统的“编号”指账单编号，娱乐子系统的“编号”指项目编号。异名同义是不同名字指同一个概念，比如“顾客号”和“客人编号”其实是一个东西。

结构冲突是这三类里最值得展开的。原文提到同一种情况：同一对象在不同应用中具有不同的抽象，在某个分 E-R 图里它是属性，在另一个分图里它是实体。比如“部门”在经理子系统里是实体，在财务子系统的 E-R 图里可能只作为查询条件出现。处理办法原文给得很明确：只要在任何一个分 E-R 图中作为实体出现，全局就统一按实体对待。宁可在不需要的地方多建一个实体，也不能让同一个对象在总图里既是实体又是属性，那样会直接干扰后续关系模式转换。

3.2 联系转关系模式：1:1合并、n:1落多端、n:m独立建表

逻辑结构设计的核心工作是把 E-R 图转成关系模式，而联系的处理规则决定了表的数量和结构。原文的处理策略完全是教材级别的：

1:1 联系与某一端实体关系合并。工资和职工之间 1:1，合并进职工关系；顾客和订单之间 1:1，合并进订单关系；折扣规则和款项之间 1:1，合并进款项关系。这样做的原因是 1:1 联系不会产生多值依赖，任意一端持有对方主键作为外键即可。

n:1 联系与多端实体关系合并。职工和部门之间 n:1，把部门号并入职工关系；部门和财务状况之间 n:1，把财务状况编号并入部门关系；客房和部门之间 n:1，把部门号并入客房关系；项目和部门之间 n:1，把部门号并入项目关系；总帐和财务状况之间 n:1，把财务状况编号并入总帐关系；账单和总帐之间 n:1，把总帐编号并入账单关系。规则一句话：谁多谁带外键。

n:m 联系必须独立建关系模式。原文明确列出了三个：客房和订单之间的预约联系转成预约关系模式；顾客和客房之间的住宿联系转成住宿关系模式；顾客和项目之间的选择联系转成选择关系模式。原因在于 n:m 联系自身可能产生新的属性——预约有始定时间和结束时间，住宿有住宿时长，选择有发生时间和经手人，这些属性无法塞进任何一端，只能单独建表。

这段处理逻辑的完整对应用表列出：

3.3 规范化判定：BCNF打底、3NF补位、一处1NF故意保留

关系模式确定后，原文逐一做了函数依赖分析和范式判定。绝大多数实体关系模式被判定为 BCNF，三个由 n:m 联系转化来的关系——预约、住宿、选择——被判定为 3NF。3NF 和 BCNF 的差别在这些联系表里体现得很具体：预约表的主键是订单号加客房号，其中订单号依赖顾客号，但顾客号不是候选键的一部分，存在传递依赖的残余；如果强行拆到 BCNF，需要把订单和预约拆成两张表，对查询来说反而增加连接成本。

最值得琢磨的是原文在规范化上留下的两处相反决策。第一处，总账关系优化时删除了净利字段，理由是净利可以由收入减支出计算得到，且不经常单独查询。第二处，财务状况关系保留了净利润字段，判定为 1NF，理由是净利润查询频繁，如果每次查询都现算，系统计算量增加、性能下降，保留冗余提高查询效率，利大于弊。

这两处对比说明规范化的真实工作方式不是“范式越高越好”，而是按查询模式做取舍。字段可计算且查询频率低，就删掉；字段可计算但查询频率高，就留下并承受冗余。后续设计文档或评审时，遇到类似取舍建议在表注释里写清楚理由，否则很容易被当成笔误。

4. 逻辑与物理结构落地：关系模式落表、存储分层与建表SQL

完成关系模式设计后进入物理设计阶段。原文把数据按访问特征分成两类：经常存取的部分放在一个磁盘，存取频率较低的部分放在另一个磁盘，备份数据和日志文件保存在磁带中。这套思路虽然产生于磁盘与磁带时代，但分层逻辑放到今天依然有效——热数据和冷数据分开存放，是所有数据库性能优化的起点。

4.1 数据访问特征分类：热数据与冷数据的分层存放

经常存取部分包括职工、工资、客房、款项、折扣规则、项目、顾客七类数据。这些是酒店日常工作流的核心：入住登记要查客房状态，退房结算要查款项和折扣规则，调薪要查工资和职工信息，娱乐消费要查项目和收费标准。它们的共同特点是更新频率高、查询并发大，放在高速存储上是合理的。

存取频率较低的部分包括部门、账单、订单、总帐、财务状况五类数据。部门是主数据，变更极少；账单、总帐、财务状况是期末汇总产物，平时只在月底结算时读写一次；订单是预订记录，相对客房状态变化来说属于低频写入。这些数据放在慢速存储上没有性能压力。

放到今天的数据库设计里，这个分类对应两种常见做法：一是 MySQL/PostgreSQL 里用不同表空间存放热表和归档表，SSD 放热数据、机械盘放冷数据；二是在应用层做冷热分离，把历史账单迁到独立的报表库。设计稿里给出的分类可以直接沿用，只需要把“磁盘”替换成“表空间”或“存储实例”。

用户子模式的设计也在这个阶段出现。原文为经理子系统建立了只包含职工号、姓名、级别、部门号、职务、部门经理、实际工资的职工视图；为住宿子系统建立了聚焦客房位置、设备、收费标准、管理人员号、状态的客房视图；为经营管理子系统建立了包含顾客编号、住宿号、级别、应收款、使用时间的顾客视图。这些用户子模式在今天的 SQL 里对应的就是视图（VIEW），本质是让不同角色只看自己关心的列，屏蔽底层表结构变化。

4.2 核心关系模式的建表SQL：修正数据类型后的落地方案

下面给出一组基于 MySQL 8 语法的建表示例，覆盖最核心的职工、部门、客房、订单、账单五个关系模式。字段命名和类型在原文基础上做了修正——原文数据字典里“证件号码”被标成整数类型，实际业务里身份证号会出现字母 X，必须用字符串存。

-- 部门表：部门号为主键，部门经理引用职工号 CREATE TABLE dept ( dept_id INT PRIMARY KEY AUTO_INCREMENT, dept_name VARCHAR(50) NOT NULL, manager_id INT, emp_count INT DEFAULT 0, finance_no INT, CONSTRAINT fk_dept_manager FOREIGN KEY (manager_id) REFERENCES emp(emp_id) ) ENGINE=InnoDB; -- 职工表：部门号外键关联部门，级别字段表达上下级关系 CREATE TABLE emp ( emp_id INT PRIMARY KEY AUTO_INCREMENT, emp_name VARCHAR(20) NOT NULL, gender ENUM('男', '女'), age INT, work_years INT DEFAULT 0, grade VARCHAR(20), dept_id INT NOT NULL, position VARCHAR(30), remark VARCHAR(100), CONSTRAINT fk_emp_dept FOREIGN KEY (dept_id) REFERENCES dept(dept_id) ) ENGINE=InnoDB; -- 客房表：类别用枚举表达，状态区分空房/入住/维修 CREATE TABLE room ( room_id VARCHAR(10) PRIMARY KEY, room_type ENUM('单人标准间', '双人标准间', '商务套房'), dept_id INT NOT NULL, location VARCHAR(50), equipment VARCHAR(100), price DECIMAL(10,2) NOT NULL, manager_id INT, status ENUM('空房', '入住', '维修') DEFAULT '空房', CONSTRAINT fk_room_dept FOREIGN KEY (dept_id) REFERENCES dept(dept_id) ) ENGINE=InnoDB CHARACTER SET utf8mb4; -- 订单表：顾客和订单1:1合并，因此顾客号直接落在订单表 CREATE TABLE booking ( booking_id INT PRIMARY KEY AUTO_INCREMENT, customer_id INT NOT NULL, manager_id INT, booking_time DATETIME, remark VARCHAR(100) ) ENGINE=InnoDB; -- 账单表：账单与总帐n:1，总帐编号作为外键 CREATE TABLE bill ( bill_id INT PRIMARY KEY AUTO_INCREMENT, total_id INT, invoice_no VARCHAR(30), summary VARCHAR(100), income DECIMAL(12,2) DEFAULT 0, expense DECIMAL(12,2) DEFAULT 0, bill_date DATETIME, handler_id INT, remark VARCHAR(100), CONSTRAINT fk_bill_total FOREIGN KEY (total_id) REFERENCES total_account(total_id) ) ENGINE=InnoDB;

表现层的实际语义需要说明几点。gender 字段用 ENUM 枚举，限定值为男、女，避免脏数据写入；room_type 用 ENUM 约束双人标准间、单人标准间等类别，与数据字典里的“枚举类型”描述保持一致；price 用 DECIMAL(10,2) 而不是 FLOAT，避免浮点计算产生 0.1+0.2 这类精度误差；booking_time 和 bill_date 用 DATETIME 类型，原文数据字典里写的“格式：/”只表达了日期精度，实际落表时建议直接给到时间点，生成报表时再用 DATE_FORMAT 截断。

外键约束按原文的 n:1 关系落：职工表带 dept_id 外键，客房表带 dept_id 外键，账单表带 total_id 外键。这里要注意“部门经理引用职工号”和“职工表引用部门号”形成循环引用，建表时要先建部门表、再建职工表、最后补部门表的经理外键，或者让部门经理字段在插入数据后再 update。

4.3 索引与级联删除：别让外键帮你做一切

原文在总经理子系统的需求里明确写了“对辞退职工从系统中级联删除其信息，如从职工表中删除其基本信息，从它所服务的工作部门中删除工作名额，结算支付工资、奖金”。放到数据库层实现时，我一般不建议直接用ON DELETE CASCADE，原因有两个。

第一，工资结算涉及财务审计，工资历史记录必须保留，不能让删除职工时连带把工资表数据也物理删除。正确做法是给职工表加“在职状态”字段（如 status ENUM('在职', '离职')），辞退操作通过状态变更实现逻辑删除，工资历史原封不动，之后再在月结时做归档。第二，删除职工还要同步减少部门职工数量、回收负责人和经手人引用，这些动作横跨多张表，用外键自动级联会带来意想不到的连带删除，应该放在应用层事务里逐项处理。

索引建议按查询模式补。住宿子系统最频繁的查询是“按房间类别统计剩余量”，room 表的 room_type 字段应建索引；财务子系统月末按部门汇总时要走 dept_id，bill 表和 total_account 表的 dept_id 需要索引；来客登记查询按身份证号码定位，customer 表如果包含证件号码字段，这个字段也要建唯一索引。

5. 避坑清单：教学设计稿里最容易被复现翻车的五个坑

原文作为一份课程设计案例，整体推导逻辑完整，但里面有几处如果照着原样搬到真实系统或毕业设计答辩里，很容易被追问或翻车。以下五条按“现象-原因-解决”整理。

5.1 证件号码被声明成整数类型

现象：数据字典里“证件号码 整数类型 唯一性”被照抄进建表 SQL，导致身份证号无法入库。原因：设计文档把证件号码理解成了纯数字，忽略了身份证号包含 X、港澳台证件含字母的实际情况。解决：改为 VARCHAR(18) 并加 CHECK 约束做格式校验，同时建立唯一索引确保一人一证。从那次以后，我每次看到设计文档里号码类字段标整数，都会先去核实业务样本数据里有没有字母。

5.2 饮食部门被整体并进财务子系统，后续无法扩展成本分析

现象：系统上线后发现要做菜品销售统计、原料库存核算，但库里根本没有菜品表和消费明细。原因：需求分析时只把“财务登记”当成饮食部门唯一需要入库的信息，砍掉了过程数据。解决：这类简化必须在文档里显式记录业务边界。如果预期会有餐饮成本分析或促销活动，即便不做完整餐饮子系统，也应保留一张最简消费流水表，把每日销售收入明细落到能按菜品口径汇总的程度。

5.3 顾客“级别”字段试图包揽所有折扣规则

现象：折扣规则变化时，比如引入协议价、季节折扣、会员积分，需要在顾客表里加一堆新字段，或者频繁修改级别取值。原因：原文用一个“级别”属性对应所有折扣场景，属于用编码代替业务规则。解决：保留款项表里的折扣级别字段做快照，同时在折扣规则表里补充折扣类型、生效时间、适用条件等扩展列。设计文档里单用顾客级别表达多维度定价的做法，只适合演示“1:1 联系转关系合并”的教学场景。

5.4 水平分解职工表后产生职责漂移

现象：原文把职工关系按职能水平分解为负责人员、服务人员、经手人员三张表。实际业务里同一个职工可能既是服务人员又是经手人，同一职工要往三张表里各插一份数据，更新时还要保证三份一致。原因：水平分解按“角色”切分数据，没有考虑一个职工身兼多职的情况。解决：基础数据保留统一职工表，按角色需求建立视图或其他关联表，而不是物理拆表。原文的水平分解思路用于查询优化是可以的，但在当前 CPU 和数据库能力下，直接建视图更合适。

5.5 辞退职工走物理级联删除，工资审计数据被连带清掉

现象：执行删除职工操作后，该职工的工资历史、历史账单关联信息全部消失，月末审计时查无对证。原因：需求原文写的是“级联删除其信息”，这个表述在业务上站不住脚，财务数据必须保留。解决：职工表增加在职状态字段，辞退操作改为状态流转加历史归档，账单、工资、负责人引用全部保留。数据库层的物理删除只允许出现在测试库和确定需要彻底抹除的数据上。

排查这些坑有一个统一路子：拿到设计文档先看数据字典，凡是类型标注可疑的字段全部列出来和业务人员核对；再看删除类需求，所有删除都要问一句“这个记录以后要不要查”；最后看范式权衡点，凡是出现冗余保留的地方，要求文档在表注释里写清楚理由。

6. 用SQL把设计稿验一遍：视图、统计查询与级联设计

这套设计最终能不能用，最直接的验证方式是写几段目标查询，看表结构是否撑得住。这里挑三个具有代表性的查询，对应原文用户子模式设计和月末汇总需求。

用视图封装用户子模式，让经理子系统、住宿子系统、经营管理子系统各自只接触关心的列：

-- 经理子系统用户视图：只暴露常用管理字段 CREATE VIEW mgr_emp_view AS SELECT e.emp_id, e.emp_name, e.grade, e.dept_id, e.position, d.manager_id, w.actual_salary FROM emp e JOIN dept d ON e.dept_id = d.dept_id JOIN salary w ON e.emp_id = w.emp_id; -- 住宿子系统用户视图：聚焦客房运营字段，隐藏财务字段 CREATE VIEW stay_room_view AS SELECT room_id, room_type, location, equipment, price, manager_id, status FROM room;

统计各房间类别的空房数量和入住率，对应原文住宿管理“统计各类房间的客满程度”的需求：

SELECT room_type, COUNT(*) AS total_rooms, SUM(CASE WHEN status = '空房' THEN 1 ELSE 0 END) AS available_rooms, SUM(CASE WHEN status = '入住' THEN 1 ELSE 0 END) / COUNT(*) AS occupancy_rate FROM room GROUP BY room_type;

月末财务汇总，按部门统计收入、支出、净收入，来自原文财务子系统的第三个功能“期末各部门财务报表”：

SELECT d.dept_id, d.dept_name, SUM(b.income) AS total_income, SUM(b.expense) AS total_expense, SUM(b.income - b.expense) AS net_income FROM dept d JOIN bill b ON d.dept_id = b.dept_id WHERE b.bill_date BETWEEN '2024-01-01' AND '2024-01-31' GROUP BY d.dept_id, d.dept_name;

三个查询跑通，说明这套关系模式设计基本撑得起核心业务。入住率查询依赖 room 表的 room_type 分组和 status 过滤，索引该建的建上就行。财务汇总查询把 bill 表按月份过滤后分组，如果数据量到百万级，建议给 bill_date 建索引，或者直接按月做分区表。

实际验证时还会发现一个原文没展开的问题：住宿子系统里“来客登记”要同时更新 customer、住宿联系表、room 表状态三个地方。原文把它标记为“满足顾客要求”数据流，但没有给出事务处理逻辑。设计文档在这类多表一致性场景下留了空白，落实现场必然要用事务包裹。

START TRANSACTION; INSERT INTO customer (customer_id, room_id, contact_name, id_type, id_no, check_in_time) VALUES (10001, 'R201', '张伟', '身份证', '110101199001011234', NOW()); INSERT INTO stay (customer_id, room_id, stay_time) VALUES (10001, 'R201', 7); UPDATE room SET status = '入住' WHERE room_id = 'R201'; COMMIT;

这段事务示例对应原文住宿子系统的来客登记和房间管理联动，三个动作要么全成功要么全回滚。从那以后我每次拿到这类设计文档，都会把所有“登记”“修改”“结算”类动作过一遍，看有没有用事务把多表写入包起来——设计稿画 E-R 图往往很漂亮，但一致性边界才是真正落地时最需要补的功课。最理想的验证方式，是先把文档里的每张数据表建出来，然后用一套模拟数据把入住、退房、月度结算整个流程走一遍，跑出来的数字和手工核算对得上，这份设计才算真正可交付。希望帮到你。

本文还有配套的精品资源，点击获取