企业官网建设流程全解析

简介：PowerBuilder 9.0 安装包及配套说明面向使用 PB 进行客户端开发、课程实验与上机考试的人员，重点解决旧版开发环境在 Win10 上的获取与搭建问题。压缩包共 69 个文件、约 282.22MB，以 cab、exe、ini、ex_ 等安装镜像与配置文件为主体，并含 txt 使用说明、docx 安装说明与函数资料、sql 建库脚本、zip 组件包及 bmp、ico 等界面资源，兼顾安装部署与后续查阅。已有 2454 人学习下载，说明其在 PB9 环境配置场景中具有一定参考价值。读者可从中获得较完整的安装介质、中文安装说明、PB 常用函数整理、PowerBuilder9.0 教程文档以及 ASAnywhere、SoapClient 等相关组件，便于对照检查安装项、补齐实验环境，并在开发练习中快速查找函数用法和数据库脚本，减少旧版本软件部署时的资料缺失与反复试错。

1. 老项目维护现场：为什么还要找 PowerBuilder 9.0 安装包

上个月有人把一套跑了十几年的生产管理系统源码丢过来，PBL 文件、DataWindow 的 SRD 导出、一堆 .ini 配置，唯一的要求是“先把环境跑起来看看”。这类场景里，搜索 PowerBuilder 9.0 安装包下载 的人基本都不是想学新东西，而是手上有一份只能在 PB9 下编译的老工程需要让程序运行起来：要么接手遗留系统的二次开发，要么做数据迁移前的字段核对，要么给客户演示一个已经停产多年的模块。这套安装包本质上是一个 32 位 C/S 快速开发工具的完整运行环境，包含 IDE、DataWindow 引擎、示例库和自带的数据库组件。它解决的不是“新项目选型”问题，而是“老代码怎么在新机器上重新跑起来”的问题。适合的人群很明确：需要维护 PB6/PB7/PB8/PB9 存量工程的开发者、要复现客户现场问题的实施人员，以及被派去接手老系统的接盘者。

2. 先认清这套工具：PowerBuilder 9.0 的定位与安装前的依赖盘点

2.1 DataWindow 是这套工具的核心

PowerBuilder 的核心价值几乎全部集中在 DataWindow 这一个对象上。它不是普通意义上的表格控件，而是把“取数 SQL、显示样式、编辑校验、打印格式、导出规则”揉进一个可复用对象里的容器。一个 DataWindow 可以定义检索参数、设置 update 属性后自动生成 INSERT/UPDATE/DELETE 语句、按列做下拉数据窗口、按分组做汇总带。放到今天看，这套思路和低代码平台的数据绑定层是同一套逻辑，只不过 PB9 在 2003 年就把这件事做完了，而且做得足够稳定，所以大量制造、电力、医疗、仓储类系统至今仍在跑。

理解这一点对安装很重要：PB9 不是装完 IDE 就能用，它的运行链路分成三段——IDE 本体负责编辑和编译，DataWindow 引擎（一组独立 DLL）负责在运行时把数据画到窗口上，数据库接口 DLL 负责和具体数据库通信。这三段在安装包中属于不同组件，Typical 安装未必全给你装上。很多人装完发现“能打开工程但不能预览数据窗口”，问题往往出在第二段或第三段缺失，而不是安装失败。

还有一个现实约束：PB9 是纯 32 位程序。在 64 位系统上它照样能跑，但它调用的 ODBC 驱动、注册的 ActiveX 控件、读写的注册表分支全部走 32 位通道。这一条会在第 4 章和第 5 章反复出现，是绝大部分“连不上数据库”问题的根因。装之前先把这条记在心里，后面省一半时间。

2.2 安装包里到底有什么：目录结构与组件取舍

拿到手的安装包通常是镜像文件或者一堆 disk1、disk2 目录，根下有一个 setup.exe。不同渠道打包的目录名不完全一样，但组件构成基本一致，我按“装不装”给一张表：

安装类型一般给三个选项：Typical（典型）、Compact（最小）、Custom（自定义）。我的习惯是一律选 Custom，然后把示例代码和联机手册勾上，建模工具取消。理由很实际：Typical 在部分打包版本里会跳过示例库，而排查 DataWindow 问题时，官方示例是最快的对照物——同样一个下拉数据窗口，示例里能跑、你的不能跑，问题就锁定在你的配置上，不用再怀疑环境。

