简介：《Sql Server数据库系统加固规范》是一份面向数据库管理员、安全运维与合规检查人员的安全基线文档，主要用于指导 SQL Server 实例在账号、认证、日志、通信及主机层面的加固落地。压缩包内含 1 个 doc 文件，大小约 1.73MB，以 Word 文档形式集中呈现规范条目，便于查阅、打印和内部制度引用。文档按账号管理与认证授权、日志配置、通信协议、设备其他安全要求等模块编排，每条要求均给出编号、实施目的、问题影响、系统当前状态、参考配置步骤、回退方案、判断依据、实施风险与重要等级，兼具检查表与操作手册的双重用途。已有 245 人学习，适合需要开展 SQL Server 安全自查、等保整改或编写加固方案的读者参考，也可作为日常运维中的核对清单。

1. 从一张审计整改单说起：SQL Server 数据库系统加固规范要解决什么

某公司内部审计给一台生产库开了一张不合格单，上面只写了四行：存在共享账号、sa 口令长期未改、xp_cmdshell 未禁用、多余网络协议没关。运维拿到单子后第一反应不是改，而是不敢改——这台机器上还跑着三套业务，改错一条半夜就得回滚。SQL Server 数据库系统加固规范要解决的正是这个卡点：它把账号管理、认证授权、日志配置、通信协议、设备其他安全要求五个方向拆成 11 条带编号的基线动作，每条都写清实施目的、当前状态怎么查、步骤怎么敲、回退怎么做、风险多高。做毕设或课设的同学可以照着交一份有编号、有证据、有回退的加固方案；要出交付文档的从业者，也能把它当模板直接改成本单位版本。

2. 基线清单怎么拆：11 条编号背后的四个域与核查顺序

规范原文最容易被人跳过的是编号规则，大家往往直接翻到具体条目就开始改配置。编号其实是整份文档的骨架，理解了它，你才知道自己漏了哪一块、哪一条风险最高、哪些条目可以合并成一次停机窗口做完。

2.1 编号规则拆解：SHG-Mssql-01-01-01 每一段在说什么

把SHG-Mssql-01-01-01从左往右拆开看，第一段是规范自身的代号前缀，用来区分不同设备类型的加固规范；第二段Mssql标明适用对象；第三段是安全域大类，01 对应账号管理与认证授权，02 对应日志配置，03 对应通信协议，04 对应设备其他安全要求；第四段是子域，第五段才是具体条目序号。这个五段式的好处是条目可以持续追加而不打乱已有编号——后期补一条新要求，直接在对应大类后面加序号就行，前面已经验收过的编号不用动。

四个安全域的条目分布并不均匀，账号域占了 6 条，是绝对重心；日志域只有 1 条；协议域 3 条；设备域 2 条。这个分布本身就说明了加固工作的优先级判断：账号和权限是绝大多数入侵路径的入口，值得用一半以上的条目去覆盖。

表格里那列「风险等级」是很多人忽略的信息。11 条里有 9 条标注实施风险为「高」，意味着这些动作一旦做错会直接影响业务可用性，不是改完重启就完事。真正低风险的只有日志那一条。做方案时把这列单独拎出来看，你就能排出「哪些必须先做停机窗口、哪些可以随时改」。

2.2 每条基线必须填满的十个字段

规范给出的每条目模板是固定的：编号、名称、实施目的、问题影响、系统当前状态、实施步骤、回退方案、判断依据、实施风险、重要等级。这个模板看着像八股，但每一项都在回答验收时会被追问的问题——目的是什么、不改会怎样、改之前系统长什么样、怎么改、改坏了怎么退、怎么证明改成功了、风险多大、值不值得优先做。

十个字段里最值钱的是「回退方案」。我见过太多加固文档把这一栏写成「恢复原状」四个字，等于没写。合格的回退方案应该具体到可直接执行：删掉哪个账号、还原哪个注册表键值、从哪份备份恢复、恢复后需要重启哪个服务。判断依据同样不能糊弄，「查看是否生效」不算判断依据，「执行某条查询，返回 0 行即为通过」才算。

提示：模板里的「系统当前状态」不是让你写「正常」，而是让你把改之前的事实记录下来。这一栏是后面验收对比的基准，也是出问题时判断是不是加固导致的唯一依据。

