简介pd2bs-scripts 是一套面向暗黑破坏神2自动化脚本使用者与开发者的 JavaScript 脚本合集核心围绕 PD2BS 与 Kolbot 的配合使用展开解决机器人运行、游戏服务器切换、技能 ID 查询、特定物品拾取规则配置以及 D2BS 崩溃排查等实际问题。资源包共 229 个文件以 151 个 js 脚本为主体辅以 33 个 txt 说明、22 个 nip 拾取规则、10 个 dbj 启动配置及少量 dbl、ts、json 等辅助文件压缩后约 707KB结构紧凑、便于按模块查阅。内容涵盖 D2Bot 系列启动脚本、OOG 配置、拾取规则与常见问题说明读者可据此快速搭建并调试自己的自动化环境理解各脚本职责与参数含义掌握 GS 服务器修改、技能 ID 对照和崩溃修复等排错思路。目前已有 247 人学习下载适合具备一定动手能力、希望深入定制 Kolbot 行为的进阶用户参考。1. pd2bs-scripts 到底解决什么问题从一堆散落脚本到可复用工具链如果你手上有一批零散的 JavaScript 脚本每次用都得翻目录、改路径、手动跑那 pd2bs-scripts 这类脚本集合就是冲着这个场景来的。它把 pd2bs 相关的处理逻辑收拢成一组可独立调用的脚本文件核心价值在于「一次整理、反复调用」——不用每次从零写胶水代码也不用记住每个脚本藏在哪个子目录里。适合两类人一是需要批量处理 pd2bs 数据或配置的开发者二是想把现有脚本规范化、做成团队可共享工具链的工程师。它不解决算法问题解决的是「脚本散、调用乱、复用难」的工程问题。下面从目录结构、运行环境到具体脚本逐个拆。2. 目录结构与运行环境先搞清楚脚本怎么组织、依赖怎么装2.1 典型目录布局与文件命名规律拿到一个脚本集合第一件事不是急着跑而是先看目录怎么分的。pd2bs-scripts 这类项目通常按功能域划分子目录而不是把所有 .js 平铺在根目录。常见做法是根目录放一个入口脚本或 package.json子目录按「输入类型」或「处理阶段」命名比如parse/、transform/、export/各管一段。文件命名上我一般会看有没有统一前缀——如果全是pd2bs-xxx.js说明作者有意做命名空间隔离调用时不容易和系统里其他脚本撞名。先跑一遍目录树把结构看清楚# 查看项目根目录结构排除 node_modules 避免输出过长 find . -maxdepth 2 -not -path ./node_modules/* -not -path ./.git/* | sort这条命令只展开两层够你看清顶层目录和一级子目录的文件分布。-not -path排除依赖目录和版本控制目录输出更干净。如果发现某个子目录下全是.test.js或.spec.js那说明作者写了单元测试这类脚本集合的可靠性通常比裸脚本高一个档次因为至少有人验证过边界情况。2.2 Node.js 版本与依赖安装的实操步骤JavaScript 脚本集合对运行时的版本敏感度比想象中高。pd2bs-scripts 里如果用到了fs.promises、structuredClone或顶层awaitNode 版本低于 16 直接报语法错误。我一般先看 package.json 里的engines字段没有的话就看代码里用了哪些较新的 API。# 确认当前 Node 和 npm 版本 node -v npm -v # 如果有 package.json安装依赖 npm install # 没有 package.json 时检查脚本的 require/import 语句 grep -rE require\(|from --include*.js . | grep -v node_modules | head -30node -v输出如果低于 v16建议用 nvm 切一个 LTS 版本再跑。npm install会读取 package.json 里的 dependencies 和 devDependencies把依赖装到 node_modules。如果项目没有 package.json说明它是纯脚本集合依赖可能靠全局安装或手动引入——这时候 grep 出来的 require 列表就是你的依赖清单缺哪个装哪个。注意不要用npm install -g装项目依赖全局污染后患无穷我在这上面翻过车后来一律用本地安装。2.3 环境变量与配置文件的位置约定脚本集合通常需要一个配置文件来指定输入输出路径、API 端点或数据库连接串。常见做法是在根目录放.env或config.json代码里用process.env.XXX或require(./config)读取。先找有没有.env.example或config.sample.json有的话复制一份改名再填自己的值。# 查找配置模板文件 ls -la | grep -iE \.env|config|settings # 如果有 .env.example复制为 .env cp .env.example .env # 查看 .env 里需要填哪些键不显示值 grep -oE ^[A-Z_] .env | sortgrep -oE ^[A-Z_]只提取变量名不打印值避免敏感信息落到终端历史里。填配置时注意路径类变量用绝对路径还是相对路径——如果脚本内部会cd到其他目录再执行相对路径大概率翻车。我一般统一写成绝对路径虽然丑但稳。3. 核心脚本逐个拆从参数解析到批量处理的调用方式3.1 入口脚本的参数设计与调用示例入口脚本通常叫index.js或main.js负责解析命令行参数、分发到具体处理函数。看一个脚本能不能直接用先看它支不支持--help或-h。# 尝试获取帮助信息 node index.js --help # 如果没帮助信息直接看源码里的参数解析部分 head -50 index.js如果--help有输出说明作者用了commander、yargs或minimist这类库参数设计通常比较规范。没有的话就看源码里process.argv的切片逻辑。常见参数模式是node index.js --input ./data --output ./result --format json其中--input和--output是必填--format有默认值。调用时如果路径含空格记得用引号包住否则 shell 会把路径拆成多个参数脚本收到就懵了。// 典型的参数解析片段基于 minimist const argv require(minimist)(process.argv.slice(2)); const inputPath argv.input || ./default-input; const outputPath argv.output || ./default-output; const format argv.format || json; // 参数校验输入路径必须存在 const fs require(fs); if (!fs.existsSync(inputPath)) { console.error(输入路径不存在: ${inputPath}); process.exit(1); }这段代码的逻辑是从process.argv切掉前两个元素node 路径和脚本路径剩下的交给 minimist 解析成对象。argv.input取--input的值没传就用默认值。fs.existsSync做前置校验路径不存在直接退出并返回非零状态码方便在 CI 里判断成败。参数说明inputPath支持相对和绝对路径但建议传绝对路径format控制输出格式常见值有json、csv、text。3.2 批量处理脚本的输入输出约定批量处理脚本一般接收一个目录或一个文件列表遍历后逐个处理结果写到输出目录。关键点是输入目录里的文件命名是否有规律、输出文件是否覆盖原文件、处理失败时是跳过还是中断。// 批量遍历目录并处理每个文件 const fs require(fs); const path require(path); function processDirectory(inputDir, outputDir) { // 确保输出目录存在 if (!fs.existsSync(outputDir)) { fs.mkdirSync(outputDir, { recursive: true }); } const files fs.readdirSync(inputDir); const results []; for (const file of files) { const fullPath path.join(inputDir, file); const stat fs.statSync(fullPath); // 跳过子目录只处理文件 if (stat.isDirectory()) continue; try { const content fs.readFileSync(fullPath, utf-8); const processed transform(content); // 假设 transform 是处理函数 const outPath path.join(outputDir, file); fs.writeFileSync(outPath, processed, utf-8); results.push({ file, status: ok }); } catch (err) { results.push({ file, status: error, message: err.message }); } } return results; }逻辑说明fs.mkdirSync带recursive: true确保多级输出目录能一次创建。readdirSync拿到文件名列表后用statSync判断是文件还是目录目录直接跳过。try/catch包住单个文件的处理一个失败不影响后续文件最后汇总结果。参数说明inputDir和outputDir都建议传绝对路径transform是实际处理逻辑不同脚本里实现不同。注意如果输入文件很大readFileSync会一次性加载到内存几百 MB 以上建议换成流式处理。3.3 脚本间的依赖关系与调用顺序多个脚本之间往往有先后依赖先跑解析脚本生成中间文件再跑转换脚本最后跑导出脚本。如果顺序搞反轻则报错重则生成错误结果还不自知。我一般先看有没有 README 或package.json里的scripts字段那里通常会写清楚执行顺序。{ scripts: { parse: node parse/index.js --input ./raw --output ./parsed, transform: node transform/index.js --input ./parsed --output ./transformed, export: node export/index.js --input ./transformed --output ./final } }如果 package.json 里有这样的 scripts 定义直接npm run parse npm run transform npm run export就能按顺序跑完。没有的话就手动按「解析 → 转换 → 导出」的顺序调用。判断依赖关系的一个技巧看每个脚本的输出目录是不是另一个脚本的输入目录是的话就有先后依赖。注意不要并行跑有依赖关系的脚本中间文件还没生成完就读取必然报ENOENT。4. 避坑与排查脚本跑不起来时先查这五条4.1 现象SyntaxError: Unexpected token报错原因Node 版本太低不支持脚本里用的新语法如可选链?.、空值合并??、顶层 await。解决node -v确认版本低于 16 的用 nvm 切到 18 或 20 LTS。如果项目有.nvmrc文件直接nvm use即可。4.2 现象Error: Cannot find module xxx原因依赖没装或者脚本用了相对路径引入但工作目录不对。解决先npm install没有 package.json 就手动npm install xxx。如果是相对路径问题检查require(./lib/helper)里的./是不是相对于当前脚本文件——Node 的相对路径是相对于脚本所在目录不是执行命令的目录。4.3 现象脚本跑完没报错但输出目录是空的原因输入目录路径写错脚本遍历了一个空目录或者输入文件被过滤条件全部跳过。解决在遍历逻辑里加一行console.log(找到文件数:, files.length)先确认输入目录里确实有文件。再检查过滤条件比如if (file.endsWith(.pd2bs))是不是把实际文件都排除了。4.4 现象处理到一半卡住不动原因脚本在等标准输入stdin或者某个同步操作在等一个永远不会来的回调。解决先看代码里有没有process.stdin相关逻辑有的话要么传参跳过要么手动输入。如果是异步没加await用node --trace-warnings跑一遍能看到未处理的 Promise 警告。4.5 现象输出文件内容乱码或格式错乱原因读写文件时编码不一致比如读的时候用utf-8写的时候没指定编码默认成了buffer。解决fs.readFileSync和fs.writeFileSync都显式传utf-8。如果处理的是二进制文件读写都用Buffer不要转字符串。5. 进阶用法把散装脚本改造成可调度工具链5.1 用 npm scripts 串联多脚本执行单个脚本跑通之后下一步是把它们串成一条流水线。package.json 的scripts字段是最轻量的调度方案不需要额外装任何东西。{ scripts: { pd2bs:full: npm run parse npm run transform npm run export, pd2bs:watch: nodemon --watch ./raw --exec npm run pd2bs:full } }保证前一个脚本成功才跑下一个任何一个失败整条链就停。nodemon --watch监听输入目录变化文件一改就自动重跑全流程适合调试阶段。注意nodemon需要全局或本地安装npm install -D nodemon即可。5.2 加一层错误日志与重试机制生产环境跑脚本最怕的是静默失败。我一般会在入口脚本里加一个简单的日志包装function withRetry(fn, retries 3, delay 1000) { return async (...args) { for (let i 0; i retries; i) { try { return await fn(...args); } catch (err) { console.error(第 ${i 1} 次失败: ${err.message}); if (i retries - 1) throw err; await new Promise(r setTimeout(r, delay)); } } }; }这个包装器接收一个异步函数失败后等delay毫秒重试最多retries次。适合网络请求或文件锁冲突的场景。参数说明retries默认 3 次delay默认 1 秒可根据实际失败原因调整。注意不是所有错误都值得重试比如「文件不存在」重试多少次都没用所以最好在catch里判断错误类型再决定是否继续。5.3 验证脚本输出是否正确的三个检查点跑完脚本不能只看「没报错」就完事。我习惯做三个检查第一输出文件数量是否和输入文件数量一致排除过滤条件后第二随机抽一个输出文件和输入文件对比确认转换逻辑符合预期第三用diff对比两次运行的输出确认脚本是幂等的。# 检查输出文件数量 ls ./output | wc -l # 随机抽一个文件看内容 head -20 ./output/$(ls ./output | shuf -n 1) # 跑两次对比输出是否一致幂等性检查 npm run pd2bs:full cp -r ./output ./output-run1 npm run pd2bs:full diff -r ./output ./output-run1diff -r递归对比两个目录没有输出就说明两次运行结果完全一致脚本是幂等的。如果有差异说明脚本里可能有时间戳、随机数或未初始化状态需要排查。从那以后我每次改完脚本都强制走一遍「数量 → 抽样 → 幂等」这三步确认没问题才提交。希望帮到你。本文还有配套的精品资源点击获取 pd2bs-scripts 脚本集合实战：从散落脚本到可复用工具链
简介pd2bs-scripts 是一套面向暗黑破坏神2自动化脚本使用者与开发者的 JavaScript 脚本合集核心围绕 PD2BS 与 Kolbot 的配合使用展开解决机器人运行、游戏服务器切换、技能 ID 查询、特定物品拾取规则配置以及 D2BS 崩溃排查等实际问题。资源包共 229 个文件以 151 个 js 脚本为主体辅以 33 个 txt 说明、22 个 nip 拾取规则、10 个 dbj 启动配置及少量 dbl、ts、json 等辅助文件压缩后约 707KB结构紧凑、便于按模块查阅。内容涵盖 D2Bot 系列启动脚本、OOG 配置、拾取规则与常见问题说明读者可据此快速搭建并调试自己的自动化环境理解各脚本职责与参数含义掌握 GS 服务器修改、技能 ID 对照和崩溃修复等排错思路。目前已有 247 人学习下载适合具备一定动手能力、希望深入定制 Kolbot 行为的进阶用户参考。1. pd2bs-scripts 到底解决什么问题从一堆散落脚本到可复用工具链如果你手上有一批零散的 JavaScript 脚本每次用都得翻目录、改路径、手动跑那 pd2bs-scripts 这类脚本集合就是冲着这个场景来的。它把 pd2bs 相关的处理逻辑收拢成一组可独立调用的脚本文件核心价值在于「一次整理、反复调用」——不用每次从零写胶水代码也不用记住每个脚本藏在哪个子目录里。适合两类人一是需要批量处理 pd2bs 数据或配置的开发者二是想把现有脚本规范化、做成团队可共享工具链的工程师。它不解决算法问题解决的是「脚本散、调用乱、复用难」的工程问题。下面从目录结构、运行环境到具体脚本逐个拆。2. 目录结构与运行环境先搞清楚脚本怎么组织、依赖怎么装2.1 典型目录布局与文件命名规律拿到一个脚本集合第一件事不是急着跑而是先看目录怎么分的。pd2bs-scripts 这类项目通常按功能域划分子目录而不是把所有 .js 平铺在根目录。常见做法是根目录放一个入口脚本或 package.json子目录按「输入类型」或「处理阶段」命名比如parse/、transform/、export/各管一段。文件命名上我一般会看有没有统一前缀——如果全是pd2bs-xxx.js说明作者有意做命名空间隔离调用时不容易和系统里其他脚本撞名。先跑一遍目录树把结构看清楚# 查看项目根目录结构排除 node_modules 避免输出过长 find . -maxdepth 2 -not -path ./node_modules/* -not -path ./.git/* | sort这条命令只展开两层够你看清顶层目录和一级子目录的文件分布。-not -path排除依赖目录和版本控制目录输出更干净。如果发现某个子目录下全是.test.js或.spec.js那说明作者写了单元测试这类脚本集合的可靠性通常比裸脚本高一个档次因为至少有人验证过边界情况。2.2 Node.js 版本与依赖安装的实操步骤JavaScript 脚本集合对运行时的版本敏感度比想象中高。pd2bs-scripts 里如果用到了fs.promises、structuredClone或顶层awaitNode 版本低于 16 直接报语法错误。我一般先看 package.json 里的engines字段没有的话就看代码里用了哪些较新的 API。# 确认当前 Node 和 npm 版本 node -v npm -v # 如果有 package.json安装依赖 npm install # 没有 package.json 时检查脚本的 require/import 语句 grep -rE require\(|from --include*.js . | grep -v node_modules | head -30node -v输出如果低于 v16建议用 nvm 切一个 LTS 版本再跑。npm install会读取 package.json 里的 dependencies 和 devDependencies把依赖装到 node_modules。如果项目没有 package.json说明它是纯脚本集合依赖可能靠全局安装或手动引入——这时候 grep 出来的 require 列表就是你的依赖清单缺哪个装哪个。注意不要用npm install -g装项目依赖全局污染后患无穷我在这上面翻过车后来一律用本地安装。2.3 环境变量与配置文件的位置约定脚本集合通常需要一个配置文件来指定输入输出路径、API 端点或数据库连接串。常见做法是在根目录放.env或config.json代码里用process.env.XXX或require(./config)读取。先找有没有.env.example或config.sample.json有的话复制一份改名再填自己的值。# 查找配置模板文件 ls -la | grep -iE \.env|config|settings # 如果有 .env.example复制为 .env cp .env.example .env # 查看 .env 里需要填哪些键不显示值 grep -oE ^[A-Z_] .env | sortgrep -oE ^[A-Z_]只提取变量名不打印值避免敏感信息落到终端历史里。填配置时注意路径类变量用绝对路径还是相对路径——如果脚本内部会cd到其他目录再执行相对路径大概率翻车。我一般统一写成绝对路径虽然丑但稳。3. 核心脚本逐个拆从参数解析到批量处理的调用方式3.1 入口脚本的参数设计与调用示例入口脚本通常叫index.js或main.js负责解析命令行参数、分发到具体处理函数。看一个脚本能不能直接用先看它支不支持--help或-h。# 尝试获取帮助信息 node index.js --help # 如果没帮助信息直接看源码里的参数解析部分 head -50 index.js如果--help有输出说明作者用了commander、yargs或minimist这类库参数设计通常比较规范。没有的话就看源码里process.argv的切片逻辑。常见参数模式是node index.js --input ./data --output ./result --format json其中--input和--output是必填--format有默认值。调用时如果路径含空格记得用引号包住否则 shell 会把路径拆成多个参数脚本收到就懵了。// 典型的参数解析片段基于 minimist const argv require(minimist)(process.argv.slice(2)); const inputPath argv.input || ./default-input; const outputPath argv.output || ./default-output; const format argv.format || json; // 参数校验输入路径必须存在 const fs require(fs); if (!fs.existsSync(inputPath)) { console.error(输入路径不存在: ${inputPath}); process.exit(1); }这段代码的逻辑是从process.argv切掉前两个元素node 路径和脚本路径剩下的交给 minimist 解析成对象。argv.input取--input的值没传就用默认值。fs.existsSync做前置校验路径不存在直接退出并返回非零状态码方便在 CI 里判断成败。参数说明inputPath支持相对和绝对路径但建议传绝对路径format控制输出格式常见值有json、csv、text。3.2 批量处理脚本的输入输出约定批量处理脚本一般接收一个目录或一个文件列表遍历后逐个处理结果写到输出目录。关键点是输入目录里的文件命名是否有规律、输出文件是否覆盖原文件、处理失败时是跳过还是中断。// 批量遍历目录并处理每个文件 const fs require(fs); const path require(path); function processDirectory(inputDir, outputDir) { // 确保输出目录存在 if (!fs.existsSync(outputDir)) { fs.mkdirSync(outputDir, { recursive: true }); } const files fs.readdirSync(inputDir); const results []; for (const file of files) { const fullPath path.join(inputDir, file); const stat fs.statSync(fullPath); // 跳过子目录只处理文件 if (stat.isDirectory()) continue; try { const content fs.readFileSync(fullPath, utf-8); const processed transform(content); // 假设 transform 是处理函数 const outPath path.join(outputDir, file); fs.writeFileSync(outPath, processed, utf-8); results.push({ file, status: ok }); } catch (err) { results.push({ file, status: error, message: err.message }); } } return results; }逻辑说明fs.mkdirSync带recursive: true确保多级输出目录能一次创建。readdirSync拿到文件名列表后用statSync判断是文件还是目录目录直接跳过。try/catch包住单个文件的处理一个失败不影响后续文件最后汇总结果。参数说明inputDir和outputDir都建议传绝对路径transform是实际处理逻辑不同脚本里实现不同。注意如果输入文件很大readFileSync会一次性加载到内存几百 MB 以上建议换成流式处理。3.3 脚本间的依赖关系与调用顺序多个脚本之间往往有先后依赖先跑解析脚本生成中间文件再跑转换脚本最后跑导出脚本。如果顺序搞反轻则报错重则生成错误结果还不自知。我一般先看有没有 README 或package.json里的scripts字段那里通常会写清楚执行顺序。{ scripts: { parse: node parse/index.js --input ./raw --output ./parsed, transform: node transform/index.js --input ./parsed --output ./transformed, export: node export/index.js --input ./transformed --output ./final } }如果 package.json 里有这样的 scripts 定义直接npm run parse npm run transform npm run export就能按顺序跑完。没有的话就手动按「解析 → 转换 → 导出」的顺序调用。判断依赖关系的一个技巧看每个脚本的输出目录是不是另一个脚本的输入目录是的话就有先后依赖。注意不要并行跑有依赖关系的脚本中间文件还没生成完就读取必然报ENOENT。4. 避坑与排查脚本跑不起来时先查这五条4.1 现象SyntaxError: Unexpected token报错原因Node 版本太低不支持脚本里用的新语法如可选链?.、空值合并??、顶层 await。解决node -v确认版本低于 16 的用 nvm 切到 18 或 20 LTS。如果项目有.nvmrc文件直接nvm use即可。4.2 现象Error: Cannot find module xxx原因依赖没装或者脚本用了相对路径引入但工作目录不对。解决先npm install没有 package.json 就手动npm install xxx。如果是相对路径问题检查require(./lib/helper)里的./是不是相对于当前脚本文件——Node 的相对路径是相对于脚本所在目录不是执行命令的目录。4.3 现象脚本跑完没报错但输出目录是空的原因输入目录路径写错脚本遍历了一个空目录或者输入文件被过滤条件全部跳过。解决在遍历逻辑里加一行console.log(找到文件数:, files.length)先确认输入目录里确实有文件。再检查过滤条件比如if (file.endsWith(.pd2bs))是不是把实际文件都排除了。4.4 现象处理到一半卡住不动原因脚本在等标准输入stdin或者某个同步操作在等一个永远不会来的回调。解决先看代码里有没有process.stdin相关逻辑有的话要么传参跳过要么手动输入。如果是异步没加await用node --trace-warnings跑一遍能看到未处理的 Promise 警告。4.5 现象输出文件内容乱码或格式错乱原因读写文件时编码不一致比如读的时候用utf-8写的时候没指定编码默认成了buffer。解决fs.readFileSync和fs.writeFileSync都显式传utf-8。如果处理的是二进制文件读写都用Buffer不要转字符串。5. 进阶用法把散装脚本改造成可调度工具链5.1 用 npm scripts 串联多脚本执行单个脚本跑通之后下一步是把它们串成一条流水线。package.json 的scripts字段是最轻量的调度方案不需要额外装任何东西。{ scripts: { pd2bs:full: npm run parse npm run transform npm run export, pd2bs:watch: nodemon --watch ./raw --exec npm run pd2bs:full } }保证前一个脚本成功才跑下一个任何一个失败整条链就停。nodemon --watch监听输入目录变化文件一改就自动重跑全流程适合调试阶段。注意nodemon需要全局或本地安装npm install -D nodemon即可。5.2 加一层错误日志与重试机制生产环境跑脚本最怕的是静默失败。我一般会在入口脚本里加一个简单的日志包装function withRetry(fn, retries 3, delay 1000) { return async (...args) { for (let i 0; i retries; i) { try { return await fn(...args); } catch (err) { console.error(第 ${i 1} 次失败: ${err.message}); if (i retries - 1) throw err; await new Promise(r setTimeout(r, delay)); } } }; }这个包装器接收一个异步函数失败后等delay毫秒重试最多retries次。适合网络请求或文件锁冲突的场景。参数说明retries默认 3 次delay默认 1 秒可根据实际失败原因调整。注意不是所有错误都值得重试比如「文件不存在」重试多少次都没用所以最好在catch里判断错误类型再决定是否继续。5.3 验证脚本输出是否正确的三个检查点跑完脚本不能只看「没报错」就完事。我习惯做三个检查第一输出文件数量是否和输入文件数量一致排除过滤条件后第二随机抽一个输出文件和输入文件对比确认转换逻辑符合预期第三用diff对比两次运行的输出确认脚本是幂等的。# 检查输出文件数量 ls ./output | wc -l # 随机抽一个文件看内容 head -20 ./output/$(ls ./output | shuf -n 1) # 跑两次对比输出是否一致幂等性检查 npm run pd2bs:full cp -r ./output ./output-run1 npm run pd2bs:full diff -r ./output ./output-run1diff -r递归对比两个目录没有输出就说明两次运行结果完全一致脚本是幂等的。如果有差异说明脚本里可能有时间戳、随机数或未初始化状态需要排查。从那以后我每次改完脚本都强制走一遍「数量 → 抽样 → 幂等」这三步确认没问题才提交。希望帮到你。本文还有配套的精品资源点击获取