PowerBuilder 11.5安装配置与32位ODBC排错指南

简介：PowerBuilder 11.5 安装包面向需要搭建 PB11.5 开发环境、维护旧版 PowerBuilder 项目或进行兼容性验证的开发者与教学人员，适合在遗留系统维护、课程实验和升级评估等场景中使用。资源包体积约 729.75MB，压缩格式为 rar；上游未提供文件总数与文件类型明细，具体内容需以压缩包内实际目录为准。当前已有 1349 人浏览学习，说明该版本仍有一定使用与参考需求。对于需要获取 PowerBuilder 11.5 安装文件的读者，可用于建立本地开发与测试环境，便于后续查看旧项目结构、验证运行依赖和开展版本对比；在缺少现成安装介质时，也可作为该版本安装文件的补充来源。使用前建议结合自身系统环境与项目版本要求核对兼容性。

1. 从一台 64 位机器说起：pb11.5 装完连不上库的那个下午

接手老系统维护的时候，PowerBuilder 11.5 几乎是绕不开的一套环境。安装向导一路 Next，界面正常弹出来，工作区也建了，结果打开 Database Painter 想连库，数据源下拉框里干干净净——不是驱动没装，也不是账号写错，是 32 位和 64 位两个 ODBC 管理器在打架。pb11.5 本体是 32 位进程，它只看得到 32 位那一份数据源，你在 64 位入口里建多少个都没用。

这套环境现在主要落在三类人手里：维护十几年前上线的 MIS/ERP 系统的、要把旧 PBL 库编译成 .NET 目标的、还有被临时拉来救火、只求把源码跑起来的。装不好最典型的后果不是报错，是“看着正常但什么都不能干”——连不上库、编不出 .NET、编译好的 exe 到客户机上缺 DLL。下面按我实际装过几轮的顺序，把环境、安装、配置、排错、验证一条线走完。

2. 装前盘环境：PowerBuilder 11.5 的系统要求与依赖清单

装老 IDE 最容易犯的错是拿新机器的思路硬套：系统越新越好、位数越高越好。pb11.5 这套东西出生在 32 位当道的年代，它对“新”不敏感，对“齐不齐”特别敏感。我一般先在虚拟机里把系统盘做一份快照，再开始动手，后面任何一步翻车都能一分钟回到原点，这个后悔药成本极低。

2.1 操作系统、位数与硬件的账

官方那一代的要求写得很宽松，实际用下来有几个点必须自己补上判断。下面这张表是我这几年反复用下来的一版对照，虚拟机那列是我目前最常用的配置：

关于位数，我的结论是：能用 32 位系统就用 32 位系统。原因不在兼容性本身，而在于后面所有跟系统交互的环节——ODBC 管理器、System32 与 SysWOW64 的 DLL 落点、注册表的 WOW6432Node 重定向——在 32 位系统上全都只有一份，不可能搞错。64 位系统不是不能跑，只是每遇到一个“找不到”的问题，你都要先问自己一句“是不是我找错地方了”，排查成本翻倍。

2.2 .NET Framework 2.0 与那几个必装运行库

pb11.5 的一个卖点是把 PowerScript 编译成 .NET 程序集，WinForm、WebForm、Web Service 几种目标都支持。但这里有个特别容易漏的点：运行时（Runtime）和开发包（SDK）是两回事。装个 .NET Framework 2.0 只能让编出来的程序跑起来，IDE 里真正执行编译动作时调的是 SDK 里的编译器，SDK 没装，新建 .NET 目标那一刻就报找不到编译器。

装之前把这几样确认一遍，缺什么补什么：

# 逐项确认 pb11.5 依赖的几个组件在不在 # 1) .NET Framework 2.0 运行时：注册表里能查到版本号才算装好 Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727" -ErrorAction SilentlyContinue | Select-Object Version, InstallPath # 2) .NET Framework 2.0 SDK：编译 .NET 目标时必须，看 csc.exe 在不在 Test-Path "C:\Program Files (x86)\Microsoft.NET\SDK\v2.0\Bin\csc.exe" # 3) MDAC / 数据访问组件：看 ODBC 核心 DLL 的版本 (Get-Item "$env:SystemRoot\System32\odbc32.dll").VersionInfo.FileVersion # 4) 系统里的 IE 内核版本：老 IDE 的帮助系统和部分 ActiveX 面板依赖它 (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Internet Explorer").Version