提示：安装包内通常带一份安装说明文档，里面有序列号信息和组件兼容说明，装之前先翻一遍，别等到向导要求输入时再回头找。

另外要留意镜像里的runtime或Shared一类目录，那是运行时库的原始位置。后面第 6 章做部署时会用到，现在先记住它在哪。

2.3 装机前的环境核对清单

环境不对，后面全是玄学。下面这几项必须在运行 setup.exe 之前确认，我一般写成一张核对单，逐项打勾：

第一是操作系统版本。PB9 的原生支持范围是老一代 Windows，在较新的系统上安装和运行都需要额外处理。实践中最稳的组合是 32 位 Windows 7 虚拟机，或者 64 位系统加兼容模式。如果你只是想跑起来看代码，虚拟机方案能省掉 80% 的兼容性折腾；如果必须装在物理机上给客户演示，那就做好第 3.3 节那套兼容性设置。

第二是路径。安装目录必须是纯英文、无空格、层级短，比如D:\PB9。InstallShield 这类老安装器在解压临时文件时对中文路径处理很差，路径里带中文或空格，轻则组件注册失败，重则安装到 90% 回滚。

第三是权限与杀毒软件。安装过程要向系统目录写 DLL、注册组件、写注册表，全程需要管理员权限；同时实时防护很容易把老版本的注册动作判成可疑行为直接拦掉，表现为“安装到最后一步失败但没报错”。装之前临时关闭实时防护，装完再开。

第四是 32 位 ODBC 环境。64 位系统上默认打开的是 64 位 ODBC 管理器，配出来的 DSN 对 PB9 完全不可见。要配数据源必须显式启动C:\Windows\SysWOW64\odbcad32.exe。这一条单独拎出来说，是因为它造成的困惑最多，第 4 章会展开。

第五是磁盘和临时目录。老安装器解压会占用系统临时目录，剩余空间建议留 5 GB 以上，并且确认当前账户对%TEMP%有写权限。有些公司机器做了组策略限制，临时目录只读，安装会莫名其妙卡在复制阶段。

装之前跑一段小脚本把环境信息打出来，比事后猜要快得多：

@echo off REM 装机前环境快照：系统版本、位数、临时目录、关键运行库 ver wmic os get Caption,Version,OSArchitecture /value echo ---- TEMP ---- echo %TEMP% if exist "%TEMP%" (echo TEMP 可访问) else (echo TEMP 不可访问，检查权限) echo ---- 32 位 ODBC ---- if exist "C:\Windows\SysWOW64\odbcad32.exe" ( echo 32 位 ODBC 管理器存在 ) else ( echo 未找到 32 位 ODBC 管理器，可能不是 64 位系统 ) echo ---- 磁盘剩余 ---- wmic logicaldisk where "DeviceID='D:'" get FreeSpace /value pause

这段脚本做四件事：ver和wmic os确认系统版本与位数，决定要不要走兼容模式；打印%TEMP%并做存在性判断，提前发现权限坑；探测SysWOW64下的 ODBC 管理器，确认 32 位数据源通道可用；最后看一眼目标盘剩余空间。wmic在新系统上可能被标记为弃用但通常仍可调用，真调不到就换成systeminfo看系统信息，不影响判断。脚本里没有写死安装盘符之外的东西，改DeviceID就能查别的盘。

3. 安装全过程：从挂载镜像到 IDE 第一次成功启动

3.1 解压与目录规划

镜像文件先挂载或者用解压工具展开到一个本地目录，不要在压缩包里直接双击 setup.exe。原因很直接：安装器中途需要回读同目录下的 cab 包和数据文件，压缩软件的虚拟盘符在长路径下经常读不到，表现是“安装到某个组件时提示找不到源文件”。

展开目标定在D:\pb9setup，装完可以删。安装目标定在D:\PB9，两个目录分开，避免安装器把自己的临时文件和目标文件混在一起。目录层级控制在两级以内，整个路径长度不要超过 60 个字符——老安装器对长路径的支持有限，尤其是组件注册阶段会拼接出很长的命令行。

规划好之后，右键 setup.exe，选“以管理员身份运行”。这一步不能省，普通权限下安装器会在注册组件阶段静默失败，最后的“完成”页照样弹出来，让你以为装成功了。

