企业官网建设流程全解析

简介：面向Revit2018二次开发者的API学习与工具合集，围绕帮助文档、Lookup查询程序与Addin-Manager外部加载工具三条主线，解决从查阅API到调试插件、管理外挂的实际问题，适合具备C#/.NET基础、希望扩展Revit功能的中级开发者。压缩包共170个文件、约51.65MB，以72个cs源码、12个resx与12个resources资源、9个dll程序集为主，另含chm文档、bmp/ico图标、xsl样式表、addin配置及sln/csproj工程文件，可直接打开编译研究。已有2058人学习下载。帮助文档梳理API函数、类库与方法说明及示例代码；Lookup源码可用于实时查看元素属性、类型参数与模型数据，理解读取机制；Addin-Manager则展示插件安装、卸载与切换的实现思路，配合元素、参数、视图、事务与addin-manifest等要点，便于对照实践与排错。

1. 三件套先分清：帮助文档、Snoop 工具和加载器各管什么

排查一个墙体参数为什么读不出来，通常要在三个地方来回跳：先在 Revit2018 API 的离线帮助文档里翻类成员，确认接口到底存不存在；再打开 RevitLookup 对着真实元素看它的参数表和几何树；最后用外部加载工具把刚改好的 dll 挂进当前进程试跑。这三样经常被打包放在一起，职责却完全不同——帮助文档管「有没有这个接口」，Snoop 工具管「这个模型里实际是什么值」，加载器管「我的代码怎么进去且不用重启」。分不清就会陷入反复编译、反复重启的循环，一天下来改不了几行。这份资源适合已经能写第一个 IExternalCommand、却总在「找不到方法、取不到值、改了没生效」之间打转的人；也适合把老项目往 2018 上迁、需要一套能完全离线查询的团队。下面按「查文档 → 看现场 → 挂进程 → 排错 → 串链」这条线拆开讲。

2. 把离线 API 文档用成查询台：命名空间树、成员页与示例段

离线帮助文档的价值不在于「有」，而在于能不能在断网、客户现场、内网机器上三十秒内定位到一个类或一个枚举值。两本 chm 分别是RevitAPI.chm和RevitAPIUI.chm，前者覆盖Autodesk.Revit.DB、Autodesk.Revit.Creation、Autodesk.Revit.Exceptions等，后者覆盖Autodesk.Revit.UI、Autodesk.Revit.UI.Selection、Autodesk.Revit.UI.Events。这两个命名空间的物理边界就是两条动态库的边界，写代码时引用哪一个，文档里就该翻哪一本。

2.1 chm 的三层结构和四条检索路径

打开后左侧目录是 Namespace → Class → Member 的三级树，顶部有「目录 / 索引 / 搜索 / 收藏」四个页签。目录适合按模块浏览，索引适合已知名字精确跳转，搜索适合只有模糊关键词的时候。我的习惯是：知道类名走索引，知道功能不知道类名走搜索，想确认某个命名空间下还藏着什么工具类才走目录。

一个成员页包含固定几块：语法签名（含所有重载）、参数表、返回值、异常列表、示例代码段。真正容易被忽略的是异常列表——例如FilteredElementCollector的某个重载在文档视图上会抛ArgumentException，这类信息只在异常块里写，代码里不处理就会在客户机器上炸。

提示：chm 是从压缩包解出来的，Windows 会给它打上「来自网络」的标记，表现为打开后右侧一片空白、提示「已取消该操作」。右键属性里勾选解除锁定即可，这条坑在避坑章里还会再提一次。

索引页签默认按字母排序，中文环境下输入英文全名即可。查枚举值时不要按名称硬猜，BuiltInParameter下面有上千个成员，索引里输入WALL_能看到一整批相关的，比自己拼词靠谱。

2.2 从需求反查接口：三个真实检索路径

下面这张表是我带人时最常给的对照，照着走基本能覆盖八成的检索场景。

第一个例子最能说明问题：很多人写elem.get_Parameter("底部偏移")，这种按显示名取参数的做法在中文版和英文版之间必然翻车，因为Definition.Name会随界面语言变。正确路径是先在文档里查到BuiltInParameter.WALL_BASE_OFFSET，代码里用枚举取，语言无关。这个「先查枚举再写代码」的习惯，是离线文档最大的复用价值。