第四条看着很无关，实际踩过：某些精简版系统把 IE 内核组件裁掉了，pb11.5 的帮助文档窗口打开是空白，连带一些属性面板也不渲染。这不是致命问题，但会让你以为装坏了。

csc.exe那一行是重点。SDK 的默认安装路径在不同系统上略有差异，64 位系统上通常在Program Files (x86)下，32 位系统在Program Files下，两个路径都测一遍更稳妥。返回 False 就说明只有运行时没有 SDK，得单独补装 2.0 的 SDK 包——注意别顺手装成 4.0 的，pb11.5 这一代只认 2.0。

还有一条容易被忽略：安装时用管理员权限运行 setup.exe。不是因为安装程序会提示权限不足，而是它在复制文件之后要往系统目录注册一堆 COM 组件和 DLL，权限不够时注册动作会静默失败，装完看着是成功的，用起来到处是“类未注册”。我一般的做法是右键 setup.exe 选“以管理员身份运行”，顺便把杀毒软件的实时防护临时关掉，等装完再开。

2.3 解压 .rar 之后的目录规划和安装包自检

拿到的是一个 rar 包，第一步不是双击，是先看里面有什么。老安装盘常见的结构是根目录一个 setup.exe，下面挂几个 disk 目录或者组件目录，也可能是一个 ISO 被压进了 rar。先解压到一个短路径、无空格、无中文的目录，比如D:\PB115SETUP，不要放在桌面或者“下载”里——安装过程中有些临时文件路径带中文会出问题，这是血泪经验。

# 先算哈希，跟发布方给的校验值对一下，确认传输过程中没坏包 Get-FileHash .\PowerBuilder115.rar -Algorithm SHA256 | Select-Object Algorithm, Hash, Path # 解压后确认安装入口和组件包是否齐全 Get-ChildItem .\PowerBuilder115 -Recurse -Filter setup.exe | Select-Object FullName, Length Get-ChildItem .\PowerBuilder115 -Directory | Select-Object Name

Get-FileHash出来的 SHA256 值拿去和来源方提供的值比对，不一致就重新下一份，别硬装——半截损坏的包最典型的症状是装到七八成的时候报解压失败然后整体回滚，浪费时间还容易误判成系统问题。

setup.exe那一行是确认入口在哪一层。有些打包方式会把安装程序藏在disk1子目录里，根目录的 setup.exe 只是个启动器；两种都能用，但知道入口在哪，后面出问题看日志时心里有数。

目录规划上我还有一个习惯：安装路径尽量短且不带空格，比如D:\PB115，而不是默认的C:\Program Files\...\PowerBuilder 11.5。原因是 pb11.5 有些配置节和批处理脚本对带空格的路径处理得不干净，尤其是命令行编译和自动化构建的时候，路径里的空格会被当成参数分隔符。这个坑在纯手工点界面的阶段不会暴露，等到你要写脚本批量编译的时候就炸了。

3. 跑安装向导：PowerBuilder 11.5 主程序与组件的取舍

向导本身没什么难的，难的是中间那两屏——选安装类型和勾组件。默认的 Typical 会塞一堆你这辈子用不上的东西，全勾又会把磁盘和后续排查复杂度拉满。这一章把每一屏该做什么、为什么这么做说清楚。

3.1 安装向导逐屏选择：序列号、路径与程序组

启动 setup.exe 之后，前面几屏基本是欢迎页、许可协议、安装类型、安装路径、程序组，节奏很快，但有两处要停一下。

第一处是安装类型。三个选项对应三种行为：Typical 装一套预设组件，Compact 只装最小可运行集，Custom 让你自己勾。老 IDE 的 Typical 预设往往包含示例库、报表工具、中间层客户端，对纯开发场景来说是负担。我一般直接选 Custom，下一屏自己勾。选 Custom 不影响功能完整性，只是把选择权拿回来。

第二处是序列号 / 许可信息页。pb11.5 是需要授权的商业 IDE，安装过程会要求输入序列号或者指向许可服务器。这一步没法跳过，也不要试图用来源不明的注册信息——装完能用但编译行为异常的情况我见过不止一次，最后排查半天发现是许可校验没过导致某些功能被降级。手上有正规授权的就按正规流程填，单位里通常有资产管理员能提供。

