1. 项目概述当Node.js遇见Shell谷歌zx如何重塑脚本编写体验如果你和我一样常年混迹在Node.js和运维开发领域那你一定对写Shell脚本这件事又爱又恨。爱的是它简单直接几行命令就能串联起复杂的系统操作恨的是Bash脚本的语法有时略显晦涩错误处理麻烦想在脚本里调用个Node模块或者处理个JSON数据更是得费一番周折。我们常常陷入一种分裂状态一部分逻辑用Node.js写得优雅流畅另一部分系统操作又不得不切回Bash中间用child_process调来调去代码既冗长又脆弱。就在这种背景下谷歌开源了一个名为zx的工具。我第一次看到它时感觉就像有人把我脑子里那个“要是能这样写脚本就好了”的想法给具象化了。简单来说zx是一个基于Node.js的脚本编写工具它让你能够用JavaScript或者TypeScript的语法以一种近乎“嵌入式”的方式无缝地编写和执行Shell命令。它不是一个全新的语言而是对Node.js原生child_process模块的极致封装和语法糖增强目标是让编写跨平台的、强大的脚本变得像写普通Node.js代码一样简单愉快。它的核心价值在于将JavaScript的生态和表达能力与Shell命令的原生威力结合在了一起。你不再需要为了执行一个ls命令而去写exec(‘ls’, (error, stdout, stderr) {...})这样的回调地狱。在zx脚本里你可以直接用反引号包裹命令像使用模板字符串一样执行它并且能直接拿到结构化的结果。这对于需要频繁与操作系统交互、进行文件操作、调用外部CLI工具如git、docker、aws-cli的自动化任务、构建脚本、部署流程来说简直是生产力利器。2. zx的核心设计哲学与工作原理拆解2.1 为什么是“Bash in Node”而不是“Node in Bash”理解zx的设计首先要明白它解决的问题域。传统的Node.js脚本调用Shell是“Node in Bash”的思路Node是子进程被Bash脚本通过node script.js调用。而zx反其道而行之是“Bash in Node”以Node.js进程为主体将Shell命令的执行内化为JavaScript语言的一部分。这种设计带来了几个根本性的优势统一的语言环境整个脚本的逻辑控制条件判断、循环、函数、数据处理JSON解析、字符串操作、异步流程Promise, async/await全部由JavaScript/TypeScript完成。这消除了上下文切换的心智负担你可以用你最熟悉的工具链ES6语法、TypeScript类型检查、VS Code智能提示来开发脚本。强大的生态集成你可以直接在脚本里require或import任何npm包。想发个HTTP请求直接用axios或node-fetch。想解析CSV直接用csv-parser。想操作数据库直接用对应的驱动。这相当于把整个npm的百万级模块库变成了你脚本的后备力量这是纯Bash脚本难以企及的。更优秀的错误处理和流程控制zx将每个Shell命令的执行为一个返回Promise的对象。这意味着你可以用try...catch来捕获命令执行失败用await来优雅地处理异步依赖用Promise.all()来并发执行多个独立任务。这种基于Promise的模型比Bash的set -e和$?检查要直观和健壮得多。跨平台友好性zx在底层对命令做了一层抽象。它默认使用/bin/sh但在Windows环境下如果你安装了Git Bash或WSL它能更好地处理路径等问题。虽然不能100%解决所有跨平台差异但它提供了比原生child_process更好的起点和工具函数如cd,fetch。2.2 zx的核心API与魔法反引号背后的故事zx的魔法很大程度上来自于JavaScript的模板字符串反引号和Tagged Template Literals特性。当你写下const files await $ls -la时发生了以下事情$函数zx导出了一个名为$的函数。这个函数是一个Tagged Template函数。参数解析模板字符串内的内容ls -la会被传递给$函数。$函数会解析这个字符串识别出命令和参数。子进程执行$函数内部使用Node.js的child_process.spawn来创建一个子进程执行解析出的命令ls和参数-la。Promise封装该函数返回一个Promise。这个Promise在子进程退出时解决resolve。如果子进程退出码exit code为0Promise成功解决并将进程的标准输出stdout作为字符串返回。如果退出码非零Promise被拒绝reject并抛出一个错误错误信息中通常包含标准错误输出stderr。结果赋值通过await等待这个Promise完成命令的输出stdout就被赋值给了files变量。这就是为什么你能以如此直观的方式与Shell交互。zx还提供了其他几个非常实用的顶级APIcd()改变当前工作目录。这是一个同步函数但它改变了Node.js进程的process.cwd()。在脚本中频繁切换目录时非常有用比写一堆cd /some/path ...清晰得多。fetch()一个全局可用的、基于node-fetch的fetch实现。让你能在脚本中轻松发起HTTP请求无需额外导入包。question()一个基于readline的封装用于在命令行中与用户进行简单的交互式问答。sleep()一个返回Promise的延迟函数用于在脚本中暂停一段时间。os、fs、path等zx直接重新导出了Node.js核心模块os、fs、path方便使用。注意zx脚本的文件扩展名通常是.mjs或者需要在package.json中设置”type”: “module”。这是因为它大量使用ES Module的顶级await和import语法。这是现代JavaScript项目的趋势但也意味着如果你在旧的CommonJS.js项目中直接运行可能会遇到语法错误。一个快速的解决方法是使用node --loaderstd/esm your-script.mjs如果版本合适或者更简单地将文件命名为.mjs并直接使用node运行Node.js 14.8支持顶级await在ES模块中。3. 从零开始zx的安装与第一个脚本3.1 环境准备与安装使用zx的前提是有一个Node.js环境。我推荐使用nvmNode Version Manager来管理Node.js版本这样可以轻松切换和尝试不同版本。这里以macOS/Linux为例# 1. 安装nvm如果尚未安装 # 可以通过官方脚本安装注意检查最新安装命令 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash # 或者 wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash # 安装完成后重启终端或执行 source ~/.bashrc (或 ~/.zshrc) # 2. 安装一个较新的Node.js LTS版本例如18.x nvm install 18 nvm use 18 # 3. 验证安装 node --version npm --version有了Node.js环境安装zx有两种主要方式方式一全局安装推荐用于快速尝试和运行脚本这种方式会将zx作为一个全局命令行工具安装。你可以直接使用zx your-script.mjs来运行脚本。npm install -g zx安装后你可以通过zx --help查看帮助信息。方式二项目内安装推荐用于可复用的项目脚本在你的项目目录下将其作为开发依赖安装。npm init -y # 如果还没有package.json npm install --save-dev zx然后你可以在package.json的scripts字段中定义命令或者使用npx zx来运行脚本。3.2 编写并执行你的第一个zx脚本让我们创建一个最简单的脚本感受一下zx的流畅。创建脚本文件新建一个文件命名为hello.mjs。使用.mjs扩展名明确表示这是一个ES模块。添加脚本内容// hello.mjs #!/usr/bin/env zx console.log(Hello, zx!); // 执行一个简单的shell命令 const result await $echo Current directory: pwd; console.log(result); // 列出当前目录文件并处理输出 const { stdout } await $ls -la; const lines stdout.trim().split(\n); console.log(Found ${lines.length - 1} items in total (including . and ..)); // 减去 . 和 .. // 使用fetch获取网络数据 const response await fetch(https://api.github.com/users/google); const data await response.json(); console.log(GitHub user google has ${data.public_repos} public repositories.);注意脚本第一行的Shebang#!/usr/bin/env zx。这一行告诉系统这个文件应该用zx解释器来执行。在Unix-like系统上这赋予了脚本直接执行的能力。赋予执行权限并运行Unix-like系统chmod x hello.mjs ./hello.mjs或者在Windows上如果你全局安装了zx也可以直接运行zx hello.mjs如果是在项目内安装使用npx zx hello.mjs观察输出你会看到脚本依次打印了问候语、当前目录、文件列表信息以及从GitHub API获取的谷歌开源组织的信息。整个过程Shell命令、JavaScript逻辑、网络请求浑然一体。实操心得一开始你可能会疑惑为什么脚本里可以直接用await而不用async函数包裹这正是.mjsES模块和zx的魔力。在ES模块的顶层作用域await是允许的。这极大地简化了脚本的结构使得整个文件看起来就像一个线性的执行流程非常符合脚本编写的直觉。4. 深入实战zx在复杂自动化场景中的应用掌握了基础我们来看几个更贴近实际工作的例子。zx的真正威力体现在处理复杂逻辑和集成多种工具上。4.1 场景一自动化项目初始化与依赖检查假设你经常需要初始化新的前端项目步骤包括创建目录、初始化git、创建基础文件、安装依赖。用zx可以这样写#!/usr/bin/env zx // init-project.mjs import { $, cd, question } from zx; // 注意在.mjs文件中需要使用import语法即使全局安装了zx也建议显式导入。 const projectName await question(请输入项目名称: ); const useTypeScript await question(是否使用TypeScript? (y/n): ) y; console.log(正在创建项目: ${projectName}); // 1. 创建项目目录并进入 await $mkdir -p ${projectName}; cd(projectName); // 2. 初始化git仓库 await $git init; await $echo “node_modules” .gitignore; // 3. 创建package.json const packageJson { name: projectName, version: “1.0.0”, private: true, scripts: { dev: “vite”, build: “vite build”, preview: “vite preview” } }; if (useTypeScript) { packageJson.scripts.dev “tsc vite”; } // 使用fs模块写入文件 import { writeFileSync } from fs; writeFileSync(‘package.json’, JSON.stringify(packageJson, null, 2)); // 4. 安装依赖 const deps [‘vite’]; const devDeps [‘eslint’, ‘prettier’]; if (useTypeScript) { devDeps.push(‘typescript’, ‘types/node’); } console.log(‘正在安装依赖…’); // 使用$传递数组参数可以避免shell注入风险也更清晰 await $npm install ${deps.join(‘ ‘)}; await $npm install --save-dev ${devDeps.join(‘ ‘)}; // 5. 创建基础文件 await $echo “!DOCTYPE htmlhtmlheadtitle${projectName}/title/headbodydiv id‘app’/divscript type‘module’ src‘/src/main.js’/script/body/html” index.html; await $mkdir -p src; await $echo “import ‘./style.css’; console.log(‘Hello Vite!’)” src/main.js; await $echo “body { margin: 0; }” src/style.css; if (useTypeScript) { await $echo “{ \”compilerOptions\”: { \”target\”: \”ES2020\”, \”useDefineForClassFields\”: true, \”module\”: \”ESNext\”, \”lib\”: [\”ES2020\”, \”DOM\”, \”DOM.Iterable\”], \”skipLibCheck\”: true, \”moduleResolution\”: \”bundler\”, \”allowImportingTsExtensions\”: true, \”resolveJsonModule\”: true, \”isolatedModules\”: true, \”noEmit\”: true, \”strict\”: true, \”noUnusedLocals\”: true, \”noUnusedParameters\”: true, \”noFallthroughCasesInSwitch\”: true }, \”include\”: [\”src\”] }” tsconfig.json; await $mv src/main.js src/main.ts; } console.log( 项目 ${projectName} 初始化完成); console.log( 进入目录: cd ${projectName}); console.log( 启动开发服务器: npm run dev);这个脚本展示了zx如何将用户交互、文件操作、Shell命令、JSON处理完美结合。question()用于交互cd()切换目录$执行命令fs模块写文件逻辑一气呵成。4.2 场景二智能化的系统监控与日志清理脚本运维中经常需要监控磁盘使用情况并在空间不足时自动清理旧日志。zx让这类任务变得清晰可维护。#!/usr/bin/env zx // cleanup-logs.mjs import { $, fs } from ‘zx’; import path from ‘path’; // 配置 const LOG_DIR ‘/var/log/myapp’; const DISK_USAGE_THRESHOLD 80; // 百分比 const LOG_RETENTION_DAYS 30; // 1. 检查磁盘使用率 const dfOutput await $df -h ${LOG_DIR} | tail -1; // 输出示例/dev/sda1 100G 85G 15G 85% /var/log/myapp const usageMatch dfOutput.stdout.match(/(\d)%/); if (!usageMatch) { console.error(‘无法解析磁盘使用率’); process.exit(1); } const usagePercent parseInt(usageMatch[1], 10); console.log(当前磁盘使用率: ${usagePercent}%); if (usagePercent DISK_USAGE_THRESHOLD) { console.log(‘磁盘空间充足无需清理。’); process.exit(0); } console.log(‘⚠️ 磁盘空间不足开始清理旧日志…’); // 2. 查找超过保留期限的日志文件 const findCommand find ${LOG_DIR} -name “*.log” -type f -mtime ${LOG_RETENTION_DAYS}; const oldFiles (await $${findCommand}).stdout.trim().split(‘\n’).filter(Boolean); if (oldFiles.length 0) { console.log(‘未找到超过保留期限的日志文件。’); process.exit(0); } console.log(找到 ${oldFiles.length} 个待清理文件:); oldFiles.forEach(file console.log( - ${file})); // 3. 用户确认生产环境可改为直接执行或发送通知 import readline from ‘readline’; const rl readline.createInterface({ input: process.stdin, output: process.stdout }); const answer await new Promise(resolve { rl.question(‘是否确认删除(yes/no): ‘, resolve); }); rl.close(); if (answer.toLowerCase() ! ‘yes’) { console.log(‘操作已取消。’); process.exit(0); } // 4. 执行删除并记录 const timestamp new Date().toISOString().replace(/[:.]/g, ‘-’); const deleteLogFile ./deletion-${timestamp}.log; let deletedCount 0; let errorCount 0; for (const file of oldFiles) { try { await $rm -v ${file}; console.log(已删除: ${file}); await fs.appendFile(deleteLogFile, ${new Date().toISOString()} DELETED: ${file}\n); deletedCount; } catch (error) { console.error(删除失败 ${file}:, error.message); await fs.appendFile(deleteLogFile, ${new Date().toISOString()} FAILED: ${file} - ${error.message}\n); errorCount; } } console.log(\n清理完成。已删除: ${deletedCount}, 失败: ${errorCount}); console.log(操作日志已保存至: ${path.resolve(deleteLogFile)}); // 5. 可选再次检查磁盘使用率 const dfOutputAfter await $df -h ${LOG_DIR} | tail -1; const usageAfterMatch dfOutputAfter.stdout.match(/(\d)%/); if (usageAfterMatch) { console.log(清理后磁盘使用率: ${parseInt(usageAfterMatch[1], 10)}%); }这个脚本体现了zx在系统运维中的价值解析命令输出、条件判断、循环处理、错误捕获、文件操作、用户交互所有逻辑都在一个连贯的JavaScript流程中完成比写一个同等功能的Bash脚本要清晰和健壮得多尤其是错误处理部分。4.3 场景三结合Git的自动化Changelog生成器在团队协作中自动生成版本变更日志Changelog是提升效率的好方法。我们可以用zx调用git命令解析提交历史生成格式化的Markdown文档。#!/usr/bin/env zx // generate-changelog.mjs import { $ } from ‘zx’; // 配置从哪个Tag开始生成如果不提供则从上个Tag开始 const fromTag process.argv[2] || (await $git describe --tags --abbrev0).stdout.trim(); const toTag ‘HEAD’; console.log(生成从 ${fromTag} 到 ${toTag} 的变更日志…); // 获取提交列表格式为”hash|author|date|subject” const gitLogFormat ‘%H|%an|%ad|%s’; const gitLogCommand git log --prettyformat:“${gitLogFormat}” --dateshort ${fromTag}..${toTag}; const logOutput await $${gitLogCommand}; const commits logOutput.stdout.trim().split(‘\n’).map(line { const [hash, author, date, subject] line.split(‘|’); return { hash: hash.substring(0, 8), author, date, subject }; }); if (commits.length 0) { console.log(‘此区间内无新提交。’); process.exit(0); } // 简单分类可根据实际提交规范优化如feat:, fix:, chore: const categories { feat: [], fix: [], docs: [], chore: [], other: [] }; commits.forEach(commit { const subject commit.subject.toLowerCase(); let categorized false; for (const [prefix, list] of Object.entries(categories)) { if (subject.startsWith(${prefix}:)) { list.push(commit); categorized true; break; } } if (!categorized) { categories.other.push(commit); } }); // 生成Markdown let changelog # 变更日志 (${fromTag} … ${toTag})\n\n; changelog **生成时间:** ${new Date().toLocaleString()}\n; changelog **提交总数:** ${commits.length}\n\n; for (const [category, list] of Object.entries(categories)) { if (list.length 0) { changelog ## ${category.toUpperCase()}\n\n; list.forEach(commit { changelog * **${commit.date}** [${commit.hash}] ${commit.subject} (by ${commit.author})\n; }); changelog ‘\n’; } } // 写入文件 import { writeFileSync } from ‘fs’; const filename CHANGELOG-${new Date().toISOString().split(‘T’)[0]}.md; writeFileSync(filename, changelog); console.log(✅ 变更日志已生成: ${filename}); console.log(‘各分类提交数量:’); for (const [category, list] of Object.entries(categories)) { if (list.length 0) { console.log( ${category}: ${list.length}); } }这个脚本展示了zx如何处理结构化文本git log输出、进行数据转换和聚合并最终生成一份报告。你可以轻松地扩展它比如解析JIRA issue key、关联PR信息、按照Conventional Commits规范进行更精细的分类等。5. 高级技巧、避坑指南与性能考量5.1 安全与Shell注入这是使用zx或任何执行Shell命令的库时最重要的一点。zx的$标签模板函数在解析参数时已经对直接嵌入模板字符串的变量进行了适当的转义这提供了基础的安全保障。安全示例const userInput ‘somefile.txt; rm -rf /‘; // 恶意输入 // 这样是安全的$会处理转义 await $ls -la ${userInput}; // 实际执行的命令类似于ls -la ‘somefile.txt; rm -rf /’危险示例const userInput ‘somefile.txt; rm -rf /‘; // 危险直接将未经验证的字符串拼接进命令 const dangerousCommand ls -la ${userInput}; await $${dangerousCommand}; // 这相当于执行了 ls -la somefile.txt; rm -rf /最佳实践始终将变量放在${}中让zx来处理转义。对于复杂的命令构建考虑使用参数数组形式虽然zx的$函数主要设计用于模板字符串但其底层支持传递参数数组。对于来自不可信源如用户输入、网络请求的数据在执行前必须进行严格的验证和清洗。5.2 错误处理与调试zx默认的行为是如果执行的命令退出码非零即失败它会抛出一个ProcessOutput错误并拒绝Promise。你需要用try...catch来捕获。try { await $git pull origin main; console.log(‘拉取成功’); } catch (p) { // p 是一个 ProcessOutput 对象包含 stdout, stderr, exitCode 等 console.error(命令执行失败退出码: ${p.exitCode}); console.error(错误输出: ${p.stderr}); // 根据不同的退出码进行不同处理 if (p.exitCode 128) { // git 常见错误码 console.error(‘看起来不是git仓库或远程地址有问题。’); } process.exit(1); // 脚本以失败退出 }调试技巧在命令前加上echo可以打印出将要执行的命令这在调试复杂命令拼接时非常有用。zx本身也提供了$.verbose选项但更简单的方式是const command ls -la ${someDir}; console.log(‘即将执行:’, command); await $${command};使用console.log或console.error输出中间变量和结果。对于长时间运行的命令你可能需要处理标准输入或实时输出。zx的$返回的Promise解决后才有完整输出。如果需要实时流式输出可以使用底层的spawn或考虑使用zx提供的其他选项如pipe。5.3 性能与并发zx命令默认是顺序执行的因为用了await。对于独立的、无前后依赖的命令可以使用并发来提升脚本速度。// 顺序执行慢 await $command1; await $command2; // 等待command1完成 // 并发执行快 const [result1, result2] await Promise.all([ $command1, $command2 ]); console.log(result1.stdout, result2.stdout);但请注意并发执行大量命令尤其是消耗大量I/O或CPU的可能会对系统造成压力需要根据实际情况权衡。5.4 跨平台兼容性处理虽然zx尽力提供跨平台支持但Shell命令本身存在平台差异。编写可移植脚本时需要注意命令可用性ls,grep,sed,awk在Unix-like系统上常见但在原生Windows CMD/PowerShell中不存在。zx在Windows下通常会尝试通过Git Bash或WSL来执行但这并非绝对可靠。路径分隔符使用Node.js的path模块zx已导出来处理路径连接而不是手动拼接字符串。import { path } from ‘zx’; const filePath path.join(‘some’, ‘dir’, ‘file.txt’); await $cat ${filePath};特定平台逻辑可以使用Node.js的os.platform()来判断操作系统从而执行不同的命令。import { os } from ‘zx’; if (os.platform() ‘win32’) { await $dir; } else { await $ls -la; }5.5 与现有工具链集成TypeScriptzx完美支持TypeScript。你可以直接编写.ts文件然后通过ts-node或先将TS编译成JS再运行。zx包自带了TypeScript类型定义能提供良好的代码提示。代码检查与格式化像对待普通Node.js项目一样使用ESLint和Prettier来规范你的zx脚本代码。纳入npm scripts将常用的zx脚本定义在package.json的scripts字段中是管理项目脚本的好方法。{ “scripts”: { “cleanup”: “zx ./scripts/cleanup-logs.mjs”, “deploy”: “zx ./scripts/deploy.mjs --envproduction” } }然后就可以用npm run cleanup或yarn cleanup来执行。6. 常见问题与排查实录在实际使用zx的过程中你可能会遇到一些典型问题。这里记录了我踩过的一些坑和解决方案。6.1 命令执行失败但错误信息不清晰问题执行await $some-failing-command“时脚本直接停止只看到一个ProcessOutput错误但不知道具体哪里错了。排查首先一定要用try...catch包裹可能失败的命令。在catch块中详细打印错误对象的属性try { await $some-failing-command; } catch (p) { console.error(‘exitCode:’, p.exitCode); console.error(‘stdout:’, p.stdout); console.error(‘stderr:’, p.stderr); console.error(‘message:’, p.message); }stderr通常包含了命令失败的具体原因。6.2 在管道pipe或重定向时遇到语法问题问题Bash中的管道|、重定向、在zx的模板字符串中可能需要特别注意。解决zx的模板字符串最终会传递给Shell解释所以大多数Shell操作符可以直接使用。但为了清晰和避免转义问题对于复杂命令可以将其赋值给一个变量。// 直接使用管道这是可行的 const filtered await $ps aux | grep node; // 重定向到文件 await $echo “Hello” output.txt; // 复杂的多命令组合可以考虑拆分成多个$调用或者使用Shell的 和 || await $command1 command2; // 如果command1成功则执行command2 await $command1 || echo “command1 failed”; // 如果command1失败则执行echo6.3 脚本在Windows上无法运行或行为异常问题在Windows上运行依赖Unix工具如grep,sed的zx脚本报错“command not found”。解决确保安装了Git for Windows并将其bin目录通常包含bash.exe,grep.exe,sed.exe添加到系统的PATH环境变量中。zx在Windows上会尝试使用这个环境。使用跨平台的Node.js模块替代如果可能用JavaScript代码替代Shell命令。例如用fs.readdirSync代替ls用字符串的includes或replace方法代替grep和sed。显式指定解释器在Shebang行或命令中可以尝试指定bash。// 在脚本中针对特定命令 if (os.platform() ‘win32’) { await $bash -c “grep ‘pattern’ file.txt”; }考虑使用WSL2对于复杂的、深度依赖Linux环境的脚本在Windows上使用WSL2是最一劳永逸的方案。你可以在WSL2的终端里直接运行zx脚本。6.4 如何处理需要交互式输入的命令问题有些命令如mysql -p提示输入密码rm -i提示确认需要从标准输入stdin读取交互式输入。解决zx的默认$执行器不适合复杂的交互式场景。对于这种情况你有几个选择使用非交互模式或提供参数许多命令支持通过参数或环境变量避免交互。例如mysql可以通过--passwordYOUR_PWD不安全或使用配置文件。使用zx的spawn或Node.js原生child_process对于必须交互的场景可以退回到使用Node.js的child_process.spawn并手动处理stdin.write和stdout.on(‘data’)事件流。重新设计流程思考是否真的需要交互。自动化脚本的目标应该是无人值守所以尽量寻找非交互的替代方案。6.5 提升脚本的可读性与可维护性当脚本越来越长时维护就成了挑战。提取函数将重复的逻辑或独立的步骤封装成函数。使用配置文件将路径、阈值、URL等配置项提取到外部的JSON或JS配置文件中。添加日志使用console.log、console.error记录关键步骤和结果。对于长期运行的脚本可以考虑写入日志文件。参数化通过process.argv接收命令行参数使脚本更灵活。const [,, sourceDir, targetDir] process.argv; if (!sourceDir || !targetDir) { console.error(‘用法: node script.mjs 源目录 目标目录’); process.exit(1); }添加JSDoc注释为函数和复杂逻辑添加注释说明意图和参数。我个人在大量使用zx编写部署、构建、数据备份等脚本后最大的体会是它并没有引入一个全新的概念而是用一种极其优雅的方式弥合了JavaScript世界和系统Shell之间的鸿沟。它让“胶水代码”变得不再难看和脆弱让你能更专注于业务逻辑本身而不是如何让两个不同的环境互相通信。对于任何需要频繁与操作系统交互的Node.js开发者来说zx都是一个值得放入工具箱的高效利器。开始可能会觉得有点新奇但用习惯了之后你可能就再也不想回头去写那些冗长的child_process.exec调用或者脆弱的Bash脚本了。