3.2 安装向导逐页说明与勾选策略

向导的页面顺序在不同打包版本里略有差异，但关键决策点就那么几个，按顺序过一遍：

第一页欢迎界面，直接下一步。许可协议页选接受。用户信息页会要求填姓名、公司名和序列号，序列号在安装包的说明文档里，姓名和公司名随便填，只影响注册表里的注册信息，不影响功能。

接下来是安装目录页，填D:\PB9。有的版本会单独问一次共享组件目录（Shared），默认在系统盘，保持默认即可，这个目录放的是运行时公共库，多个组件共用，改到奇怪的路径反而容易出问题。

安装类型页选 Custom。进入组件选择后，按 2.2 节的表勾选：主程序、示例代码、联机手册、命令行编译工具必选；自带数据库组件在需要单机跑示例时勾上；建模工具和报表工具按需。

程序文件夹页保持默认，方便开始菜单里找。之后进入复制阶段，这一步耗时最长，几分钟到十几分钟都正常，中途不要点取消，也不要切到别的窗口去操作文件——安装器在注册组件时对文件占用很敏感。

复制完成后通常提示是否重启。我的做法是重启一次，让注册表和环境变量变更彻底生效，然后再启动 IDE。省这一步的后果是第一次启动可能报找不到运行时库，然后又得重装一遍，不值得。

3.3 兼容性设置：让 IDE 在新系统上稳定运行

装完不等于能跑。新系统上第一次双击 pb.exe，常见三种结果：正常打开、闪一下就退、报缺少某个 90 后缀的 DLL。后两种都属于兼容性问题，按下面的顺序处理。

先给主程序做兼容性设置：右键 pb.exe → 属性 → 兼容性 → 勾选“以兼容模式运行这个程序”，选一个较老的 Windows 版本；再勾选“以管理员身份运行此程序”；最后点“更改高 DPI 设置”，勾选“替代高 DPI 缩放行为”，缩放执行选“应用程序”。最后这一项解决的是界面模糊和控件错位，PB9 的窗口布局是按固定像素设计的，系统缩放一改，DataWindow 设计器里的标尺就全乱了。

如果启动时提示缺少 DLL，先确认文件是不是真的在安装目录里。装完被杀软隔离掉一两个 DLL 是很常见的事，去隔离区恢复并加白名单即可。确认文件存在但仍然报错，就把安装目录和共享组件目录都加进系统 PATH：

@echo off REM 把 PB9 主目录和共享运行库目录加入当前用户 PATH（永久生效） setx PATH "%PATH%;D:\PB9;D:\PB9\Shared\PowerBuilder" /M echo 已写入系统 PATH，需要重开命令行窗口生效

setx写的是持久化环境变量，/M表示写系统级而不是用户级，需要管理员权限。这里把两个目录都加进去，是因为运行时库有可能装在共享目录而不是主目录，具体位置取决于安装时的选择。写完必须重开一个命令行窗口或者重登录，旧窗口读的还是旧 PATH。如果不想动系统级变量，把/M去掉改成用户级更安全。

还有一个容易被忽略的点：数据执行保护。老版本 IDE 里有自修改代码的加载方式，在新系统上可能被 DEP 拦下，表现是启动瞬间崩溃。如果前面几步都做了还是闪退，可以把 pb.exe 加入 DEP 例外列表，用系统的高级系统设置里“数据执行保护”页签手工添加，不要全局关闭 DEP。

3.4 首次启动与完整性验证

IDE 打开后先别急着导工程，做三件事验证安装是否完整。

第一，新建一个 Workspace 和一个 Target，类型选应用，随便起个名字。这一步验证的是工程模板和编译链是否可用。

第二，打开安装目录下的示例 PBL，随便找一个带 DataWindow 的窗口跑起来。这一步验证 DataWindow 引擎和运行时库是否齐全——如果示例能跑而你的工程不能跑，问题在你的工程配置，不在安装。

第三，新建一个 DataWindow，数据源选 SQL Select，随便连一个库或者用示例库，预览一下。预览成功说明数据库接口层是通的。

再补一个命令行层面的检查，用脚本把关键文件挨个点名，比在资源管理器里翻要靠谱：

