简介这份中文版 Design Compiler 学习资料面向 IC 前端设计初学者与需要系统梳理综合流程的工程师围绕 Synopsys 综合工具 DC 的使用展开帮助读者理解从 HDL 行为描述到门级网表的完整转换过程。内容涵盖综合的转换、优化与映射三阶段原理综合在集成电路设计流程中的承上启下地位以及基于路径的优化特点同时讲解综合脚本的可重用与参数化要求时钟定义、线负载模型、输入输出延迟、多周期路径与非法路径等约束设置并给出综合结果需满足的时序与工艺库映射标准。资源包共 1 个 doc 文档约 954KB以章节化讲义形式组织配有 Verilog 语句到门级映射的实例说明便于对照阅读与查阅。目前已有 465 人学习适合作为 DC 入门与综合约束实践的参考材料。1. 一份能照着跑通的中文 DC 综合笔记到底解决了什么翻到一份讲 Design Compiler 的中文资料第一反应往往是又是把官方手册翻译一遍。但这份不太一样——它从“综合到底在干什么”讲起把转换、优化、映射三个阶段拆开再落到 Verilog 语句怎么变成门、dc_shell 怎么起、库怎么设、脚本怎么写。对刚接触综合的人来说最缺的不是命令列表而是“为什么这条命令要放在这一步”的因果链。这份资料的价值就在这条链上它把综合当成约束驱动的过程来讲而不是当成一堆 set_xxx 的堆砌。适合谁写过 RTL、跑过仿真、但第一次要把代码变成门级网表的人也适合已经会用 DC 但脚本写得随缘、想回头补原理的熟手。下面按“原理立住 → 动手复现 → 踩坑排查 → 进阶验证”的顺序拆。2. 综合三阶段与 Verilog 到门的映射先看懂电路再敲命令2.1 转换、优化、映射各自在做什么综合不是一步到位的黑匣子。DC 拿到 HDL 之后先做转换用 gtech.db 里的通用门级单元把行为描述搭成一个初始的、未优化的电路。这个阶段的电路逻辑上等价于你的 RTL但没有工艺信息没有延迟没有驱动能力纯粹是“能跑通逻辑”的骨架。接着是优化与映射DC 调用内建的静态时序分析能力对有效路径逐条分析删冗余单元、重构不满足约束的路径最后把优化后的电路映射到 target_library 指定的工艺库上这时网表才带上真实的单元延迟、引脚电容、驱动能力。理解这个顺序很关键因为它决定了你排错的方向。如果 link 之后报 unresolved design reference问题在转换之前的读文件和库路径如果 compile 之后时序违反问题在约束和工艺库不在 RTL 语法。很多人一上来就改代码其实八成是约束没给对。提示gtech.db 只用于转换阶段的逻辑搭建它不含延迟和驱动信息别拿它当工艺库用。2.2 If、Case、Always 综合出来长什么样资料里用大量例子把 Verilog 语句和门电路对应起来这部分是整份笔记最值得反复看的地方。If 语句隐含优先级综合出来是带优先级的選擇器链Case 语句在完全译码时是平行结构条件不全时同样会退化成优先级结构。最典型的坑是 If 没写全分支条件未覆盖时工具为了保持行为一致会插入锁存器来“记住”上一次的值。// 条件不完全译码综合后会引入 Latch always (num or xval or yval or zval) begin if (num 2b00) dec xval; else if (num 2b01) dec yval; else if (num 2b10) dec zval; // num 2b11 没有处理工具插入 Latch end这段代码的逻辑说明很直白num 取 11 时没有任何赋值分支组合逻辑无法给出确定输出工具只能推断出存储元件。参数上没什么可调的改法就两条——要么在判断前给输出一个缺省赋值要么补全 else 分支。锁存器和触发器混在同一电路里会显著增加测试难度这是资料反复强调的红线。Case 那边有个更隐蔽的点//synopsys parallel_case和//synopsys full_case这类编译指导只被综合工具识别仿真器不认。也就是说加了指导之后综合出来的电路可能和你仿真的模型不一致。资料里明确提醒“使用编译指导时必须谨慎”这句话的分量比它看起来重——综合和仿真不一致是后期最难查的一类问题。2.3 算术与移位运算符的映射边界加法、比较、移位这些运算符由 DesignWare 负责实现。4 位无符号加法综合出来就是不带进位的 4 位加法器比较综合成无符号数比较取大的电路。移位要分两种情况移位位数是常量时综合只是重新连线比如右移 2 位就是把输入高 2 位接到输出低位、高位补零几乎不耗资源移位位数是变量时工具生成通用移位器面积和延迟都上来了。// 常量移位纯连线无额外逻辑 assign Addr_after_shift Addr 2; // 变量移位生成通用移位器资源开销明显 assign Addr_after_shift Addr shift_var;参数说明前者移位量固定综合器在 elaboration 阶段就能确定连线关系后者移位量来自端口必须用多路选择结构实现。如果你的设计里出现变量移位且时序紧张常见做法是改成桶形移位器的显式写法或者评估是否真需要任意位移动。DesignWare 还分 Basic 和 Foundation 两档Foundation 提供性能更高的结构但需要在 synthetic_library 里额外设置并在 link_library 里加上对应库否则链接阶段找不到实现。3. 从启动 dc_shell 到 compile一套能复现的综合流程3.1 三种启动方式与初始化文件加载顺序DC 有三种跑法dc_shell 是传统文本界面dc_shell-t 是基于 TCL 的文本界面design_analyzer 是图形界面。现在基本都用 dc_shell-t因为 TCL 脚本可控性强、可参数化。图形界面适合看电路图但它只能显示 HDL 描述对应的电路不是用来编辑原理图的这点资料里专门点了。# 进入工程目录后启动 TCL 模式 cd ~/DC_example/risc_design dc_shell-t # 或者直接跑脚本适合批处理 dc_shell-t -f run.tcl启动时 DC 会按固定顺序搜索.synopsys_dc.setup安装目录下的标准初始化文件、用户 HOME 目录、当前启动目录后面的覆盖前面的。这个顺序决定了库路径和别名的最终取值。文件是 Unix 隐藏文件ls看不到得用ls -a。我一般把库设置放在工程目录的 setup 里HOME 目录只放个人习惯的别名避免换项目时互相污染。3.2 四个库的分工link、target、symbol、synthetic库设错是新手翻车率最高的环节。四个库各管一摊库作用典型设置link_library解析模块和单元引用必须含*{* core_slow.db}target_library综合映射的目标工艺库含延迟信息core_slow.dbsymbol_library图形界面显示电路符号用core_slow.sdbsynthetic_libraryDesignWare 扩展实现standard.sldb及扩展库link_library 里的*不是通配符随便写的它表示“先搜 DC 内存里已加载的模块”。少了这个星号DC 不会复用内存中已有的设计直接报 unresolved design reference。这个坑我见过不止一次报错信息看起来像模块没读进来实际是库设置漏了星号。# .synopsys_dc.setup 中的典型库设置 set search_path [list . ./lib /path/to/techlib] set link_library [list * core_slow.db] set target_library core_slow.db set symbol_library core_slow.sdb set synthetic_library standard.sldb参数说明search_path 决定 DC 去哪找库文件和源文件link_library 用 list 形式且首位放*target_library 只放工艺库别把 gtech.db 塞进去。设置完可以用echo $target_library之类的命令确认实际生效值别假设文件写了就一定加载成功。3.3 读设计、link、约束、compile 的完整脚本骨架流程本身不复杂读文件 → link → 定义环境 → 施加约束 → check_design → compile → 出报告。难的是每一步的约束给得对不对。下面是一个可复用的骨架参数抽成变量方便模块位宽变化时只改参数不动结构。# 读入设计并链接 read_db unmapped/RISC_CORE.db link # 工作环境 set_operating_conditions -library core_slow slow set_wire_load_model -name tsmc18_wl10 -library core_slow set_driving_cell -lib_cell BUFX2 -pin Z [all_inputs] set_load 0.05 [all_outputs] # 时钟与 IO 约束 create_clock -period 10 -name clk [get_ports clk] set_clock_uncertainty 0.5 [get_clocks clk] set_input_delay 2 -clock clk [remove_from_collection [all_inputs] [get_ports clk]] set_output_delay 2 -clock clk [all_outputs] # 设计规则与优化目标 set_max_area 0 set_max_fanout 8 [current_design] set_max_transition 0.6 [current_design] # 检查并综合 check_design reports/check_design.rpt compile -map_effort medium report_timing reports/timing.rpt report_area reports/area.rpt report_constraint -all_violators reports/violators.rpt逻辑说明link必须在约束之前否则约束施加不到实际电路上create_clock是同步设计的根约束没有时钟定义后续所有时序分析都失去基准set_input_delay/set_output_delay描述模块边界外的延迟别和内部路径延迟混淆compile -map_effort控制优化力度medium 是常规起点时序紧再往上调。参数上时钟周期直接决定时序目标uncertainty 留的是时钟抖动和偏差的余量一般取周期的 5% 到 10%具体看工艺和时钟树预期。约束施加时还有个对象歧义问题set_load 3 Clk这种写法如果电路里同时存在叫 Clk 的 port、pin 和 netDC 不知道你指哪个。规范写法是显式指定对象类型比如set_load 3 [get_nets Clk]。这类模糊对象在复杂设计里会静默作用到错误目标上报告里看不出异常但结果就是不对。4. 综合脚本与结果里的坑五条踩出来的排查记录4.1 现象link 报 unresolved design reference原因link_library 没包含*或者 search_path 没指向子模块所在目录DC 在内存和库里都找不到被实例化的模块。解决先确认read_db/read_verilog是否真的读进来了再检查 link_library 首位有没有星号最后核对 search_path。三步按顺序查别一上来就重读文件。4.2 现象综合后电路里冒出锁存器原因If 或 Case 分支没覆盖全部条件组合逻辑输出在某些输入下无定义工具推断出 Latch。解决在 always 块开头给所有输出赋缺省值或补全 else/default 分支。改完重新 elaborate用check_design确认没有 latch 警告再 compile。4.3 现象仿真通过综合后功能不对原因用了//synopsys full_case或parallel_case编译指导综合器按指导裁剪了逻辑仿真器却按完整语义执行两边模型分叉。解决优先改 RTL 让分支天然完整少依赖编译指导确实要用必须在综合后做门级仿真比对。这类问题血泪经验最多因为波形上看不出错只有比对才发现。4.4 现象时序报告全是违反但 RTL 看起来没问题原因约束本身错了——时钟没定义、input/output delay 给得离谱、或者 operating condition 选错。解决先看report_clock确认时钟存在且周期正确再看report_constraint -all_violators区分是设计规则违反还是时序违反。设计规则违反max_transition、max_fanout优先修它们会连带影响时序。4.5 现象compile 跑很久面积暴涨原因-map_effort开太高、DesignWare Foundation 库没设导致工具用基本结构硬凑高性能路径或者约束过紧逼工具堆逻辑。解决先回到 medium 力度看基线结果确认 synthetic_library 和 link_library 里扩展库都设了再逐步收紧约束。面积和时序是折中关系路径延迟压到一定程度后面积代价换不来明显时序收益这时候该回头改微架构而不是继续压工具。5. 用报告反推约束一套可复用的验证习惯综合跑完不等于结束报告才是判断约束是否合理的依据。我习惯按固定顺序读三份报告先report_clock和report_port -verbose确认时钟与 IO 约束真的生效了再看report_constraint -all_violators分清设计规则违反和时序违反最后用report_timing -max_paths 20 -nworst 5看关键路径落在哪一层逻辑上。顺序不能反——约束没生效时看时序报告看到的全是假象。验证约束是否“过紧”有个简单办法把时钟周期放宽 20% 再 compile 一次如果面积和时序大幅改善说明原约束已经逼近工具的能力边界该考虑改结构而不是继续压。反过来如果放宽后结果几乎不变说明瓶颈不在时序而在设计规则或库选择上。# 对比两次综合的关键指标 report_area reports/area_run1.rpt report_timing -max_paths 10 reports/timing_run1.rpt # 放宽周期后重跑比较面积与 slack 变化 create_clock -period 12 -name clk [get_ports clk] compile -map_effort medium report_area reports/area_run2.rpt这套对比我一般在新模块第一次综合时必做成本很低但能快速判断约束是“合理偏紧”还是“离谱”。从那以后我每次拿到一份新的综合脚本都强制先跑一遍约束生效性检查再谈优化——库设对、时钟在、对象不歧义这三件事确认完后面八成的怪问题根本不会出现。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 6:12:41 · 阅读 1.2k Design Compiler综合实战：从原理到脚本的完整指南
简介这份中文版 Design Compiler 学习资料面向 IC 前端设计初学者与需要系统梳理综合流程的工程师围绕 Synopsys 综合工具 DC 的使用展开帮助读者理解从 HDL 行为描述到门级网表的完整转换过程。内容涵盖综合的转换、优化与映射三阶段原理综合在集成电路设计流程中的承上启下地位以及基于路径的优化特点同时讲解综合脚本的可重用与参数化要求时钟定义、线负载模型、输入输出延迟、多周期路径与非法路径等约束设置并给出综合结果需满足的时序与工艺库映射标准。资源包共 1 个 doc 文档约 954KB以章节化讲义形式组织配有 Verilog 语句到门级映射的实例说明便于对照阅读与查阅。目前已有 465 人学习适合作为 DC 入门与综合约束实践的参考材料。1. 一份能照着跑通的中文 DC 综合笔记到底解决了什么翻到一份讲 Design Compiler 的中文资料第一反应往往是又是把官方手册翻译一遍。但这份不太一样——它从“综合到底在干什么”讲起把转换、优化、映射三个阶段拆开再落到 Verilog 语句怎么变成门、dc_shell 怎么起、库怎么设、脚本怎么写。对刚接触综合的人来说最缺的不是命令列表而是“为什么这条命令要放在这一步”的因果链。这份资料的价值就在这条链上它把综合当成约束驱动的过程来讲而不是当成一堆 set_xxx 的堆砌。适合谁写过 RTL、跑过仿真、但第一次要把代码变成门级网表的人也适合已经会用 DC 但脚本写得随缘、想回头补原理的熟手。下面按“原理立住 → 动手复现 → 踩坑排查 → 进阶验证”的顺序拆。2. 综合三阶段与 Verilog 到门的映射先看懂电路再敲命令2.1 转换、优化、映射各自在做什么综合不是一步到位的黑匣子。DC 拿到 HDL 之后先做转换用 gtech.db 里的通用门级单元把行为描述搭成一个初始的、未优化的电路。这个阶段的电路逻辑上等价于你的 RTL但没有工艺信息没有延迟没有驱动能力纯粹是“能跑通逻辑”的骨架。接着是优化与映射DC 调用内建的静态时序分析能力对有效路径逐条分析删冗余单元、重构不满足约束的路径最后把优化后的电路映射到 target_library 指定的工艺库上这时网表才带上真实的单元延迟、引脚电容、驱动能力。理解这个顺序很关键因为它决定了你排错的方向。如果 link 之后报 unresolved design reference问题在转换之前的读文件和库路径如果 compile 之后时序违反问题在约束和工艺库不在 RTL 语法。很多人一上来就改代码其实八成是约束没给对。提示gtech.db 只用于转换阶段的逻辑搭建它不含延迟和驱动信息别拿它当工艺库用。2.2 If、Case、Always 综合出来长什么样资料里用大量例子把 Verilog 语句和门电路对应起来这部分是整份笔记最值得反复看的地方。If 语句隐含优先级综合出来是带优先级的選擇器链Case 语句在完全译码时是平行结构条件不全时同样会退化成优先级结构。最典型的坑是 If 没写全分支条件未覆盖时工具为了保持行为一致会插入锁存器来“记住”上一次的值。// 条件不完全译码综合后会引入 Latch always (num or xval or yval or zval) begin if (num 2b00) dec xval; else if (num 2b01) dec yval; else if (num 2b10) dec zval; // num 2b11 没有处理工具插入 Latch end这段代码的逻辑说明很直白num 取 11 时没有任何赋值分支组合逻辑无法给出确定输出工具只能推断出存储元件。参数上没什么可调的改法就两条——要么在判断前给输出一个缺省赋值要么补全 else 分支。锁存器和触发器混在同一电路里会显著增加测试难度这是资料反复强调的红线。Case 那边有个更隐蔽的点//synopsys parallel_case和//synopsys full_case这类编译指导只被综合工具识别仿真器不认。也就是说加了指导之后综合出来的电路可能和你仿真的模型不一致。资料里明确提醒“使用编译指导时必须谨慎”这句话的分量比它看起来重——综合和仿真不一致是后期最难查的一类问题。2.3 算术与移位运算符的映射边界加法、比较、移位这些运算符由 DesignWare 负责实现。4 位无符号加法综合出来就是不带进位的 4 位加法器比较综合成无符号数比较取大的电路。移位要分两种情况移位位数是常量时综合只是重新连线比如右移 2 位就是把输入高 2 位接到输出低位、高位补零几乎不耗资源移位位数是变量时工具生成通用移位器面积和延迟都上来了。// 常量移位纯连线无额外逻辑 assign Addr_after_shift Addr 2; // 变量移位生成通用移位器资源开销明显 assign Addr_after_shift Addr shift_var;参数说明前者移位量固定综合器在 elaboration 阶段就能确定连线关系后者移位量来自端口必须用多路选择结构实现。如果你的设计里出现变量移位且时序紧张常见做法是改成桶形移位器的显式写法或者评估是否真需要任意位移动。DesignWare 还分 Basic 和 Foundation 两档Foundation 提供性能更高的结构但需要在 synthetic_library 里额外设置并在 link_library 里加上对应库否则链接阶段找不到实现。3. 从启动 dc_shell 到 compile一套能复现的综合流程3.1 三种启动方式与初始化文件加载顺序DC 有三种跑法dc_shell 是传统文本界面dc_shell-t 是基于 TCL 的文本界面design_analyzer 是图形界面。现在基本都用 dc_shell-t因为 TCL 脚本可控性强、可参数化。图形界面适合看电路图但它只能显示 HDL 描述对应的电路不是用来编辑原理图的这点资料里专门点了。# 进入工程目录后启动 TCL 模式 cd ~/DC_example/risc_design dc_shell-t # 或者直接跑脚本适合批处理 dc_shell-t -f run.tcl启动时 DC 会按固定顺序搜索.synopsys_dc.setup安装目录下的标准初始化文件、用户 HOME 目录、当前启动目录后面的覆盖前面的。这个顺序决定了库路径和别名的最终取值。文件是 Unix 隐藏文件ls看不到得用ls -a。我一般把库设置放在工程目录的 setup 里HOME 目录只放个人习惯的别名避免换项目时互相污染。3.2 四个库的分工link、target、symbol、synthetic库设错是新手翻车率最高的环节。四个库各管一摊库作用典型设置link_library解析模块和单元引用必须含*{* core_slow.db}target_library综合映射的目标工艺库含延迟信息core_slow.dbsymbol_library图形界面显示电路符号用core_slow.sdbsynthetic_libraryDesignWare 扩展实现standard.sldb及扩展库link_library 里的*不是通配符随便写的它表示“先搜 DC 内存里已加载的模块”。少了这个星号DC 不会复用内存中已有的设计直接报 unresolved design reference。这个坑我见过不止一次报错信息看起来像模块没读进来实际是库设置漏了星号。# .synopsys_dc.setup 中的典型库设置 set search_path [list . ./lib /path/to/techlib] set link_library [list * core_slow.db] set target_library core_slow.db set symbol_library core_slow.sdb set synthetic_library standard.sldb参数说明search_path 决定 DC 去哪找库文件和源文件link_library 用 list 形式且首位放*target_library 只放工艺库别把 gtech.db 塞进去。设置完可以用echo $target_library之类的命令确认实际生效值别假设文件写了就一定加载成功。3.3 读设计、link、约束、compile 的完整脚本骨架流程本身不复杂读文件 → link → 定义环境 → 施加约束 → check_design → compile → 出报告。难的是每一步的约束给得对不对。下面是一个可复用的骨架参数抽成变量方便模块位宽变化时只改参数不动结构。# 读入设计并链接 read_db unmapped/RISC_CORE.db link # 工作环境 set_operating_conditions -library core_slow slow set_wire_load_model -name tsmc18_wl10 -library core_slow set_driving_cell -lib_cell BUFX2 -pin Z [all_inputs] set_load 0.05 [all_outputs] # 时钟与 IO 约束 create_clock -period 10 -name clk [get_ports clk] set_clock_uncertainty 0.5 [get_clocks clk] set_input_delay 2 -clock clk [remove_from_collection [all_inputs] [get_ports clk]] set_output_delay 2 -clock clk [all_outputs] # 设计规则与优化目标 set_max_area 0 set_max_fanout 8 [current_design] set_max_transition 0.6 [current_design] # 检查并综合 check_design reports/check_design.rpt compile -map_effort medium report_timing reports/timing.rpt report_area reports/area.rpt report_constraint -all_violators reports/violators.rpt逻辑说明link必须在约束之前否则约束施加不到实际电路上create_clock是同步设计的根约束没有时钟定义后续所有时序分析都失去基准set_input_delay/set_output_delay描述模块边界外的延迟别和内部路径延迟混淆compile -map_effort控制优化力度medium 是常规起点时序紧再往上调。参数上时钟周期直接决定时序目标uncertainty 留的是时钟抖动和偏差的余量一般取周期的 5% 到 10%具体看工艺和时钟树预期。约束施加时还有个对象歧义问题set_load 3 Clk这种写法如果电路里同时存在叫 Clk 的 port、pin 和 netDC 不知道你指哪个。规范写法是显式指定对象类型比如set_load 3 [get_nets Clk]。这类模糊对象在复杂设计里会静默作用到错误目标上报告里看不出异常但结果就是不对。4. 综合脚本与结果里的坑五条踩出来的排查记录4.1 现象link 报 unresolved design reference原因link_library 没包含*或者 search_path 没指向子模块所在目录DC 在内存和库里都找不到被实例化的模块。解决先确认read_db/read_verilog是否真的读进来了再检查 link_library 首位有没有星号最后核对 search_path。三步按顺序查别一上来就重读文件。4.2 现象综合后电路里冒出锁存器原因If 或 Case 分支没覆盖全部条件组合逻辑输出在某些输入下无定义工具推断出 Latch。解决在 always 块开头给所有输出赋缺省值或补全 else/default 分支。改完重新 elaborate用check_design确认没有 latch 警告再 compile。4.3 现象仿真通过综合后功能不对原因用了//synopsys full_case或parallel_case编译指导综合器按指导裁剪了逻辑仿真器却按完整语义执行两边模型分叉。解决优先改 RTL 让分支天然完整少依赖编译指导确实要用必须在综合后做门级仿真比对。这类问题血泪经验最多因为波形上看不出错只有比对才发现。4.4 现象时序报告全是违反但 RTL 看起来没问题原因约束本身错了——时钟没定义、input/output delay 给得离谱、或者 operating condition 选错。解决先看report_clock确认时钟存在且周期正确再看report_constraint -all_violators区分是设计规则违反还是时序违反。设计规则违反max_transition、max_fanout优先修它们会连带影响时序。4.5 现象compile 跑很久面积暴涨原因-map_effort开太高、DesignWare Foundation 库没设导致工具用基本结构硬凑高性能路径或者约束过紧逼工具堆逻辑。解决先回到 medium 力度看基线结果确认 synthetic_library 和 link_library 里扩展库都设了再逐步收紧约束。面积和时序是折中关系路径延迟压到一定程度后面积代价换不来明显时序收益这时候该回头改微架构而不是继续压工具。5. 用报告反推约束一套可复用的验证习惯综合跑完不等于结束报告才是判断约束是否合理的依据。我习惯按固定顺序读三份报告先report_clock和report_port -verbose确认时钟与 IO 约束真的生效了再看report_constraint -all_violators分清设计规则违反和时序违反最后用report_timing -max_paths 20 -nworst 5看关键路径落在哪一层逻辑上。顺序不能反——约束没生效时看时序报告看到的全是假象。验证约束是否“过紧”有个简单办法把时钟周期放宽 20% 再 compile 一次如果面积和时序大幅改善说明原约束已经逼近工具的能力边界该考虑改结构而不是继续压。反过来如果放宽后结果几乎不变说明瓶颈不在时序而在设计规则或库选择上。# 对比两次综合的关键指标 report_area reports/area_run1.rpt report_timing -max_paths 10 reports/timing_run1.rpt # 放宽周期后重跑比较面积与 slack 变化 create_clock -period 12 -name clk [get_ports clk] compile -map_effort medium report_area reports/area_run2.rpt这套对比我一般在新模块第一次综合时必做成本很低但能快速判断约束是“合理偏紧”还是“离谱”。从那以后我每次拿到一份新的综合脚本都强制先跑一遍约束生效性检查再谈优化——库设对、时钟在、对象不歧义这三件事确认完后面八成的怪问题根本不会出现。希望帮到你。本文还有配套的精品资源点击获取