ADO Command对象实战：参数化查询与存储过程调用全解析

简介面向VC开发者的ADO Command对象实例代码包适合学习数据库操作、存储过程调用及参数化查询的入门与中级程序员。内含TestAdo演示工程覆盖_CommandPtr智能指针创建、ActiveConnection绑定、CommandText与CommandType设置、Parameter参数追加及Execute执行等关键环节并给出try-catch异常处理参考便于理解完整数据访问流程。 压缩包共11个文件以cpp源文件、h头文件和Visual Studio工程配置vcxproj/sln为主附带txt说明文本整体仅8KB属于轻量级示例代码。已有524人学习浏览可直接在VS中打开TestAdo.sln编译运行对照代码观察普通查询、存储过程调用及带参数SQL语句的实际写法对快速上手ADO、解决VC数据库编程中的常见问题很有帮助。项目中参数化查询的示范还有助于规避SQL注入风险。1. Command对象是什么——为什么它比直接拼SQL更值得用维护老系统、写数据迁移脚本、或者做报表导出的时候Command对象是绕不开的一环。很多从业者一开始都用连接的Execute方法直接拼SQL等遇到字符串里有单引号、日期格式被区域设置带偏、存储过程的输出参数读不到这类翻车时才回头找ADO里的Command。简单说Command对象把“SQL语句或存储过程名、参数定义、参数方向、命令类型”打包成一趟完整的数据库指令让数据访问层按你给定的类型去解析执行而不是把拼好的字符串原样丢给数据库。它解决的是传参安全性、类型匹配、存储过程调用和命令复用这四件日常最痛的事适合所有用脚本或老框架维护数据访问代码的从业者。下面从原理讲到参数怎么设再落到每个坑的排查可以直接照着复现你的第一个参数化查询。2. 从Connection到Command先理清四个核心属性和两个集合在实际写代码之前建议先搞清楚Command对象上有哪些东西是可调的。用Command做查询本质上只有三件事命令发给谁连接、命令本身是段什么文本、执行的时候带哪些参数。围绕这三件事最常用的就是四个属性ActiveConnection、CommandText、CommandType、CommandTimeout和两个集合Parameters、Properties。很多人在这块翻车不是不会调API而是没搞清楚属性和Provider之间的联动关系才会出现各种“换个机器就报错”的玄学问题。2.1 ActiveConnection与CommandText命令从哪里来、发给谁ActiveConnection是Command对象最先要设置的属性。它的值可以是一个已经打开或未打开的ADODB.Connection对象也可以直接是一个连接字符串。两种写法在行为上有一点细微差别传Connection对象时Command会复用这个连接的会话上下文、事务边界和连接池状态这是推荐做法因为多个Command可以共享同一个事务出错时一起回滚传连接字符串时ADO会在内部自动创建一个隐藏的Connection用完后你需要自己想办法关闭不然连接数会悄悄涨上去。CommandText则是这条命令的文本载体。当CommandType取adCmdText时它是一段SQL语句取adCmdStoredProc时它是存储过程的名字取adCmdTable时它是表名。我一般习惯把CommandText和CommandType绑定设置只设置CommandText而不指定CommandType会让ADO以最慢的未知模式去猜这是一类很隐蔽的性能浪费。还有一个新手必踩的细节在CommandText里参数占位符用的是问号?而不是SQL Server的参数名参数真正叫什么名字、什么类型全靠Parameters集合里的对象定义。2.2 CommandType的三个核心取值告诉ADO你发的是什么东西CommandType是决定ADO怎么解析CommandText的开关取值来自CommandTypeEnum。日常工作最常用的是下面几个| 枚举值 | 数值 | 含义 | 适用场景 | | adCmdText | 1 | CommandText是SQL语句 | 增删改查 | | adCmdTable | 2 | CommandText是表名 | 整表直接打开 | | adCmdStoredProc | 4 | CommandText是存储过程名 | 存储过程调用 | | adCmdUnknown | 8 | 让ADO自己去判断 | 尽量不用 | | adCmdTableDirect | 512 | 直接打开表不走SQL解析 | 底层表格驱动时使用 |如果CommandType写成adCmdText但CommandText里放的是存储过程名ADO会把它当成一条SQL去给数据库解析数据库大概率直接报语法错误反过来把一段SELECT语句配成adCmdStoredProc数据库就会把它当成一个不存在的存储过程去查报“找不到存储过程”。这两种错法都特别容易让人怀疑代码逻辑写错了其实只是开关没配对。adCmdUnknown是最容易忽略的坑。它让ADO先发一条元数据查询帮数据库判断命令是什么类型然后再真正执行命令等于一条命令干了两次网络往返性能损耗在批量循环里会被放大得非常明显。所以我在生产脚本里的原则是能用代码明确类型就绝不交给未知模式去猜。另外CommandTimeout这个属性默认继承Connection的超时设置SQL Server默认30秒对复杂存储过程来说经常不够用执行到一半就报“超时时间已到”。它单位是秒设成0表示无限等待生产环境不建议全局乱设只对个别慢命令单独加长。2.3 Parameters与PropertiesCommand背后两只容易被忽略的手Parameters集合是Command对象的核心装配区Append、Delete、Item三种操作最常见。每次执行前用CreateParameter生成一个参数对象按顺序Append进来执行时就按这个顺序把值传给数据库。要注意的是在adCmdText模式下很多Provider并不是靠参数名去匹配SQL里的?而是靠集合里的追加顺序去一一对应所以参数顺序写错SQL文本里又带多个?时数据就会张冠李戴。这种错误编译器不报错、数据库也不报错只有查出来的结果是错的很难排查。Properties集合则更像一块“扩展坞”里面装着当前数据访问提供程序暴露出来的能力。例如有的Provider会在Properties里提供“是否支持参数化查询”“是否返回多个结果集”等开关换个Provider这个集合的内容可能完全不同。当连接串里的Provider从SQLOLEDB换成SQLNCLI时某些SQL语句的表现会发生变化根源就在这里。排查这类问题的时候与其反复试SQL不如先把这个集合里每个属性的名字和值打印一遍很多“换个机器就报错”的问题就是两边的Provider能力集合对不上造成的。Dim cmd, i Set cmd CreateObject(ADODB.Command) cmd.ActiveConnection conn cmd.CommandType 1 cmd.CommandText SELECT ? AS 测试值 For i 0 To cmd.Properties.Count - 1 WScript.Echo cmd.Properties(i).Name cmd.Properties(i).Value Next注意Properties集合里的属性由Provider决定不同Provider差很多。这段代码在设置ActiveConnection前执行能拿到的属性非常少设置后再拿才完整因为Command对象的一些元数据能力是连上数据库之后才暴露出来的。读完这一章你应该能先回答三个问题命令发到哪、命令是什么类型、参数往哪里装配然后我们再来写可运行的代码。3. 动手写第一个Command实例参数化查询的最小可运行代码概念理清楚以后就该动手了。例子就用VBScript因为它跑ADO只需要一个cscript环境任何Windows机器都能直接执行逻辑也能无缝平移到ASP、VB6、PowerShell。先准备一张表命令如下CREATE TABLE 订单 ( 订单号 INT PRIMARY KEY, 客户编号 INT NOT NULL, 金额 DECIMAL(18,2) NOT NULL, 下单时间 DATETIME NOT NULL );这张表会贯穿后面的例子字段都不复杂但包含了数字、小数、日期三种最常见的传参类型。3.1 最小连接与Command实例六行代码跑通一条查询先不碰参数用最直接的方式跑一条固定SQL验证Command对象的链路是通的。 1) 创建连接 Set conn CreateObject(ADODB.Connection) conn.Open ProviderSQLOLEDB.1;Data Source数据库地址;Initial Catalog库名;User ID账号;Password密码; 2) 创建 Command 并装配 Set cmd CreateObject(ADODB.Command) cmd.ActiveConnection conn cmd.CommandText SELECT 订单号, 金额 FROM 订单 WHERE 客户编号 1 cmd.CommandType 1 adCmdText 3) 执行并读取结果 Set rs cmd.Execute() Do While Not rs.EOF WScript.Echo rs(订单号) | rs(金额) rs.MoveNext Loop rs.Close conn.Close这段代码里的第一步是把连接串的Provider指定为SQLOLEDB.1这是SQL Server最常见的OLE DB驱动写法。数据源地址、账号密码要替换成实际环境的值实例名带反斜杠时要按连接串规则转义。第二步里ActiveConnection直接复用了已经打开的conn对象好处是Command和Connection共享会话事务控制统一。第三步的Execute返回值是一个Recordset只要SQL不是增删改返回的结果集就一定要遍历完或者显式Close否则下次执行同一个连接上的命令时可能报“对象已关闭或没有权限”之类的错。需要特别说明的是cmd.CommandType 1这个赋值。这里写1是为了让代码在任何环境里都不依赖常量定义如果你用ASP或VB6工程里已经引用了ADO类型库可以直接写成adCmdText数值和含义完全一致。如果你看的资料里写的是adCmdText记住它背后就是1两者不存在谁对谁错。3.2 用CreateParameter绑定输入参数告别字符串拼接固定SQL只能跑通链路真正发挥Command威力的是参数化。先看大多数从业者最初都会犯的写法Dim kw kw 财务部 Set rs conn.Execute(SELECT * FROM 员工 WHERE 部门 kw )这种写法在kw里出现一个单引号时SQL就变成三个单引号轻则查询出错重则数据库报语法错误或导致注入。更隐蔽的问题是日期参数用字符串拼日期会受服务器区域设置影响同一个脚本在中国机器上正常在美国机器上查出来的范围就可能是错的。参数化的正确写法是让Command对象拿着“类型定义值”去执行。Set cmd CreateObject(ADODB.Command) cmd.ActiveConnection conn cmd.CommandText SELECT * FROM 员工 WHERE 部门 ? AND 入职日期 ? cmd.CommandType 1 cmd.Parameters.Append cmd.CreateParameter(部门, 200, 1, 50, 技术部) cmd.Parameters.Append cmd.CreateParameter(入职日期, 7, 1, 8, #2024-01-01#) Set rs cmd.Execute() Do While Not rs.EOF WScript.Echo rs(姓名) | rs(入职日期) rs.MoveNext Loop rs.CloseCreateParameter一共五个参数依次是参数名、数据类型、方向、长度、值。这里第一个参数名字随便起但在adCmdText模式下名字基本只用于你自己读代码数据库端匹配主要靠?的顺序。第二个参数200是adVarChar7是adDate都是ADO公开的数据类型枚举值第三个参数1是adParamInput表示输入参数第四个参数50对字符串类型表示列宽定长类型如整数传4或直接省略也行第五个参数就是实际要传的值。如果你想查中文字段首选adWChar即202类型后面避坑章会专门说这个区别。这种写法下单引号、反斜杠、日期格式都由数据访问库处理数据库拿到的是经过编码后的合法参数而不是被拼进SQL文本里的裸字符串注入这条路就堵死了。同时数据库可以缓存这条参数化语句的执行计划同样的查询第二次执行时省掉了语句解析的时间这是后面要讲的性能收益的来源。3.3 Execute的返回值与Recordset读取拿回结果的两条路Command.Execute有两种典型调用方式区别在于你有没有接收返回值。查询语句必须接收返回值因为结果集在Recordset里而INSERT、UPDATE、DELETE这类不返回结果集的语句可以不接收直接cmd.Execute但要注意这时你拿不到受影响行数Command对象本身不像Connection.Execute那样有RecordsAffected参数。如果你需要知道一条UPDATE到底改了几行常见做法是让存储过程用输出参数把行数带回来这部分在下一章展开。cmd.CommandText UPDATE 订单 SET 金额 金额 * 1.1 WHERE 客户编号 ? cmd.CommandType 1 cmd.Parameters.Append cmd.CreateParameter(客户编号, 3, 1, 4, 1001) cmd.Execute 不接收返回值 Set rs cmd.Execute() 示例Execute 也可能返回 Nothing If rs Is Nothing Then WScript.Echo 没有返回结果集 Else rs.Close Set rs Nothing End If执行UPDATE这类语句后Execute可能返回Nothing如果直接Set rs再去访问rs.EOF就会报“对象变量或With块变量未设置”这一点和422行代码的执行结果无关纯粹是返回值没接住。读Recordset也有两条路一是按列名rs(金额)二是按下标rs(1)。按列名的好处是SQL调整字段顺序不影响代码按下标的好处是少一次名字解析速度略快。在循环里频繁读值时我习惯用下标前提是SELECT的字段顺序固定否则数据就串位了这是为了快那一点而引入的隐性陷阱。4. 存储过程调用与输出参数Command对象最值钱的场景如果你只写简单的增删改查用拼接SQL也许能凑合很长一段时间。但一旦涉及存储过程尤其是带输出参数和返回值的存储过程直接用Connection.Execute就完全不够了。这里才是Command对象真正值钱的场景也埋着最多的坑。4.1 调用存储过程的CommandTypeadCmdStoredProc与文本Call调用存储过程有两种等价写法。第一种是把CommandType设成4CommandText直接写存储过程名cmd.CommandType 4 adCmdStoredProc cmd.CommandText sp_GetOrderByCustomer第二种是不改CommandType保持1但把调用语句写进CommandTextcmd.CommandType 1 adCmdText cmd.CommandText {call sp_GetOrderByCustomer(?,?)}两种写法数据库执行的结果一样但对参数的匹配规则有细微差别。adCmdStoredProc模式下参数集合里的名字很多时候会被忽略按Append顺序和存储过程定义顺序对应而adCmdText模式下某些Provider会要求参数名必须和存储过程定义的参数名严格一致否则报“过程中的参数过多或过少”。我的经验是如果只是调用存储过程优先用adCmdStoredProc少一层解析参数顺序也直观如果你需要在存储过程调用前动态拼一段SQL再用adCmdTextCALL写法。4.2 输出参数与返回值接住存储过程带回来的信息存储过程最常见的需求是返回一个结果集同时通过输出参数带一个统计值或者状态码。先看存储过程的定义CREATE PROCEDURE sp_GetOrderByCustomer CustomerId INT, TotalCount INT OUTPUT AS BEGIN SET NOCOUNT ON; SELECT TotalCount COUNT(*) FROM 订单 WHERE 客户编号 CustomerId; SELECT 订单号, 金额, 下单时间 FROM 订单 WHERE 客户编号 CustomerId ORDER BY 下单时间 DESC; END这个存储过程输出两类结果一个结果集一个OUTPUT参数TotalCount。VBScript里完整的调用长这样Set cmd CreateObject(ADODB.Command) cmd.ActiveConnection conn cmd.CommandText sp_GetOrderByCustomer cmd.CommandType 4 cmd.Parameters.Append cmd.CreateParameter(ReturnValue, 3, 4) cmd.Parameters.Append cmd.CreateParameter(CustomerId, 3, 1, 4, 1001) cmd.Parameters.Append cmd.CreateParameter(TotalCount, 3, 2, 4) Set rs cmd.Execute() 先耗尽或关闭结果集再读输出参数 If Not rs Is Nothing Then Do While Not rs.EOF WScript.Echo rs(订单号) | rs(金额) | rs(下单时间) rs.MoveNext Loop rs.Close End If WScript.Echo 订单总数 cmd.Parameters(TotalCount).Value WScript.Echo 存储过程返回值 cmd.Parameters(ReturnValue).Value这里的第一个参数ReturnValue是adParamReturnValue类型用来接收存储过程用RETURN语句返回的整数状态码第二个CustomerId是输入参数第三个TotalCount是输出参数。注意输出参数在Append时不需要给值它是在Execute过程中由数据库写回的。这里有一条血泪经验输出参数一定要等Recordset被完全读取并关闭之后再访问Value否则你大概率拿到Null而且不会报错。为什么顺序这么敏感因为在某些Provider的实现里数据库只有在命令执行完毕、结果集被消费完之后才会把输出参数的值回填到客户端的Parameters集合里。如果你先读了输出参数接着再去遍历结果集读到一半输出参数又变了这就是“数据看起来是错的但又不稳定”的怪象来源。4.3 一个完整例子分页查询与模糊搜索的参数化写法接下来写一个更贴近真实业务的存储过程把模糊查询和分页糅在一起。模糊查询最常见的错误是有人把%直接拼到SQL里一部分变成字符串一部分变成参数既难看又容易出语法错。正确做法是让SQL保留LIKE % Keyword %参数只负责把用户输入的原样传进来。CREATE PROCEDURE sp_SearchOrders Keyword NVARCHAR(50), PageIndex INT, PageSize INT, TotalCount INT OUTPUT AS BEGIN SET NOCOUNT ON; SELECT TotalCount COUNT(*) FROM 订单 o INNER JOIN 客户 c ON o.客户编号 c.客户编号 WHERE c.客户名称 LIKE % Keyword %; ;WITH paged AS ( SELECT o.订单号, o.金额, o.下单时间, c.客户名称, ROW_NUMBER() OVER (ORDER BY o.下单时间 DESC) AS row_no FROM 订单 o INNER JOIN 客户 c ON o.客户编号 c.客户编号 WHERE c.客户名称 LIKE % Keyword % ) SELECT 订单号, 金额, 下单时间, 客户名称 FROM paged WHERE row_no BETWEEN (PageIndex - 1) * PageSize 1 AND PageIndex * PageSize; END调用端的代码和4.2类似区别在于Keyword用adVarWChar类型长度按数据库列宽给足PageIndex、PageSize用adIntegerTotalCount用adInteger加adParamOutput方向。cmd.CommandText sp_SearchOrders cmd.CommandType 4 cmd.Parameters.Append cmd.CreateParameter(Keyword, 202, 1, 50, 科技) cmd.Parameters.Append cmd.CreateParameter(PageIndex, 3, 1, 4, 1) cmd.Parameters.Append cmd.CreateParameter(PageSize, 3, 1, 4, 20) cmd.Parameters.Append cmd.CreateParameter(TotalCount, 3, 2, 4) Set rs cmd.Execute() ...遍历结果集然后读取 TotalCount参数202是adVarWChar也就是数据库里的NVARCHAR。如果你把中文字段错配成200adVarChar查询结果通常也能出来但在某些排序规则下会出现查不全或者乱码。这一条和分页的边界估算放一起是存储过程调用里最常被复查的两个点。把分页边界处理好之后这套写法可以直接照抄到报表系统或管理后台的列表查询里。到这里Command对象的输入参数、输出参数、返回值和存储过程四种用法都过了一遍下面这份排查清单建议认真看完很多“偶尔正常、偶尔Null”的怪象其实是同一个根因的不同表象。5. 避坑清单Command使用中的常见翻车点与排查下面不是理论补充而是把实际维护脚本里最常见的几类问题按现象到原因再到解决写清楚。每一条都有不少人在线上环境里反复折腾很久最后发现根因都出在很小的地方。5.1 参数追加顺序错乱SQL不报错结果却张冠李戴现象SQL语句本身简单字段对应也检查过但查询结果里日期变成另一个字段的值或者报“过程或函数需要参数xxx但未提供该参数”在adCmdText模式下这种错尤其隐蔽因为数据库根本不会提示你参数顺序反了。原因在CommandText使用?占位符时ADO的Parameters集合按Append的顺序从左到右匹配?参数名不参与匹配。不少人习惯把参数按照自己顺手的顺序Append或者中间插入一个参数后没有重新调整顺序结果值和字段对不上。在adCmdStoredProc模式下多数Provider同样按集合顺序对应存储过程定义顺序名字只是给人看的。解决把参数Append的顺序和CommandText中?出现的顺序、以及存储过程定义顺序保持一致。改代码时先数清SQL里有几个?再逐个对应。为了减少这类错误我在维护脚本时会专门写一段校验在调试模式下把每个参数的Name、Value、Direction打印出来执行前人工对照一次。5.2 类型与长度不匹配中文乱码和字符串被截断现象中文字符串通过Command参数写进数据库后变成一串问号或者写入过长的字符串时数据库并不报错但数据被截断后面的内容丢了还有的是NVARCHAR字段一切正常VARCHAR字段偶尔出问题。原因CreateParameter里类型给错是最常见的adVarChar对应VARCHARadVarWChar对应NVARCHAR两者底层编码长度不同。另一个常见原因是Size给得太小比如数据库字段是NVARCHAR(100)你Append时只给了50数据库端按50的长度截断。和连接串里直接拼SQL不同Command对象不会替你做“类型修整”它把类型和长度原样传给数据库。解决CreateParameter的第四个参数Size按数据库列定义给不要贪图省事写一个固定值。数据库字段是NVARCHAR(100)就写202类型、100长度是VARCHAR(50)就写200类型、50长度。如果有输出参数Size还得考虑返回值本身可能比传入值长宁可给大一些。5.3 输出参数读出来是Null取值顺序和结果集生命周期现象存储过程里的OUTPUT参数明明有值Execute之后立即读取却返回Null有人会把代码改成“执行两次”第二次才能读到于是怀疑存储过程写错了。原因结果集还没有被消费完或者没有关闭时部分Provider不会把输出参数回填到客户端。你读到的Null只是一个尚未填充的空值不是数据库那边没有返回。连读两次之所以能读到是因为第一次读取过程中结果集已经被慢慢消费掉了行为不稳定不能作为可靠写法。解决调用完Execute之后先把Recordset循环遍历完再关闭关闭后再去读cmd.Parameters集合里的输出参数和ReturnValue。如果命令执行后你不在乎结果集直接Set rs cmd.Execute()后立刻关掉rs再读输出参数。最好养成“先结果集、后输出参数”的固定顺序这套顺序在SQL Server环境下基本可以稳定复现。5.4 命令超时与连接未释放批处理脚本跑着跑着就卡死现象脚本循环几千次执行同一个Command跑到中间某一次开始报“超时时间已到”之后怎么重试都报同样的错或者脚本结束回到数据库里看连接数发现一堆连接状态涨着不掉。原因Command对象默认继承Connection的超时设置SQL Server默认是30秒。某个慢查询正好卡在30秒边缘就会偶发超时。而连接没释放通常是脚本里在某个分支提前退出没走到conn.Close在VBScript这类没有try/finally的语言里报错后代码直接跳出后面的Close不会执行。解决给长命令单独放大超时循环前统一设置cmd.CommandTimeout 60或者按数据库最大执行时间预估一个值脚本里用On Error Resume Next配套状态变量做收尾逻辑确保无论是否报错都执行conn.Close和Set conn Nothing。我一般会在脚本入口写好一个清理函数在每个退出点之前调用它这样即使中途出错连接也能被释放。5.5 Preparedtrue执行计划“老化”缓存带来的性能错觉现象一个参数化查询第一次执行很快第二次反而变慢或者同一条参数化语句在大批量数据写入之后彻底不走索引了怎么调SQL都不行。原因cmd.Prepared true会让数据库预编译这条语句并缓存执行计划后续执行直接复用计划。问题在于缓存计划一旦生成不会随数据分布变化而自动更新尤其对范围查询、日期区间的参数固定计划可能不适合不同参数值。这就是经典的计划嗅探问题的Command版本。解决对等值查询主键ID、唯一编码开启Prepared收益明显建议保留对范围查询、模糊查询、日期区间这类参数分布差异大的SQL不要开Prepared。另外数据库统计信息要定期更新存储过程里的查询也一样执行计划是老化了而不是Command对象坏了。这五条基本覆盖了从参数装配到连接生命周期的常见坑很多“时好时坏”的问题往前追溯常常是顺序、类型或取数时机在捣乱。收尾章节会给出一个能直接落地的封装习惯把那几条坑从流程上挡掉。6. 进阶把Command封装成统一入口再留一条性能自检后路6.1 一个能直接抄的Command封装函数重复写Command装配代码既啰嗦又容易漏参数我一般会把它们收进一个函数参数用数组传进来类型和方向在数组里提前定义好。Function RunCommand(conn, sql, cmdType, params) Dim cmd, p Set cmd CreateObject(ADODB.Command) cmd.ActiveConnection conn cmd.CommandText sql cmd.CommandType cmdType For Each p In params cmd.Parameters.Append cmd.CreateParameter(p(0), p(1), p(2), p(3), p(4)) Next Set RunCommand cmd.Execute() End Function调用时每个参数写成一行数组顺序和SQL里的?一致。这套封装让新来的同事不用理解Command的内部集合只要按表填空就行出问题时把数组打印出来参数顺序一眼就能看出对不对。6.2 留一条自检后路用计数器验证参数化收益封装好之后建议随手写一小段计数脚本在那张订单表上循环执行2000次同样的参数化查询记录总耗时再用等价的字符串拼接查询跑一遍对比。参数化方案的耗时通常更稳更关键的是它能处理包含单引号、百分号、换行符的脏数据而拼接方案会在第一条脏数据上直接翻车。这段验证脚本留着以后有人质疑参数化“多此一举”时直接跑给他看。我自己维护数据脚本这些年吃过参数顺序的亏也栽在输出参数读取顺序上后来发现所有坑都能归结到集合顺序和执行时机这两件事上。后来我把Command封装成统一入口把每一类操作都配上可复现的验证案例翻车的次数就明显少了。如果你也要长期维护这类脚本建议现在就拿一张测试表把上面的例子跑通跑通之后再上生产这样最稳妥。希望帮到你。本文还有配套的精品资源点击获取