#批处理脚本
该话题下聚合了社区中所有标记为「批处理脚本」的公开帖子。
给同事批处理装完软件顺手做了个开机项审计，揪出四个没用的自启动
2026/11/3上周帮隔壁组批量装一批工具软件，装完照例跑一遍自己的检查脚本。这次重点是开机自启动项。 我写了个批处理，用 wmic startup get caption,command,location 拉全量启动项，再跟装软件前的基线快照 diff。装之前先跑一次存成 baseline.txt，装完再跑一次，
打印机驱动装完每台都手动改端口，我写了个批处理省下半天活
2026/11/2上周给办公楼三层换一批新打印机，六台同型号，按老规矩先把驱动盘和安装包拷到样机上跑两天。结果样机没事，批量装到第五台的时候发现个怪事：每台装完端口都默认跳到 USB001，得手动改成 IP 端口，一台一台点，六台机器我蹲那改了半个钟头。 我这人最烦这种重复劳动，二十年前刚干运维那会儿，给整个机房重装
批处理按日期切分日志，我加了行数预检才敢自动删旧包
2026/10/22先别急着吹自动化，切分脚本翻过车 之前写了个批处理，每天凌晨把 logs/ 下超过 7 天的 .tar.gz 按日期切分归档，顺手删掉源包。逻辑看着没问题，结果有一次一个日志包被下游程序写坏了，tar -tzf 直接报错，for /f 把错误信息当文件名，差点把当天正在写的日志目录给删了。 从那以后
日志包按日期切分后，我拿批处理脚本把每月整理时间压到十分钟
2026/10/21先说结论：日志包这东西，别指望一款工具全包，我现在是「入库用 Win解压缩、跑脚本用 7-Zip 命令行」，分工明确，谁也不耽误谁。 场景 我们后端服务每天凌晨滚一个日志归档，一个月下来二十几个包，单个 200M 到 1.5G 不等，里面还有嵌套的旧包。以前我是手动一个个解，解完再按日期挪文件夹，遇
7-Zip批处理解压日志包，-mmt开满反而更慢，我拿两台机器掐了三天
2026/10/21上周发过一帖聊 -mmt 核数取舍，评论区有人问具体怎么测。这周我拿两台机器把参数组合全跑了一遍，数据列出来，省得大家继续拍脑袋。 测试环境 A机：i7-12700H，16G，NVMe，Win11 23H2，7-Zip 24.08 B机：i5-10400，16G，SATA SSD，Win10 22H
实测：7-Zip命令行并发解压，-mmt参数开多少核才不浪费CPU
2026/10/20平时部署包和日志包都是批量解，脚本里一直用 7z 命令行，但 -mmt 这个参数我从来没细究过，默认给多少就用多少。前两天一台 8 核的构建机解一个 30GB 的日志分卷包，CPU 只跑到 40%，解压花了 11 分钟，我觉得不对劲，就抽空把参数挨个掐表对了一遍。 测试环境 机器 A：8 核 16G
把Win解压缩塞进批处理脚本，我踩了三个坑才搞明白它不支持管道
2026/10/19昨天想偷个懒，把日志压缩包的解压流程写成批处理，结果在Win解压缩上直接卡住了。 背景：每天要处理几十个部署包，手动右键解压太慢，想写个脚本循环调用命令行。之前用 7-Zip 的 7z x 跑得好好的，想着 Win解压缩 速度确实快，试试能不能替上。 测试环境：Win10 22H2、Win11 23