《js脚本编写教程》

凌晨三点，脚本教程我盯着控制台里那行红色的编写报错信息——Uncaught TypeError: Cannot read property 'length' of undefined。第七次了。脚本教程这行代码我明明照着MDN文档抄的编写，怎么还是脚本教程炸了？后来我才发现，问题出在API返回的编写数据结构上，后端在某个边界条件下根本没返回数组，脚本教程而是编写返回了null。那是脚本教程我第一次意识到，写JavaScript脚本，编写真正难的脚本教程从来不是语法，而是编写对数据流的掌控。

先别急着打开编辑器敲代码。脚本教程脚本和项目代码不一样，编写它像一把瑞士军刀，脚本教程要的是短小、精准、能解决问题。你得先问自己三个问题：这个脚本要处理什么数据？数据从哪里来？处理结果要送到哪里去？想清楚这三点，脚本的骨架就有了。比如我要批量重命名某个文件夹下的图片，那数据源就是文件系统，处理逻辑是正则匹配文件名，输出是修改后的路径。就这么简单。

真正动手时，别一上来就写几十行。拆成几个小函数，每个函数只做一件事。拿刚才那个重命名的例子来说：getFiles(dir)负责读目录，parseName(filename)负责解析旧名字，renameFile(oldPath, newPath)负责执行修改。每个函数不超过十行，出错了也好排查。你可能会觉得这样太啰嗦，但相信我，当脚本运行到一半报错时，你能直接定位到是读取还是解析还是写入出了问题，那种感觉比写一百行连在一起的代码爽多了。

处理异步是脚本编写里最容易翻车的地方。Node.js里几乎所有I/O操作都是异步的，你要是用for循环去遍历文件列表并逐个重命名，会发现循环跑完了，重命名还没执行。这时候得用Promise.all或者for...of配合await。我踩过最深的坑是忘了在异步回调里捕获异常，结果某个文件权限不够，整个脚本就静默失败了，还找不到原因。后来我习惯在每个异步操作后加.catch(console.error)，至少能知道哪儿炸了。

调试脚本有个土办法特别管用——在关键节点打印日志。别用console.log输出那种"step1 done"之类的废话，要输出具体的数据快照。比如处理到第几个文件了、当前文件名是什么、转换后的新名字是什么。这些信息比任何调试器都直观。我有个习惯，在脚本开头加个const DEBUG = process.env.DEBUG === 'true'，然后所有日志都包在if (DEBUG)里，这样平时运行不会刷屏，出问题时开个环境变量就能看到全过程。

再聊一个实用技巧：善用process.argv接收命令行参数。别把路径写死在代码里。这样你写一个脚本，就能复用到不同场景。比如node rename.js ./images，脚本里用const dir = process.argv[2] || '.'，没传参就默认当前目录。这个习惯帮我节省了大量改代码的时间——同一个脚本，换个目录就能跑。

最后说点个人的偏执。写完脚本后，我会故意用错误的方式跑一遍：传一个不存在的路径、传一个空文件夹、传一个包含特殊字符的文件名。脚本能优雅地报错并退出，而不是抛出一堆看不懂的堆栈信息，这才算合格。毕竟脚本是给人用的工具，不是给机器看的艺术品。

对了，写脚本时记得加#!/usr/bin/env node这行shebang，然后chmod +x，这样你就能直接在终端里像执行命令一样运行它，而不是每次都要敲node xxx.js。小细节，但体验提升巨大。

行了，思路有了，函数拆了，异步处理了，日志加上了，参数也接好了。剩下的就是动手写。别怕报错，报错是脚本在跟你说话。