安装路径那一屏，按上一章说的，指到一个短路径。程序组那一屏保持默认即可，它只是开始菜单里的文件夹名，不影响任何功能。

后面就是复制文件加注册组件，这一段耗时最长，中间会有进度条停顿，停顿的时候不要点取消，也不要以为卡死了就强杀进程。它在做的动作包括往系统目录写运行时 DLL、注册 COM 组件、写注册表配置节，中途打断会留下半装状态，后续重装时安装程序检测到残留，可能直接拒绝安装或者装出一份自相矛盾的目录。真遇到超过十分钟完全没动静的，先开任务管理器看安装进程的 CPU 和 IO 是否还在动，再决定。

3.2 组件勾选：哪些必须装，哪些装了就是负担

这一屏是整篇里最值得抄的部分。下面这张表是我用了几年稳定下来的一套勾选方案，按“必装 / 按需 / 不装”三档分：

有两个取舍值得单独说。一是.NET 目标支持。很多人装了之后发现新建 WinForm 目标编译报错，就以为组件没装对，其实是前面说的 SDK 缺失。组件本身装了但 SDK 没装，IDE 里那个选项是亮的、点了会失败，比没装更迷惑。所以勾了这一步，务必回到第 2 章把csc.exe确认一遍。

二是随包数据库。如果你的目标只是打开老 PBL 库改改代码、连的是单位已有的库，那这套本地库完全可以不装，省几百兆空间，也少一个开机自启的服务。反过来，如果你想先验证环境是否装通、又不想碰生产的库，装一个本地库反而是最省事的验证手段，装完就有一个能连的示例数据源。

3.3 安装后的目录结构与 PATH 里的两个路径

装完之后去安装目录看一眼，结构大致是这样：

D:\PB115\ ├── PowerBuilder 11.5\ # IDE 主程序目录，PB.EXE 在这里 │ ├── PB.EXE │ ├── *.PBD / *.PBL # 自带示例与系统库 │ └── ... └── Shared\PowerBuilder\ # 共享运行库，所有编译产物都靠它 ├── pbvm115.dll # 虚拟机核心，缺它 exe 直接起不来 ├── pbdwe115.dll # 数据窗口引擎 ├── pbshr115.dll # 公共函数库 └── ...

Shared\PowerBuilder这个目录是重点。IDE 启动时自己能找到它，但你编译出来的 exe 拿到别的机器上跑，或者在同一台机器上用命令行启动，靠的是系统 PATH 里的这条路径。所以装完第一件事就是把它加进 PATH：

# 把共享运行库目录写进当前用户的 PATH，避免编译产物找不到 pbvm115.dll $pbShared = "D:\PB115\Shared\PowerBuilder" # 先判断是否已经存在，重复追加会让 PATH 越来越长 $userPath = [Environment]::GetEnvironmentVariable("PATH", "User") if ($userPath -notlike "*$pbShared*") { [Environment]::SetEnvironmentVariable("PATH", "$userPath;$pbShared", "User") Write-Host "已追加：$pbShared" } else { Write-Host "已存在，跳过" }

这段用的是User级别的环境变量而不是Machine级别，理由是机器级 PATH 修改需要管理员权限，而且一旦写坏影响全系统所有用户；用户级的够用，出问题也好回退——把那个键值改回去就行。-notlike "*$pbShared*"这一句是防重复，PATH 里堆十几条重复路径是老机器上的常见病，会让某些命令行工具解析变慢，也难看。

写完 PATH必须重开一个终端或者注销重登才生效，当前已经打开的窗口读的还是旧值。这一点在排查“我明明加了 PATH 为什么还找不到 DLL”的时候，十次有三次是没重开。

4. 配开发环境：数据源、PB.INI 与 .NET 目标的落地配置

装完只是把工具放到硬盘上，能不能干活取决于配置。这一章的四个点，按依赖顺序排：先让 IDE 能连上库，再让连接参数稳定下来，然后处理 .NET 目标的编译链路，最后把工作区和库的关系理清楚。

4.1 用 32 位 ODBC 管理器建数据源

这是整篇里最容易翻车的一步，也是第 1 章那个场景的根源。64 位 Windows 上同时存在两个 ODBC 管理器，名字只差一个括号：