@echo off set PB_HOME=D:\PB9 REM 逐个检查核心文件，缺失的会打 MISS for %%f in (pb.exe pbvm90.dll pbdwe90.dll pbodb90.dll libjcc.dll orcascr9.exe) do ( if exist "%PB_HOME%\%%f" ( echo [OK] %%f ) else ( echo [MISS] %%f -- 检查是否被杀软隔离或组件未安装 ) ) echo ---- 共享运行库目录 ---- if exist "%PB_HOME%\Shared\PowerBuilder" ( dir /b "%PB_HOME%\Shared\PowerBuilder\*.dll" | find /c ".dll" ) else ( echo 共享目录不存在，确认安装时是否选择了自定义路径 ) pause

脚本里的文件清单对应三个层次：pb.exe是 IDE 本体，pbvm90.dll是虚拟机（所有 PB 程序都靠它解释执行），pbdwe90.dll是 DataWindow 引擎，pbodb90.dll是 ODBC 数据库接口，libjcc.dll是 Java 组件容器（很多老工程用了第三方控件会依赖它），orcascr9.exe是命令行编译工具。任何一个打 MISS，都说明安装不完整或者文件被隔离，别急着往下走，先补齐。最后那段统计共享目录下 DLL 数量，正常应该是两位数，如果只有个位数，说明共享组件那一步没装全。

注意：不同打包版本里命令行编译工具的文件名可能带不同后缀，如果orcascr9.exe打 MISS，去安装目录下找名字里带 orca 的可执行文件，把脚本里的名字换掉即可。

4. 打通数据库链路：32 位 ODBC、DB Profile 与 DataWindow 最小验证

4.1 32 位 ODBC 数据源怎么配

这一步是新手最容易翻车的地方，先把结论说清楚：PB9 是 32 位程序，它只能看见 32 位 ODBC 数据源。在 64 位系统上从控制面板点进去的“ODBC 数据源”是 64 位的，你在里面配的 DSN，PB9 一个都看不到，连接时报的错还是“未找到数据源名称”，让人误以为是驱动没装。

正确做法是显式运行 32 位管理器：

@echo off REM 打开 32 位 ODBC 数据源管理器（64 位系统上必须走这个路径） start "" "C:\Windows\SysWOW64\odbcad32.exe"

SysWOW64这个名字容易误导，它存放的是 32 位组件；真正放 64 位组件的是System32。这一点记反了会一直配不对。

管理器打开后选“用户 DSN”或“系统 DSN”。区别是用户 DSN 只对当前账户可见，系统 DSN 对所有账户和服务可见。给客户部署时一律用系统 DSN，否则换个账户登录就找不到数据源。点添加，选对应数据库的 32 位驱动，填名称、服务器地址、认证方式，最后点“测试连接”确认通。

驱动这里有个坑：如果系统里只装了 64 位驱动，32 位管理器里根本看不到那个选项。解决办法是单独安装一份 32 位驱动，版本尽量和数据库服务端匹配。老系统常见的组合是配一个老版本的 SQL Server 驱动，新驱动反而不兼容旧的认证方式。

4.2 DB Profile 与连接脚本

ODBC 配好之后，PB 里还要建一个 DB Profile，它是 IDE 内部使用的连接配置，用于数据窗口画板里直接预览数据。入口在数据库画板上，右键 ODBC 节点新建 profile，选刚才配的 DSN，填用户名密码，点 Test Connection。这一步通了，画板里设计 DataWindow 就不用来回切工具了。

但 DB Profile 只服务于 IDE，程序运行时用的是应用对象里的事务对象。PB 的标准做法是用全局事务对象 SQLCA，在应用对象的 Open 事件里赋值并连接：

// 应用对象 Open 事件：初始化事务对象并连接数据库 SQLCA.DBMS = "ODBC" SQLCA.AutoCommit = False SQLCA.DBParm = "ConnectString='DSN=pb9_demo;UID=app_user;PWD=******'" CONNECT USING SQLCA; IF SQLCA.SQLCode <> 0 THEN // 连接失败：把错误码和错误文本一起弹出来，方便现场定位 MessageBox("数据库连接失败", & "SQLCode = " + String(SQLCA.SQLCode) + "~r~n" + SQLCA.SQLErrText) HALT CLOSE END IF

