shot-scraper 1.11 发布了。官方说明写得很朴素:几处小改进,围绕命令参数一致性,外加一个等待机制的修复。
这个等待机制值得单独说。它之前的server检测很粗暴:不管本地开发服务器有没有真正启动完,固定等1秒就开始截图或录像。服务器慢半拍,直接对着白屏拍下去。1.11把这个死板的1秒,换成了轮询端口连接、最多等30秒。
这次改了什么
| 项目 | 旧行为 | 新行为(1.11) |
|---|---|---|
| server等待 | 固定等1秒 | 轮询端口,最多等30秒 |
| JS脚本加载 | 只能用--javascript传字符串 | 新增--js-file,支持文件/标准输入/gh:username/script |
| multi的YAML配置 | 无对应key | 新增js_file: key |
| timeout参数 | javascript、html命令缺失 | 补齐--timeout,与其他命令一致 |
server等待机制被shot-scraper multi和shot-scraper video共用。--js-file覆盖shot-scraper、pdf、html、accessibility、har五个命令。
受影响的主要是两类人:用命令行做网页截图、录制演示视频的开发者;把这个工具塞进CI、文档生成或产品演示流水线的技术团队。这类人最先感知到升级前后的差别。
为什么"等1秒"值得单独修一版
固定1秒在开发者自己机器上多半够用。换到CI环境,冷启动、依赖安装、端口占用检测,随便一项都能把这1秒吃掉。
轮询到30秒,本质上是把"赌服务器够快"换成"确认服务器真的活了"。这不是性能提升,是把一个隐性失败点变成显性等待逻辑。
如果你的CI脚本原本靠这固定1秒去掐时间点,比如做限流或者顺序控制,升级后行为会变。升级前最好翻一下issue #197,确认自己没依赖这个副作用。
--js-file和--timeout两处改动方向一致:让命令参数命名和行为互相对齐。以前想传JS代码,只能用--javascript把字符串塞进命令行,写复杂脚本很别扭。现在可以从文件读、从标准输入读,甚至从gh:username/script拉取。timeout补到javascript和html命令,减少的是用户去记"哪个命令支持哪个参数"的负担。
接下来该看什么
不是每个小版本都值得单独写。这次值得写,是因为它代表了CLI工具走向成熟的一条具体路径:不堆新功能列表,把边界条件一个个填平。
真正该观察的变量,是shot-scraper后续会不会继续做这类一致性修补。如果再过几个版本,各命令的参数命名、超时行为、重试逻辑都对齐了,这工具会比多数同类CLI更适合长期塞进自动化流水线。如果之后转头去堆新功能,却放着这类一致性问题不管,那就说明维护重心变了。
小工具真正值钱的地方,往往不是功能堆得多,而是边界条件留得少。