# 64 位系统上有两个入口，pb11.5 只认下面这一个 Start-Process "$env:SystemRoot\SysWOW64\odbcad32.exe" # 32 位，pb11.5 用这个 # Start-Process "$env:SystemRoot\System32\odbcad32.exe" # 64 位，pb11.5 看不到这里的数据源

判断自己该用哪个的办法很简单：IDE 是 32 位进程，就只能看见 32 位的数据源。SysWOW64 这个目录名反直觉——它是给 32 位程序用的，System32 反而是给 64 位程序用的，这个命名是历史遗留，别按字面理解。

打开正确的管理器之后，建数据源的流程是标准的：选驱动（SQL Server、Oracle、Sybase ASE 之类按你实际的库来选）、填名称、填服务器地址、填认证方式、测试连接。测试通过再保存，不要跳过测试直接存。存下来的 DSN 名字要记住，下一步在 IDE 里要用。

如果这一步测试连接就失败，问题在驱动或者网络，跟 pb11.5 无关，先在 ODBC 层面解决干净。常见的两个原因：驱动版本和数据库服务器版本差太远（老驱动连新库、新驱动连老库都可能握手失败），以及 32 位驱动根本没装——很多驱动安装包默认只装 64 位版本。

4.2 PB.INI 与 DB Profile：连接参数到底落在哪

IDE 里的数据库配置最终会落到两个地方：一个是 pb11.5 自己的配置文件 PB.INI，一个是 IDE 的数据库画板里定义的 DB Profile。搞清楚这两者的关系，能省掉大量“我改了为什么没生效”的困惑。

PB.INI 是 IDE 的全局配置，默认落在安装目录下，也可以在启动时用/INI参数指定别的路径。数据库 профиль 相关的节大致长这样：

[DBMS_PROFILES] ; 这里记录当前有哪些 Profile，Session 决定启动时默认用哪个 Session=0 Profile_1=erp_odbc [Profile erp_odbc] ; DBMS 必须和实际驱动类型匹配，写错会报 DBMS xxx not found DBMS=ODBC ; Database 是库名，不是 DSN 名，两者别混 Database=erpdb UserId=dba DatabasePassword= ; ServerName 这里填的是 ODBC 里那个 DSN 的名字 ServerName=erp_odbc ; DBParm 是传给驱动的连接串，注意引号是单引号，分号分隔 DBParm=ConnectString='DSN=erp_odbc;UID=dba;PWD=****'

几个参数单独说明。DBMS=ODBC是指定走 ODBC 通道，如果用的是厂商原生驱动，这里会换成对应的标识；写错这个值 IDE 会直接报“DBMS 未找到”，跟驱动装没装完全是两回事，别一看到这个报错就去重装驱动。

ServerName和Database是两回事，前者是 DSN 名称，后者是连上之后要在哪个库里操作。这两个填反了的表现是能连上服务器但找不到表，很迷惑。

DBParm里的ConnectString建议用单引号包起来，因为值里面本身有分号，双引号在某些版本解析时会出问题。

提示：密码字段在 PB.INI 里是明文或者弱编码的。把配置文件放到共享目录、或者提交进版本库之前，先确认里面没有生产库口令，这个习惯要养成。

除了 PB.INI，IDE 的数据库画板里还能看到一份 DB Profile 列表，两者是同步的。改的时候我一般在 IDE 界面里改，让它自己写回配置文件，手工编辑 PB.INI 只作为批量迁移或者救援手段——手工改漏一个分号，IDE 可能整个配置节读不出来，症状是数据库画板一打开就闪退。

4.3 .NET 目标的配置：WinForm、WebForm 与智能客户端

如果你勾了 .NET 支持，这一节是重点。pb11.5 的 .NET 编译有几个前提必须配齐，缺一个就会在“部署”那一步失败，而错误提示往往指向具体某一行代码，让人误以为是代码问题。

第一，.NET Framework 2.0 SDK 必须在。前面查过csc.exe的位置，这里要确认 IDE 能找到它。有些版本会在系统选项里提供编译器的路径设置，路径不对就手工指到...\SDK\v2.0\Bin那一层。

第二，编译输出目录要和源码库分开。我习惯在工程根目录下建out\winform、out\webform这样的子目录，让每次编译产物都落在固定位置。混在一起最典型的后果是：改了一个 pbl 编译，旧产物没清，跑起来的还是上一版，排查半天发现是缓存问题。