2.3 核查顺序：为什么必须先只读采集再动手

11 条基线的执行顺序不能按编号从头到尾走。正确的顺序是先做全量只读采集，再按「补丁版本 → 协议 → 账号 → 权限 → 日志 → 存储过程」推进。原因是版本决定了后面所有命令的语法：老版本用sp_addlogin建登录名，较新版本用CREATE LOGIN；老版本用sp_dropextendedproc删扩展存储过程，新版本里很多过程本身已经不存在，删除语句会直接报错中断脚本。

采集阶段一条改配置的语句都不要写，全部用查询完成：

-- 1. 版本与补丁号：结果第三段数字对应补丁级别，先记下来 SELECT @@VERSION AS 版本信息; EXEC xp_msver; -- 平台、处理器、物理内存等明细 -- 2. 登录名清单：password 为 NULL 说明是空口令账号 USE master; SELECT name AS 登录名, CASE WHEN password IS NULL THEN '空口令' ELSE '已设置' END AS 口令状态 FROM syslogins ORDER BY name; -- 3. 服务器角色成员：看谁被塞进了 sysadmin EXEC sp_helpsrvrolemember 'sysadmin';

第一段查询输出的是版本字符串，末段数字就是补丁号，后面核对 SP 级别时直接用。第二段沿用规范原文的syslogins查询，password列返回的是口令哈希，为NULL就代表这个账号没有设置口令，这是最危险的一类账号。第三段查sysadmin固定服务器角色的成员，业务账号出现在这个列表里基本就是权限失控。

数据库内的用户和角色关系要逐个库查，不能只看 master：

-- 在业务库中执行，导出「用户 → 角色」映射 SELECT DB_NAME() AS 库名, dp.name AS 数据库用户, r.name AS 所属角色 FROM sys.database_role_members rm JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id JOIN sys.database_principals dp ON rm.member_principal_id = dp.principal_id ORDER BY r.name, dp.name;

这段查的是数据库级角色成员关系，db_owner、db_datareader、db_datawriter这些角色的实际持有人会全部列出来。判断标准很直接：业务连接账号只应该出现在db_datareader和db_datawriter里，出现db_owner就要在权限最小化那一条里处理掉。

2.4 动手之前先做一份回退包

所有标注风险「高」的条目，执行前都要留一份可还原的快照。数据库层面备份 master 库，账号和角色层面导出清单，注册表层面导出键值：

# 建一个基线目录，把所有回退材料集中存放 New-Item -ItemType Directory -Force -Path D:\baseline | Out-Null # 1. 导出 TCP/IP 参数键值，改之前先存一份 reg export "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" ` D:\baseline\tcpip_before.reg /y # 2. 记录所有登录名及其状态，出问题时照着这份清单反推 # （SQL 部分用前面的 syslogins 查询导出成 CSV）

reg export的第二个参数是导出文件路径，/y表示覆盖同名文件不提示。导出的.reg文件双击即可回滚，这是注册表类加固最省事的后悔药。账号清单建议同时留一份明文 CSV，因为一旦误删了sysadmin成员，你可能连查清单的权限都没有了，只能靠文件对照。

3. 账号管理与认证授权：六条基线的落地写法

账号域这 6 条是整份规范的重头戏，也是实操中最容易做一半的地方。很多人做到「删除无效账号」就停了，权限最小化和角色管理这两条往往空着，结果审计复核时照样扣分。这六条实际上是递进关系：先保证人人有独立账号，再清掉没人用的账号，然后压低启动账号和业务账号的权限，最后用角色把权限管理变成可维护的结构。

3.1 一人一账号：共享账号为什么最先被扣分

SHG-Mssql-01-01-01的要求是按用户分配账号，避免不同用户共享账号。共享账号的后果不是「权限不明确」这么抽象——真正的问题是审计日志失效。当三个运维共用一个dba账号时，登录记录里出现十次异常操作，你无法定位到具体是谁做的，日志直接变成黑匣子。这条同时也是后面「登录失败锁定」「口令有效期」等策略能落地的前提，共享账号上的任何口令策略都没有意义。

建账号的动作本身很简单，两套写法要分清：