第二个例子是FilteredElementCollector。类页上能看到它有三个构造重载（传 Document、传 Document 加 ElementId 集合、传 Document 加视图），方法页上能看到OfClass、OfCategory、OfType、WhereElementIsNotElementType、WhereElementIsElementType这些链式过滤器的返回值都是自身类型，所以可以连着写。示例段里通常会给出「取所有墙实例」的完整写法，抄下来改类别即可。

2.3 文档示例落到工程：引用、目标框架与最小入口

文档里的示例代码基本都假设你已经引好了两个动态库。新建类库项目后要做四件事：把目标框架设成与 Revit 2018 运行时匹配的那一档 .NET Framework、平台目标设成 x64、引用RevitAPI.dll与RevitAPIUI.dll、把这两个引用的「复制到本地」设为False。

using System; using Autodesk.Revit.Attributes; using Autodesk.Revit.DB; using Autodesk.Revit.UI; namespace DocProbe { // TransactionMode.Manual：事务由命令自己开，适合需要精确控制提交时机的场景 [Transaction(TransactionMode.Manual)] [Regeneration(RegenerationOption.Manual)] public class ProbeCommand : IExternalCommand { public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements) { UIDocument uidoc = commandData.Application.ActiveUIDocument; if (uidoc == null) { // message 会被 Revit 弹窗展示，是给用户看的，不要塞堆栈 message = "请先打开一个项目或族文档"; return Result.Failed; } Document doc = uidoc.Document; // VersionNumber 在 2018 上返回 "2018"，可用来做多版本兼容分支 TaskDialog.Show("DocProbe", string.Format("文档：{0}\n版本：{1}", doc.Title, doc.Application.VersionNumber)); return Result.Succeeded; } } }

几个参数值得单独说明。TransactionMode.Manual表示命令内部自己管理事务边界；如果写成TransactionMode.ReadOnly，代码里任何Transaction.Start都会在运行时抛异常，这在只读取参数的探查类命令里是个不错的安全带。RegenerationOption.Manual表示由代码决定何时重生成，配合事务提交使用。ref message是输出参数，返回Result.Failed时 Revit 会把它显示给用户，所以里面要写人话而不是异常堆栈。ElementSet elements用于把出错元素塞进去，让 Revit 在三维视图里高亮，调试几何相关逻辑时非常好用。

引用属性里「复制到本地」必须设False的原因，放到避坑章展开——简单说就是别把RevitAPI.dll拷进你的输出目录，否则 Revit 加载时会因为程序集标识冲突而报「无法加载程序集」。

3. RevitLookup 上手：从选不中元素到把参数、几何、关系看穿

帮助文档解决「有哪些接口」，RevitLookup 解决「这个模型里到底是什么」。它是挂在 Revit 进程里的一个查看器，把元素的内部数据结构原样摊开：属性、参数、几何、位置、与其他元素的依赖关系。这个工具最典型的使用时机，是你按文档写完了取值代码，跑出来是null或者数值离谱，需要判断到底是代码写错了还是模型里本来就没这个值。

3.1 五种入口分别能看什么

不同版本的菜单项数量和名称略有差异，但核心入口就那么几个，功能边界如下。

实际使用频率最高的是前两个。Snoop Pick Object的好处是不打断选择状态，点哪看哪；Snoop Current Selection适合一次看一批同类型元素做横向比对，比如比较三面墙的WALL_BASE_OFFSET差异。

Snoop Dependent Elements是冷门但极有用的一项。门窗在墙上开洞会生成依赖元素，做批量删除或者改类型时，如果不先摸清依赖关系，很容易触发「元素被引用无法删除」的异常。先用它把依赖树看一遍，再决定删除顺序。

3.2 看懂窗口里的四组节点：Parameters、Geometry、Location、Relationships

展开一个元素后，Parameters节点下每一个 Parameter 对象还能继续展开，里面最关键的四个字段是Definition、StorageType、Value、AsValueString。

Definition里包含Name（界面显示名）和BuiltInParameter（语言无关的枚举），后者就是你写代码要用的那个。StorageType决定你该调AsString()、AsDouble()、AsInteger()还是AsElementId()，调错方法不会报错，只会返回默认值，这是最阴的一类 bug。AsValueString返回的是界面上看到的带单位字符串，AsDouble返回的是内部单位裸值——两者差 304.8 倍这件事，几乎每个新手都踩过。

Geometry节点展开后是Solid、Face、Edge的树。想看一个构件有几个面、面的法向是什么、体积多少，都在这里。要注意有些元素的几何需要先重生成才拿得到，Snoop 里显示为空不代表代码里也是空，可能只是当前文档还没重生成。

Location节点会显示LocationPoint（点定位，如设备、家具）还是LocationCurve（线定位，如墙、管道），这是写代码时判断「怎么移动这个元素」的依据。Relationships则把宿主、被宿主、组、约束关系摊开。

3.3 把 Snoop 的观察落成代码：一次参数读取的完整链路

假设在 Snoop 里看到一面墙的WALL_BASE_OFFSET的StorageType是Double，AsValueString显示0.0000，那代码就照这个结构写。

// 收集所有墙的实例（WhereElementIsNotElementType 双保险，排除墙类型元素） FilteredElementCollector col = new FilteredElementCollector(doc) .OfCategory(BuiltInCategory.OST_Walls) .WhereElementIsNotElementType(); foreach (Element e in col) { // 按 BuiltInParameter 取，语言无关；该参数不存在时返回 null Parameter p = e.get_Parameter(BuiltInParameter.WALL_BASE_OFFSET); if (p == null || !p.HasValue) continue; // 先判断 StorageType，再决定调哪个 As 方法 if (p.StorageType != StorageType.Double) continue; double raw = p.AsDouble(); // 内部单位：英尺 double mm = UnitUtils.ConvertFromInternalUnits(raw, DisplayUnitType.DUT_MILLIMETERS); string shown = p.AsValueString(); // 界面显示值，已带格式 // 同时打印三个值，方便和 Snoop 窗口逐项对照 System.Diagnostics.Debug.WriteLine( string.Format("Id={0} raw={1} mm={2} shown={3}", e.Id.IntegerValue, raw, mm, shown)); }

这段代码对应 Snoop 窗口的三个层级：OfCategory对应你在 Snoop 里看到元素的类别；get_Parameter(BuiltInParameter...)对应 Parameters 节点下某个参数的Definition；AsDouble与AsValueString分别对应 Value 和 AsValueString 两栏。三个值一起打印出来做对照，是排查单位问题最快的办法——raw是 0，shown也是 0，那模型里本来就没设；raw是 3.28，mm是 1000，那说明代码没错，只是单位没换算。

UnitUtils.ConvertFromInternalUnits的第二个参数在 2018 上用的是DisplayUnitType枚举。这个枚举在后续版本里被新的单位体系替换掉了，所以从 2018 往上升级时，这一句是必改项之一，写的时候最好把它封装成一个私有方法，将来只改一处。

3.4 把 Snoop 看到的东西落成表：批量导出参数

单点排查靠窗口，成批比对就得落成数据。下面这段把选中元素的常用字段写成 CSV，字段选择和 Snoop 窗口里的展示顺序保持一致，导出来可以直接和窗口对照。

UIDocument uidoc = commandData.Application.ActiveUIDocument; Document doc = uidoc.Document; ICollection<ElementId> ids = uidoc.Selection.GetElementIds(); if (ids.Count == 0) { message = "先选中若干元素"; return Result.Failed; } StringBuilder sb = new StringBuilder(); // 表头与 Snoop 窗口的展示字段对齐，方便逐列核对 sb.AppendLine("ElementId,Category,FamilyName,TypeName,ParamName,BuiltInParameter,StorageType,ValueString"); foreach (ElementId id in ids) { Element e = doc.GetElement(id); ElementType et = doc.GetElement(e.GetTypeId()) as ElementType; foreach (Parameter p in e.Parameters) { // 只导出本地参数，共享参数另起一列更清晰 if (!p.Definition.IsShared && p.Definition is InternalDefinition idef) { string bip = idef.BuiltInParameter.ToString(); sb.AppendLine(string.Join(",", id.IntegerValue, e.Category?.Name ?? "", et?.FamilyName ?? "", et?.Name ?? "", p.Definition.Name, bip == "INVALID" ? "" : bip, p.StorageType.ToString(), (p.AsValueString() ?? "").Replace(",", "，"))); // 防止值里带逗号破坏列 } } } File.WriteAllText(@"C:\Temp\param-dump.csv", sb.ToString(), Encoding.UTF8);

关键是InternalDefinition.BuiltInParameter这一列：导出后你就能看到「界面上的『底部偏移』对应WALL_BASE_OFFSET」这种映射关系，下次写代码不用再开 Snoop 猜。注意 CSV 里值字段可能自带逗号，做一次替换是最省事的规避方式。doc.GetElement(e.GetTypeId())拿到类型元素再取FamilyName和Name，这是族名与类型名的标准取法。

4. 外部加载工具与 .addin 清单：不重启 Revit 换 dll 的做法

写 Revit 插件最耗时间的不是写代码，是「改一行、关 Revit、编译、开 Revit、打开模型、点按钮」这个循环。外部加载工具存在的唯一目的就是打断这个循环。它有两种形态：一种是给 Revit 注册清单文件，让它在启动时扫描；另一种是加载器在运行期直接把 dll 挂进当前进程。两者常常混在一个工具包里，得先分清。

4.1 持久注册与临时挂载：两条路的边界

清单文件是持久化的，Revit 每次启动都会扫描固定几个目录下的.addin文件，读到就加载，程序集路径失效就在启动日志里报错。这条路适合已经稳定的插件，用户装一次就一直在。

加载器是运行期的，典型使用方式是：在 Revit 里点开加载器面板，选择一个 dll 或者一个.addin文件，它当场把程序集载入并注册命令，功能区里立刻出现按钮。好处是不用重启，坏处是每次重启 Revit 都要重新挂一遍，而且卸载不彻底——同一个 dll 被替换后重新加载，可能因为旧的程序集还在内存里而拿到旧版本。

一个稳妥的组合是：开发阶段用加载器，功能稳定后再写清单文件；或者干脆把输出目录固定下来，清单里写绝对路径，需要更新时关掉 Revit 重新编译。

注意：加载器「不用重启」这句话有个前提——你替换的是还没被加载过的 dll。如果一个 dll 已经被载入进程，.NET 会锁住这个文件，编译时链接器写不进去，报的是「另一个程序正在使用此文件」。这时要么关 Revit，要么把输出路径改成带时间戳的新目录。

4.2 .addin 清单的字段与两个注册目录

清单是一个 XML 文件，扩展名固定.addin，编码建议 UTF-8。最小可用版本如下。

<?xml version="1.0" encoding="utf-8"?> <RevitAddIns> <AddIn Type="Command"> <!-- 绝对路径最稳，相对路径的基准目录在不同版本上表现不一致 --> <Assembly>C:\Dev\DocProbe\bin\Debug\DocProbe.dll</Assembly> <!-- 必须是完整命名空间 + 类名，大小写敏感 --> <FullClassName>DocProbe.ProbeCommand</FullClassName> <!-- 全局唯一，用于 Revit 内部标识这个插件 --> <ClientId>a1b2c3d4-1111-2222-3333-444455556666</ClientId> <Text>参数探查</Text> <VendorId>DEMO</VendorId> <VendorDescription>内部调试用</VendorDescription> <!-- 没有活动文档时隐藏按钮，避免用户在没有模型时误点 --> <VisibilityMode>NotVisibleWhenNoActiveDocument</VisibilityMode> </AddIn> </RevitAddIns>

字段里最容易写错的是FullClassName。它不是 dll 名，也不是项目名，而是「命名空间.类名」，且要写完整个命名空间层级。ClientId用 GUID，重复了会导致后加载的覆盖先加载的。Type有三个取值：Command对应IExternalCommand，Application对应IExternalApplication（有界面，可建功能区面板），DBApplication对应IExternalDBApplication（无界面，做数据层事件）。绝大多数插件用的是前两种。

注册目录分机器级和用户级两处，结构一致，都是Revit\Addins\2018这样的版本号子目录：

• 机器级在%ProgramData%下厂商目录里的Revit\Addins\2018，对所有用户生效，写入需要管理员权限；
• 用户级在%AppData%下同样结构的Revit\Addins\2018，只对当前用户生效，不需要提权。

调试期间我一般用用户级，避免污染别人机器；交付时按客户要求选机器级。两处都放同名清单会加载两次，表现为功能区出现两个一样的按钮，这个现象很好认。

4.3 一个带功能区按钮的 ExternalApplication

命令只能从「附加模块 → 外部工具」菜单里点，体验差。加一个IExternalApplication建自己的面板，是插件的基本形态。

using Autodesk.Revit.UI; namespace DocProbe { public class AppEntry : IExternalApplication { public Result OnStartup(UIControlledApplication application) { // 面板名重复会抛异常，团队协作时统一命名规范 RibbonPanel panel = application.CreateRibbonPanel("调试工具"); PushButtonData data = new PushButtonData( "btnProbe", // 内部名，唯一 "参数探查", // 按钮显示文字 @"C:\Dev\DocProbe\bin\Debug\DocProbe.dll", "DocProbe.ProbeCommand"); // 命令的完整类名 data.ToolTip = "导出选中元素的参数到 CSV"; PushButton btn = panel.AddItem(data) as PushButton; return Result.Succeeded; } // 关闭时不清理功能区，Revit 会自己回收 public Result OnShutdown(UIControlledApplication application) => Result.Succeeded; } }

PushButtonData的第二个参数是按钮文字，第三个是程序集路径，第四个是命令类全名——这三者里任何一处和实际不符，按钮会出现但点击无反应，或者启动时直接抛ArgumentException。返回值Result.Succeeded表示启动成功，如果这里返回Failed，整个应用不加载但也不会给你明显报错，只在日志里留痕，这是排查时容易漏的一环。

对应的清单文件Type要改成Application，FullClassName指向DocProbe.AppEntry。命令本身的清单可以保留也可以删掉，因为通过功能区按钮已经能调到命令了。

4.4 调试：附加进程与启动外部程序

最省事的调试配置是把项目属性的「调试」页设成启动外部程序，指向 Revit 安装目录下的Revit.exe，工作目录留空。这样按 F5 就直接起一个 Revit 实例，断点能命中。

如果不想每次都重开 Revit，就用「调试 → 附加到进程」，在进程列表里找Revit.exe。注意勾选「显示所有用户的进程」，否则在某些权限配置下看不到。附加之后断点显示为空心圆，说明符号没加载或者代码版本对不上，检查一下 dll 是不是刚编译的那一份。

另一个免费的黑匣子是日志文件。Revit 每次运行都会在%LOCALAPPDATA%下的Revit\Autodesk Revit 2018\Journals目录里写日志，插件加载失败的完整堆栈通常就在里面。用户反馈「装了没反应」的时候，先要这个文件，比远程连过去看快得多。

5. 避坑：六条血泪排查记录

下面这些是按「现象 → 原因 → 解决」整理的真实翻车记录，基本覆盖了插件从编译到运行的完整链路。按发生频率排序。

5.1 加载类：清单写对却不出按钮

现象：清单文件放进了Revit\Addins\2018，Revit 重启后功能区里什么都没有，也没有任何弹窗提示。

原因：三种可能各占三分之一。一是目录层级错了，比如把清单放到了Revit\Addins而不是Revit\Addins\2018；二是FullClassName少了命名空间前缀，比如写成ProbeCommand而不是DocProbe.ProbeCommand；三是Assembly用了相对路径，Revit 的解析基准目录和你以为的不一样。

解决：先把Assembly改成绝对路径，这一步能排除大部分问题；然后用文本编辑器打开 dll 所在的输出目录，确认文件名和清单里一字不差；最后打开当次运行的日志文件，搜addin关键字，加载失败的条目会明确写出是路径找不到还是类型找不到。

现象：Revit 启动时弹窗「无法加载程序集或文件」。

原因：输出目录里混进了RevitAPI.dll和RevitAPIUI.dll。这两个库 Revit 进程自己已经加载了一份，你拷进去的副本版本标识不一致，加载器解析引用时就冲突。

解决：在引用的属性面板里把这两个的「复制到本地」设为False，然后手动删掉bin目录里的这两个文件，重新编译。这条坑几乎人人踩一次，记住「Revit 的两个动态库永远不从你的输出目录走」就够了。

5.2 运行时类：改了代码没反应、事务报错

现象：改了代码，重新生成显示成功，切回 Revit 点按钮，行为还是旧的。

原因：dll 被 Revit 进程锁住了，编译其实失败了，但 IDE 的增量编译有时不会把错误顶到最前面；或者你生成到了另一个配置目录（Debug/Release），而清单指向的是老路径。

解决：先看输出目录里 dll 的修改时间是不是刚刚，时间不对就说明没写进去；确认配置是 Debug 后，关闭 Revit 再编译。用加载器的话，先执行卸载再重新加载，否则拿到的是内存里的旧程序集。

现象：点击按钮弹出InvalidOperationException: Attempt to modify the document outside of a transaction。

原因：修改模型的操作没有包在事务里，或者事务Start了但异常路径上没走到Commit，又或者在一个只读的文档（比如链接进来的模型）上做修改。

解决：把所有写操作放进using (Transaction t = new Transaction(doc, "名称"))，Commit放在using块末尾的正常路径上；入口处先判断doc.IsReadOnly和doc.IsModifiable，不满足就直接返回Result.Failed并给出提示。

现象：批量处理到某个元素时抛异常，前面已提交的修改回不去了。

原因：把整个循环包在一个大事务里，中途抛异常，using释放时事务回滚，但如果你在循环里多次Commit，前面几次已经落库。

解决：要么整批一个事务、失败全回滚，要么每个元素一个事务、失败跳过继续。前者适合数据一致性要求高的场景，后者适合批量修补。选哪种在动手前就想清楚，别写到一半再改。

5.3 数据类：数值差 304.8 倍、chm 一片空白

现象：从参数里读出来的值是 3.28，可界面上明明显示 1000。

原因：Revit 内部长度单位是英尺，AsDouble()返回的是裸的内部值，AsValueString()返回的才是带单位格式的显示值。3.28 英尺就是 1000 毫米。

解决：所有AsDouble()的结果在参与业务计算前先过一遍UnitUtils.ConvertFromInternalUnits，明确指定目标单位。反过来写入时用ConvertToInternalUnits。写代码时养成「看到 AsDouble 就想到换算」的条件反射，比事后排查便宜得多。

现象：从压缩包里解出来的帮助文档，双击打开右侧一片空白，顶部提示「已取消该操作」。

原因：Windows 对来自网络的文件加了标记，chm 的 HTML 内容被安全策略拦住了。

解决：右键文件属性，在常规页底部勾选「解除锁定」再确定。文件多的话用 PowerShell 批量处理：

# 递归解除指定目录下所有 chm 的网络锁定标记 Get-ChildItem -Path "D:\SDK\docs" -Filter *.chm -Recurse | Unblock-File

Unblock-File做的就是删掉备用数据流里的标记，执行完重新打开即可。这条和代码无关，但在离线环境里卡住的人不少。

6. 进阶：把三件套串成一条可复用的验证链

单个工具用得再熟，效率提升也有限；真正的提速来自把它们串成一条固定流程。我现在的习惯是：任何新需求，先按下面六步走一遍，能省掉大量往返。

这条链里最容易被跳过的是第 5 步。很多人看到代码跑出数字就以为成了，结果交付后客户说「数值不对」，回头查半天才发现是单位问题。把「代码输出必须和 Snoop 显示值逐项对齐」当成硬性关卡，能挡掉一大半返工。

再补一个具体技巧：把 Snoop 的观察结果和文档里的枚举名做成一张自己的对照表，放在代码仓库的docs目录里。比如「墙的底部偏移 =WALL_BASE_OFFSET」「房间的面积 =ROOM_AREA」，日积月累就是一份比官方文档更贴合自己业务的索引。团队成员查表比查 chm 快，也比在群里问人靠谱。

还有一个常被忽略的验证手段：在命令里临时打印doc.Application.VersionNumber和doc.Application.VersionBuild。同一份 dll 被不同版本加载时，行为差异往往就出在这里，尤其是在多版本共存的机器上做测试的时候。把这两行放在命令入口，日志里就有了版本上下文，事后追查省很多口舌。

说个我自己的教训。早些年做一个批量改参数的插件，本地跑得好好的，到客户机器上就报「参数不存在」。当时第一反应是模型问题，折腾了一下午，最后发现客户用的是英文版界面，我代码里有一处偷懒用了get_Parameter("注释")按显示名取参数。从那以后我每次写参数相关的代码，都强制走一遍「Snoop 确认BuiltInParameter枚举名 → 代码里只用枚举 → 输出值和 Snoop 显示值对一遍」这三步，再没在这类问题上翻过车。这套流程看着慢，实际比返工快得多。希望帮到你。

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