第三，三种目标类型的取舍：

对绝大多数维护场景，WinForm 是性价比最高的选择：界面代码基本不用动，编译出来就能在只装了 .NET Framework 的机器上跑，不用再单独装 PB 运行时。WebForm 的水深得多，IIS 配置、数据窗口的 Web 呈现方式、会话管理都要重新考虑，除非明确要做浏览器访问，不建议一上来就选它。

验证编译器配置是否生效，最快的办法是新建一个空目标编译一次，看输出目录里有没有生成 dll 和 exe，不要等代码写完再试。

4.4 工作区与 PBL 库的初始化：库搜索路径的顺序问题

pb11.5 的工程结构是三层：工作区（.pbw）管项目，目标（.pbt）管构建，PBL 库管代码。新手最容易忽略的是库搜索路径的顺序，它决定了同名对象以哪个为准，也决定了引用外部函数和共享库时能不能找到。

一个典型工程的库列表应该按这个顺序排：先放自己项目的主库，再放公共库（公共函数库、服务库之类的 pfc 系列），最后放系统库。顺序反了，会出现你明明改了主库里的函数，运行起来还是走旧逻辑的情况——因为搜索路径先命中了公共库里的同名对象。

新建工程的时候，IDE 会问你 Application 对象放在哪个库、是否用模板生成。我的建议是：不要用模板，尤其是网络模板。模板会拉一堆用不上的对象进来，还会引入你根本没打算要的依赖。空工程加一个 Application 对象，二十秒的事，比清理模板留下的垃圾快得多。

库文件本身要注意两件事。一是别把 PBL 放在网络共享盘上，PB 对库文件的读写不是并发安全的，多人协作时极易出现库损坏，修复代价很高；要协作就分库，通过注册函数或者对象继承来共享，不要共享文件。二是定期备份 PBL 库，这个文件是二进制的，坏了没法用文本方式修，只能回滚。我一般每天把库目录整体复制一份带日期后缀，成本几乎为零。

5. 避坑与排查：装完打不开、连不上、编译不过的六种情形

这一章是我这几年攒下来的排查笔记，按“现象 → 原因 → 解决”的格式记，遇到的时候直接对号入座，别从头开始猜。

5.1 装到一半回滚，日志里全是“注册模块失败”

现象：进度条到六七十个百分点突然回滚，装完什么都没留下，重装还是同一位置失败。

原因：复制完文件之后的注册阶段需要管理员权限，或者被杀毒软件的实时防护拦住了对系统目录的写入。还有一种少见情况是系统里已经有一份旧版本残留，注册表冲突。

解决：先彻底清理——卸载残留、删掉安装目录、清掉临时目录里安装程序解出来的文件，然后关掉杀软实时防护，右键以管理员身份运行 setup.exe。装完再开防护。如果仍然失败，去看安装日志（通常在系统临时目录下，文件名带安装程序名），里面会写明是哪个模块注册失败，比反复重装有效得多。

5.2 双击图标没反应，或者窗口一闪就没了

现象：安装成功，双击 PB.EXE 之后没有任何界面，任务管理器里进程出现又消失。

原因：多见于 Windows 7 之后的系统。一是数据执行保护和老版本虚拟机的兼容问题，二是安装目录权限不对导致 IDE 启动时读配置失败，三是显卡驱动和老界面框架冲突。

解决：先给 PB.EXE 设置兼容模式（右键属性 → 兼容性 → 以兼容模式运行，选 XP SP3），再去“系统属性 → 高级 → 性能设置 → 数据执行保护”里把 PB.EXE 加进例外列表。这两步能解决绝大多数闪退。仍不行的话，用命令行带/INI参数指定一份全新的配置文件启动，排除配置文件损坏的可能。

5.3 数据库画板里数据源列表空空如也

现象：ODBC 管理器里明明建了 DSN，测试也通过，IDE 的数据库配置界面里下拉框就是没有选项。

原因：32 位 / 64 位 ODBC 管理器搞混了，这是最高频的一条。

解决：直接打开C:\Windows\SysWOW64\odbcad32.exe，看里面有没有你建的那个 DSN。没有就说明建到 64 位那份去了，在这里重建一份。建完不用重启系统，重开 IDE 即可。