USE master; -- 老版本语法（SQL Server 2000 时代的经典写法，规范原文采用） EXEC sp_addlogin 'user_name_1', 'password1'; EXEC sp_addlogin 'user_name_2', 'password2'; -- 较新版本用 CREATE LOGIN，支持 CHECK_POLICY 对接 Windows 口令策略 CREATE LOGIN user_name_1 WITH PASSWORD = 'password1', CHECK_POLICY = ON, CHECK_EXPIRATION = ON;

sp_addlogin的三个参数依次是登录名、口令、默认数据库（可省略）。CREATE LOGIN那两个开关值得打开：CHECK_POLICY = ON会让这个账号继承操作系统的口令复杂度与锁定策略，CHECK_EXPIRATION = ON强制口令到期更换，等于用一条语句把「强口令」和「定期更换」两个要求一起满足了。账号命名建议带上用途前缀，比如按「业务缩写 + 人员编号」组合，避免出现test1、admin2这类看不出归属的名字。

3.2 无效账号清理与启动账号降权

SHG-Mssql-01-01-02处理的是历史遗留账号：离职人员留下的、临时测试建的、安装时自动生成但从未使用的。清理前必须先确认哪些是无效的，规范里写的是「询问管理员」，实际操作中更可靠的做法是看登录时间和连接情况，把超过一个季度没有任何登录记录的账号列出来，再逐个和业务方确认。删除动作在企业管理器里是「安全性 → 登录 → 右键删除」，脚本方式对应DROP LOGIN。回退方案是重新创建账号并补回原有角色，所以删除前那份角色清单必须留着。

SHG-Mssql-01-01-03的目标更隐蔽：限制启动 SQL Server 服务的那个 Windows 账号的权限。服务启动账号的权限会被它拉起的子进程继承，如果这个账号在本地Administrators组里，那么数据库进程也间接拥有了管理员权限。规范给出的做法是新建专用服务账号后，把它从Users组中移除，且不要提升为管理员组成员。这一步做完必须重启服务验证，很多翻车案例就是改完账号没测重启，等到下次计划内重启时服务起不来。

注意：改启动账号前先确认这个账号是否被用于访问网络共享做备份。备份作业经常依赖服务账号的网络身份，账号一换，备份路径的权限可能同时失效。

3.3 权限最小化与角色管理：两条容易被做成空条的基线

SHG-Mssql-01-01-04要求在数据库权限配置能力内按业务需要授予最小权限，落地动作分两步：取消业务账号不需要的服务器角色，取消不需要的数据库访问许可和数据库内角色。判定「不需要」的依据来自业务方确认，不是凭感觉删。执行时建议用DENY先观察再REVOKE，因为DENY是显式拒绝，可以快速回退，而直接删角色成员之后想还原就得重新对照清单。

-- 示例：收回业务账号的多余服务器角色，只保留 public USE master; ALTER SERVER ROLE sysadmin DROP MEMBER biz_app; -- 业务账号不应是系统管理员 ALTER SERVER ROLE securityadmin DROP MEMBER biz_app; -- 数据库内：移出 db_owner，只保留读写 USE biz_db; ALTER ROLE db_owner DROP MEMBER biz_app; ALTER ROLE db_datareader ADD MEMBER biz_app; ALTER ROLE db_datawriter ADD MEMBER biz_app;

ALTER SERVER ROLE ... DROP MEMBER是服务器级角色调整，影响范围是整个实例；ALTER ROLE ... ADD MEMBER是数据库级，只作用于当前库。执行顺序建议先降服务器角色再调数据库角色，因为服务器角色里sysadmin的成员天然拥有所有库的全部权限，不先摘掉它，后面数据库内的收权动作看不出效果。

SHG-Mssql-01-01-05讲的是用数据库角色管理对象权限，而不是给每个用户单独授权。这条的价值在于可维护性：当十个用户需要相同的读写权限时，建一个角色授予SELECT / INSERT / UPDATE / DELETE / EXEC五类权限，再把十个人加进角色，后续调整权限只改角色一处。规范原文列出的权限清单里还有一个DRI（Declarative Referential Integrity），用于允许创建外键约束，一般业务账号不需要，除非该账号要执行建表脚本。

-- 建角色并授予对象级权限，再挂用户 USE biz_db; CREATE ROLE app_reader; GRANT SELECT ON SCHEMA::dbo TO app_reader; GRANT EXECUTE ON SCHEMA::dbo TO app_reader; ALTER ROLE app_reader ADD MEMBER biz_app;