逐项说明。DBMS决定用哪个数据库接口 DLL，取值ODBC走通用 ODBC 通道，也可以写OLE DB、MSS、ORA这类专用接口，区别是专用接口性能更好但需要额外部署对应的接口 DLL，维护老项目时用 ODBC 最省事，因为只依赖系统和驱动。AutoCommit设成 False 表示由程序自己控制事务提交，这是业务系统的常规做法，配合后面的COMMIT USING SQLCA;使用。DBParm是拼串，ODBC 通道下用ConnectString传完整的连接串，注意引号嵌套：外层双引号、内层单引号，密码里有分号时要做转义处理。

错误处理这两行值得多说一句。很多人只写CONNECT不判断SQLCode，连接失败后程序继续往下跑，然后在某个 DataWindow 上抛一个莫名其妙的错误，排查方向全跑偏。把SQLCode和SQLErrText在入口处就打出来，是这类老系统里性价比最高的一个习惯。HALT CLOSE会触发应用的 Close 事件做资源清理，比直接HALT干净。

程序退出时记得断开：

// 应用对象 Close 事件：释放数据库连接 DISCONNECT USING SQLCA;

4.3 DataWindow 最小验证：从 SQL 到 Retrieve

数据库通了之后，用一个最小的 DataWindow 验证整条链路。步骤是这样的：新建 DataWindow，展示样式选 Grid（表格，最适合排查），数据源选 SQL Select，选中目标表，勾选需要的列，如果要做条件检索就在 Where 里加条件并把条件设成检索参数，然后返回画板，点预览。预览能出数据，说明从 ODBC 到 DataWindow 引擎全链路没问题。

运行期的检索代码：

// 窗口 Open 事件：把事务对象挂到数据窗口上 dw_1.SetTransObject(SQLCA) // 带检索参数时：dw_1.Retrieve(ls_dept_id) long ll_rows ll_rows = dw_1.Retrieve() IF ll_rows < 0 THEN // 负数表示检索失败，具体原因看 SQLCode 和 SQLErrText MessageBox("检索失败", & "SQLCode = " + String(SQLCA.SQLCode) + "~r~n" + SQLCA.SQLErrText) END IF

SetTransObject是把全局事务对象绑定给数据窗口，绑定之后 DataWindow 自己负责发 SQL、取结果集、维护缓冲区，这也是 PB 开发效率高的原因——业务代码里几乎看不到手写的游标循环。返回值ll_rows是检索到的行数，-1一般表示 SQL 执行失败，0表示执行成功但没数据，这两种情况在业务上处理方式完全不同，别混在一起判断。

常见错误码对照，排错时先看这个再去看日志：

这张表覆盖了日常九成以上的情况。-1是最含糊的，一定要看SQLErrText，里面通常直接写明是“无效的对象名”还是“登录失败”，比猜快得多。

5. 避坑清单：装不上、打不开、连不上的五类现场排查

5.1 安装阶段的三类翻车

现象一：安装进度条走到注册组件阶段卡死，或者弹出 1603 安装失败。原因基本是两个叠加：权限不足，加上实时防护拦截了 DLL 注册动作。老安装器注册组件时会调用系统接口写注册表，杀软的主动防御会把它当成可疑写入直接掐断，安装器收不到返回就卡住。解决办法：用本地管理员账户登录（不是域账户加上去的管理员组），退出所有安全软件，重新运行 setup.exe 并右键以管理员身份启动。如果 1603 反复出现，到%TEMP%下找安装日志，最后几行会写明是哪个组件注册失败，对着文件单独手工注册也能补救。

现象二：安装到快结束时整体回滚，提示“安装被中断”。八成是路径问题。中文目录、带空格的目录、层级过深的目录，都会让解压和文件复制失败。另外系统临时目录权限不足也会导致同样的表现，尤其是被组策略限制过的办公机器。解决办法：安装包解压到D:\pb9setup，目标目录定D:\PB9，先确认%TEMP%可写，再重新安装。已经失败过一次的，卸载残留目录后重来，别在原目录上覆盖装。

现象三：装完了，开始菜单里只有主程序，示例库和联机手册不见踪影。原因是安装类型选了 Typical，部分打包版本在典型安装下不包含示例。这个不算失败，但很影响后续排查，因为没有对照物。解决办法：重新运行 setup.exe，安装向导会识别已安装实例并提供“修改”选项，进去把示例代码和联机手册勾上补装即可，不需要整体重装。