5.4 新建 .NET 目标报“找不到编译器”

现象：WinForm 目标能建，一编译就失败，报错指向找不到编译器或者无法加载编译器组件。

原因：只装了 .NET Framework 运行时，没装 2.0 的 SDK。两者文件名相似，装的时候极易混淆。

解决：确认...\Microsoft.NET\SDK\v2.0\Bin\csc.exe存在，不存在就补装 SDK 包。补装之后如果 IDE 还是找不到，去系统选项里手工指定编译器目录。注意不要装 4.0 的 SDK 来“向下兼容”，这一代 IDE 不认。

5.5 编译出的 exe 在别的机器上跑不起来

现象：开发机上双击正常，拷到客户机上报缺少 DLL，通常是pbvm115.dll或者数据窗口引擎那个。

原因：exe 依赖共享运行库，开发机上因为 PATH 里有共享目录所以能找到，客户机没有。

解决：分两种情况。如果目标是传统 C/S 程序，把Shared\PowerBuilder下运行时需要的 DLL 一起打包发布，或者在客户机上装一份最小运行时并配好 PATH。如果目标已经编译成 .NET 程序集，那只需要目标机器装 .NET Framework 2.0，不再依赖 PB 的运行时 DLL——这也是把老系统迁到 .NET 目标的主要收益之一。发布前在干净的虚拟机里试跑一遍，别在开发机上验证。

5.6 打开老库报库版本不兼容，或者中文全是乱码

现象：从别人那里拿到的 PBL 库，打开时报格式错误或版本不匹配；或者能打开，但中文注释和界面文字全是方框。

原因：前者是库的格式版本高于当前 IDE 支持的范围，或者库文件本身损坏；后者是系统区域设置里的非 Unicode 程序语言和库的编码不匹配。

解决：版本问题基本无解，只能升级 IDE 到能打开该库的版本，或者找来源方导出一份低版本格式——所以接手项目第一件事是问清楚当初用的具体版本。乱码问题去控制面板的区域设置里，把“非 Unicode 程序的语言”改成中文（简体），重启系统生效。改完如果中文正常但部分符号还是怪，那是字体问题，把 IDE 界面字体换成系统自带的中文字体。

6. 装完怎么验证：从空工作区到能在别的机器上跑起来的 exe

验证这件事，我不看 IDE 能不能打开，我看的是从零建一个应用、写一行代码、编译、拷到另一台机器跑起来这条完整链路通不通。链路通了，说明虚拟机、运行时、编译器、打包四层都没问题；任何一环断了，前面的步骤都白做。

第一步，新建工作区和目标：

1. File → New → Workspace，存成 selftest.pbw，放在 D:\selftest 下 2. 右键工作区 → New → Target → Application，目标名填 selftest 3. 新建一个 PBL 库 selftest.pbl，Application 对象命名为 app_selftest 4. 在 Application 对象的 Open 事件里写下面三行

// 最小自检脚本：能弹出这个框，说明 VM、图形层、事件机制都是通的 long ll_handle ll_handle = Handle(GetApplication()) MessageBox("环境自检", "应用已启动，应用对象句柄：" + String(ll_handle))

GetApplication()拿到当前应用对象，Handle()取它的句柄，句柄非零说明对象已经在内存里正常实例化。这个自检比看界面有没有出来可靠得多，因为界面可能只是壳子起起来了，对象系统没初始化完。

第二步，编译成可执行文件，然后在同一台机器上换一个目录运行。换目录是为了确认 exe 不是靠当前工作目录里的某个文件才跑起来的。

第三步，也是最关键的一步：把这套东西拷到一台只装了 .NET Framework 2.0 的干净虚拟机上跑。如果编的是 WinForm 目标，应该能直接起来；如果是传统 C/S 目标，就要把共享运行库目录一起带过去或者装最小运行时。这一步能一次性验证发布包里到底缺什么。

我自己的验证清单是这样的：

这套清单我从第一次被“开发机好好的、客户机打不开”坑过之后就一直留着。现在每次装完环境，哪怕只是给同事临时搭一台，我也会把自检脚本跑一遍、把产物丢到干净机器上启动一次，再交付。多花二十分钟，省掉的是后面来回扯皮的两天。希望帮到你。

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