这段的关键是ON SCHEMA::dbo这种架构级授权写法，比逐个表授权省事得多，新加的表自动被覆盖。回退方案是把角色整个删掉，成员关系会随之解除，这也是用角色管理的额外好处——撤销时不用一个个找。

3.4 空密码与强口令：sa 账号的十条命

SHG-Mssql-01-01-06是六条里唯一明确写了强度要求的：所有账号口令都要改，sa账号至少 10 位强口令。检查空口令的语句规范原文给得很直接：

-- 查出所有空口令账号，返回 0 行才算通过 SELECT name, password FROM syslogins WHERE password IS NULL ORDER BY name;

改口令的经典写法是sp_password，三个参数依次是旧口令、新口令、用户名。这个存储过程的坑在于：如果执行者本身不是该账号也不是sysadmin，必须提供旧口令；用sysadmin身份改别人的口令时旧口令可以传NULL。较新版本改用ALTER LOGIN：

-- 老写法 USE master; EXEC sp_password 'old_pwd', 'NewP@ssw0rd_2024', 'sa'; -- 新写法，不需要旧口令（需具备 ALTER ANY LOGIN 权限） ALTER LOGIN sa WITH PASSWORD = 'NewP@ssw0rd_2024';

口令改完要立刻做一次登录验证，用新口令连一次确认可用，再把新口令存入密码管理系统。这一步听起来废话，但确实有人改完sa口令后发现应用配置里写死了旧口令，业务直接断连。更稳妥的顺序是：先查应用连接串用的是哪个账号，确认不是sa，再改sa口令，这样即使改错也不影响业务。

4. 日志、协议与设备层：审计级别、协议裁剪和 TCP/IP 栈加固

账号域做完，剩下三个域加起来 6 条，工作量和风险都不低。日志那条看着最简单，实际上最容易被误解；协议那三条涉及注册表，改错直接影响网络连通；设备层两条一个动存储过程、一个动补丁，都属于不可轻易回退的操作。这一章按「记录什么 → 暴露什么 → 底层怎么防 → 表面怎么收」的顺序推进。

4.1 审计级别调到「全部」到底记录了什么

SHG-Mssql-02-01-01要求在数据库属性里把安全性中的审计级别调整为「全部」，身份验证模式调整为「SQL Server 和 Windows」，目的是记录用户登录的账号、成功与否、登录时间以及远程登录的 IP。

这里有个常见误解需要说清：这个审计级别记录的是登录级事件，不是语句级的操作审计。也就是说它能告诉你「谁在几点从哪个 IP 登录成功了」，但不会告诉你「他执行了哪条 UPDATE」。如果方案里要求记录数据增删改，光开这个不够，还需要数据库审计功能或触发器，规范原文这一条只覆盖到登录层面，写方案时不要夸大它的能力。

验证方式很实在：改完配置后故意用错误口令登录三次，再去查看 SQL Server 错误日志，应该能看到对应的失败记录，包含账号名和时间。看不到就说明审计级别没生效或者需要重启服务。

提示：审计级别调到「全部」之后错误日志的增长速度会明显加快，上线前先确认日志文件轮转配置和磁盘余量，否则几周后可能因为日志写满导致实例异常。

4.2 协议裁剪与强制加密：只留 TCP/IP 的代价

SHG-Mssql-03-01-01要求通过服务网络实用工具查看协议列表，只保留 TCP/IP，禁用其他协议。多一个协议就多一个攻击面，这条本身没问题，但要先确认客户端连接方式：如果存在使用命名管道的老客户端，禁用之后会直接连不上。规范把这条的风险标为「高」正是因为这个。

SHG-Mssql-03-01-04是通讯协议加密，在服务器网络配置工具的「常规」页把「强制协议加密」打开。开启后客户端与服务端之间的传输被加密，代价是性能有损耗，而且老版本客户端可能不支持加密握手而连接失败。上线策略建议先在测试环境用真实客户端连一遍，确认兼容后再推到生产，并且保留关闭开关的操作路径。

4.3 TCP/IP 协议栈的三个注册表键值

SHG-Mssql-03-01-02是整份规范里唯一直接改操作系统注册表的条目，三个键值都在HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下面：