5.2 运行与连接阶段的两类翻车

现象四：双击 pb.exe 没有任何反应，或者弹一下窗口就消失。先看安装目录里那几个 90 后缀的 DLL 还在不在，杀软隔离是最常见原因，恢复并加白名单即可。文件都在的话，检查环境变量 PATH 有没有包含安装目录和共享目录，缺了会导致加载失败。再不行就是 DEP 拦截或者兼容模式没设，按 3.3 节补上。有一个判断技巧：从命令行窗口里启动 pb.exe，报错信息会直接打在控制台上，比双击快得多。

现象五：PB 里测试连接成功，程序跑起来连不上；或者 ODBC 里明明配了数据源，PB 的 DB Profile 里就是看不到。这个问题在第 4 章讲过根因——配到 64 位 ODBC 里去了。表现很典型：64 位管理器里数据源列得整整齐齐，PB 里一个都看不见。解决办法是用SysWOW64\odbcad32.exe打开 32 位管理器重新配一遍，配完重启 IDE。还有一种变体是 DSN 名字对但认证失败，检查是不是在系统 DSN 和用户 DSN 之间搞混了，以及数据库账号在目标库上有没有登录权限。

现象六：DataWindow 预览里中文显示成方块或者乱码。这属于编码层面的问题，不是安装问题。老版本对字符集的处理依赖系统区域设置和字体，系统区域不是中文时，即使装了中文字体也可能显示异常。解决办法：确认系统区域设置里的非 Unicode 程序语言是中文，DataWindow 里显式指定中文字体（比如宋体、微软雅黑），涉及从外部文件导入数据的场景，还要在读写时统一编码。这类问题不影响功能，但影响交付观感，演示前一定要过一遍。

6. 进阶落地：运行时打包清单与干净机器复现

装好 IDE 只是自己能用，真正要交付的是“在一台没装过 PB 的机器上把程序跑起来”。这件事的关键在于运行时文件清单，漏一个 DLL 的表现通常是程序启动即退，没有任何提示，非常难查。

PB 程序的运行时依赖分三层：虚拟机层pbvm90.dll是所有 PB 程序的基础；引擎层pbdwe90.dll负责 DataWindow 的绘制和数据缓冲；接口层按你用的数据库通道选，走 ODBC 就带pbodb90.dll，走专用接口就带对应的接口 DLL。此外，用了 RichText、Java 组件、图形控件的老工程还要额外带pbrtc90.dll、libjcc.dll这些。我给一张部署清单，按需取：

打包脚本我一般这么写，从安装目录把文件拷到发布目录，再整体压缩发给现场：

@echo off set SRC=D:\PB9 set DST=D:\release\app_runtime if not exist "%DST%" mkdir "%DST%" REM 基础运行时：虚拟机 + DataWindow 引擎 + ODBC 接口 copy /y "%SRC%\pbvm90.dll" "%DST%\" >nul copy /y "%SRC%\pbdwe90.dll" "%DST%\" >nul copy /y "%SRC%\pbodb90.dll" "%DST%\" >nul copy /y "%SRC%\libjcc.dll" "%DST%\" >nul REM 把编译好的 exe 和 pbd 一起放进去 copy /y "D:\build\app.exe" "%DST%\" >nul copy /y "D:\build\app.pbd" "%DST%\" >nul echo 发布目录内容： dir /b "%DST%" pause

SRC指向本机安装目录，DST是发布目录，copy /y覆盖已有文件不提示，>nul屏蔽复制成功提示让输出干净。实际项目里最好再加一步把数据库客户端库一起拷进去，或者干脆在目标机器上单独装一遍客户端。发到现场前，一定要在一台干净虚拟机上做一次冷启动验证：拷过去、双击 exe、登录、打开一个带数据的窗口、做一次查询和一次保存。这五步能跑通，交付基本稳。

有个血泪教训：早期我给客户发过一个版本，本机跑得好好的，到现场一启动就退。查了半天是发布目录里漏了pbdwe90.dll，因为我的开发机上系统 PATH 里有安装目录，程序自动找到了；客户机上没有，直接崩。从那以后我每次打包都用上面这段脚本从安装目录显式拷文件，拷完在一台什么都不装的虚拟机里冷启一遍，再发出去。这套动作花不了十分钟，能省掉一次跨城返工。希望帮到你。

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