• DisableIPSourceRouting设为2，关闭源路由，防御源路由欺骗攻击。
• EnableICMPRedirect设为0，关闭 ICMP 重定向接受，防止路由表被恶意改写。
• SynAttackProtect设为2，加强 SYN FLOOD 攻击的防护。

# 逐个写入并回读确认，改之前已经用 reg export 存过快照 $base = "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" Set-ItemProperty -Path $base -Name DisableIPSourceRouting -Value 2 -Type DWord Set-ItemProperty -Path $base -Name EnableICMPRedirect -Value 0 -Type DWord Set-ItemProperty -Path $base -Name SynAttackProtect -Value 2 -Type DWord # 回读三个键值，确认写入成功 Get-ItemProperty -Path $base | Select-Object DisableIPSourceRouting, EnableICMPRedirect, SynAttackProtect

Set-ItemProperty的-Type DWord必须写，否则可能被写成字符串类型导致系统不识别。这三个键值生效不需要重启整机，但需要重启 TCP/IP 相关服务或重启系统才完全落地。回读那一步是判断依据，输出三个值与预期一致才算通过。

注意：SynAttackProtect在较新的 Windows 版本中已由系统动态管理，手工写入可能被覆盖或产生非预期行为。执行前先确认当前系统版本对该键值的支持情况，不确定就只做前两个键值，并在文档里注明原因。

4.4 危险存储过程清理与补丁核对

SHG-Mssql-04-01-01要求停用危险扩展存储过程。规范原文给了一长串sp_dropextendedproc调用，核心是几类：命令执行类的xp_cmdshell、注册表操作类的xp_regread / xp_regwrite / xp_regdeletekey、文件系统类的xp_dirtree / xp_getfiledetails、OLE 自动化类的sp_OACreate / sp_OAMethod系列，以及sp_makewebtask。

USE master; -- 命令执行类：最危险，优先删除 EXEC sp_dropextendedproc 'xp_cmdshell'; -- 注册表读写类：可被用于提权和信息收集 EXEC sp_dropextendedproc 'xp_regread'; EXEC sp_dropextendedproc 'xp_regwrite'; EXEC sp_dropextendedproc 'xp_regdeletekey'; EXEC sp_dropextendedproc 'xp_regdeletevalue'; EXEC sp_dropextendedproc 'xp_regenumvalues'; -- 文件系统类：可枚举目录、读取文件信息 EXEC sp_dropextendedproc 'xp_dirtree'; EXEC sp_dropextendedproc 'xp_getfiledetails'; EXEC sp_dropextendedproc 'xp_fixeddrives'; -- OLE 自动化类：可加载外部组件 EXEC sp_dropextendedproc 'sp_OACreate'; EXEC sp_dropextendedproc 'sp_OADestroy'; EXEC sp_dropextendedproc 'sp_OAMethod'; GO

每条语句只做一件事：从 master 库中移除指定的扩展存储过程。删除顺序建议按危害程度排，命令执行类放最前面。执行时如果某个过程本来就不存在，语句会报错并中断后续，所以整段脚本最好逐条执行或者在每条外面套存在性判断。验证方式是对着删除清单逐个调用，预期全部返回「找不到该存储过程」的错误，如果某个还能正常执行，说明没删干净。

补丁那条SHG-Mssql-04-01-02用SELECT @@VERSION查当前版本，然后对照补丁号表判断是否最新：

这张表针对的是较早期的产品线，核对时只看版本字符串的第三段数字。如果当前版本低于表中最新值，说明补丁缺失，需要下载对应补丁包安装。补丁安装属于不可回退操作，规范里回退方案写的是「无」，这一条必须排在所有加固动作的最后做，并且提前做好完整备份和回滚预案。

5. 常见问题排查：五类最容易翻车的加固动作

11 条基线里，真正让人半夜爬起来处理问题的就那么几个动作。下面这五类是我在类似项目里反复见到的翻车现场，每一类都按「现象 → 原因 → 解决」写清楚。

5.1 加固完成后应用连不上数据库

现象是应用日志里刷连接超时或登录失败，但用管理工具本地还能连上。原因通常是协议裁剪时把客户端依赖的协议禁掉了，或者强制加密开启后老客户端不支持握手。解决思路是先回退协议配置确认连通性恢复，再用真实客户端逐个协议测试，确定业务实际走的是哪条路径。如果必须开加密，先在连接串里显式加上加密参数验证客户端版本是否支持，不支持就先升级客户端驱动，别在生产上硬推。

5.2 启动账号降权后服务起不来或备份失败

现象是改完服务启动账号后，服务重启卡在启动阶段，或者服务能起但备份作业全部报权限错误。原因是新账号缺少必要权限：服务账号需要对数据目录和日志目录有读写权限，备份作业还需要对备份路径有写权限，如果备份走网络共享，还需要网络身份。解决方法是把新账号加进对应的目录 ACL，而不是简单塞回管理员组。规范的意图是「最小权限」，不是「不给权限」，权限给到够用为止。

5.3 删了 xp_cmdshell 之后某个定时作业挂了

现象是某天凌晨的批处理作业失败，错误信息指向一个不存在的存储过程。原因是老业务用xp_cmdshell调用外部程序做数据导出，这条调用链没人记录在文档里。这类情况属于删之前没做依赖排查。解决办法是先恢复该存储过程让业务跑起来，再把作业改造成用 SQL Agent 的操作系统命令步骤或外部调度工具，确认新方案稳定后再删第二次。这也是为什么删除存储过程那条要排在补丁之前、并且必须留一份完整的功能清单。

5.4 审计级别调到全部后磁盘告警

现象是加固后一两周，服务器磁盘使用率异常上升，错误日志文件涨到几个 GB。原因就是审计级别「全部」记录了所有登录尝试，其中包括大量失败登录，日志增长速度远超预期。解决方法是配置错误日志的轮转数量和单文件大小上限，把历史日志自动回收，同时把日志目录纳入监控。如果业务量确实很大，评估是否只保留「失败登录」级别而不是「全部」，并在文档里说明取舍理由——这比闷头调回原级别更经得起复核。

5.5 收权收过头，连管理员都进不去

现象是权限最小化做完，某个原本能用的管理入口失效，想改回来发现当前账号也没权限了。原因是没有预留应急通道：sysadmin角色被清空，或者只保留了 SQL 身份验证而sa口令被人改过。解决办法是加固前确认至少有一个可用的 Windows 身份验证管理员账号，并且这个账号不参与业务收权；如果实例只允许 SQL 身份验证，务必在改口令后把新口令存进受控的密码库。我一般会额外留一个只用于应急的本地账号，明确写进文档，但它不参与日常运维。

6. 验收与答辩：把 11 条做成一张可复核的证据表

加固做完不等于能交差。审计和答辩看的是证据链，不是你口头说「已经按规范加固完成」。真正省事的做法是在动手前就把验收表建好，每条基线对应一行，四列内容：改前状态、执行动作、复核命令、证据形式。

这张表的好处是它同时也是答辩提纲。上台讲的时候不用把 11 条平铺，抓三条讲深就够：第一条讲账号为什么必须一人一号，用登录日志无法定位责任人这个后果切入；第二条讲启动账号降权的原理，说清子进程权限继承这条链；第三条讲存储过程清理，重点讲你怎么发现xp_cmdshell有业务依赖、怎么改造、怎么二次删除。有依赖排查过程的加固方案，比单纯罗列执行结果的方案可信度高一个层级。

如果评审追问「你怎么保证改完不影响业务」，答案不在文档里，在顺序里：所有高风险动作都排在停机窗口内，每个动作执行前有快照、执行后有复核命令、复核不通过立刻走回退。规范里那列「实施风险」不是摆设，它就是让你用来排窗口期的。

时间分配上给个参考：账号域 6 条大约占总工作量的一半，但其中真正需要停机窗口的只有启动账号那一项；协议域三条要一次性做完并重启服务，适合和补丁安装合并到同一个窗口；存储过程删除建议单独做一次，做完观察一周再继续。很多人把所有动作塞进一个晚上，结果出了问题分不清是哪一步导致的，只能整体回退，白干一夜。

从那以后我每次接这类加固方案，都强制走一遍「先建验收表、再做回退包、最后才动配置」的流程，哪怕交付时间再紧也不跳过前两步。表和包都是半小时的事，省下来的却是整晚的排查时间。希望这套结构能帮到你，无论是交一份毕设方案，还是把手上那台生产库安安稳稳地加固完。

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