wudi61600963

代码写得有问题看不明白具体需求：

· 为什么要从 导出.txt 中导出注册表到 导出.reg？
· 为什么要用 type 语法将 导出.reg 中内容复制到 备份.reg？
· 之后 导出.reg 要删除的话，为什么不直接导出至 备份.reg？
---------------------------------

想优化就要简化需求，如果是导出某项注册表的话：

reg export 注册表项 备份.reg
复制代码

如果下面还有其他操作暂时用不到 备份.reg 的话可以“多线程”放到后台处理：

start/B reg export 注册表项 备份.reg
复制代码

加速导出单个注册表大项可以考虑拆分并创建多个“多线程”来加速处理：

for %%# in (注册表项1 注册表项2 ...) do start/B reg export %%# 备份_%%#.reg>nul
复制代码

wudi61600963

个人认为应该先了解下语法（以及执行效率），在语法可实现范围内整理思路找到最优解会比较好。
· 避免被覆盖可以从名称上着手，例如在文件名上加入 %random% 或 %time% ；
· 禁用覆盖提示添加 /y 参数（不用提示就强行覆盖现有文件）；
· type 语法会按行读取文本内容，对于复制内容场景效率极低，同类办法有复制（copy）、移动（move）、重命名（rename），当然最高效的方案是不进行任何操作。


实现“多线程”的方法有很多，因为不清楚具体的应用场景和设备性能，以及有多追求速度，所以提供一些思路：
· 以最多线程并发导出（在大规模项目中会造成卡顿甚至宕机）

@echo off
pushd "%~dp0"
setlocal enabledelayedexpansion
for /F %%# in ('type 导出.txt') do start/B reg export %%# 导出_!random!.reg>nul
复制代码

· 添加控制降低并发数

@echo off
pushd "%~dp0"
setlocal enabledelayedexpansion
set "control0=start/B"
for /F %%# in ('type 导出.txt') do set/an+=1&%control!n:~-1!% reg export %%# 导出_!random!.reg>nul
复制代码

或是可以先获取注册表项并存储在内存中（通过变量存储），待查询全部结束后将变量一齐写入等

wudi61600963

回复 7# aceamuro


    我修改了上面的代码，再次尝试。

wudi61600963

6 楼的代码是为提供思路而准备的范例（解决被覆盖问题），并非为楼主项目而量身定制的现成代码，楼主应该按照自己的实际需求进行修改寻求最优解，不应一点不改拿来用。

此外个人认为应该先了解下批处理语法，多使用搜索功能（关键字：“批处理 合并文件”），楼主现在的情况对基础语法不熟悉（例如 copy 合并文件的用法），很难继续写下去。

wudi61600963

回复 11# aceamuro


    优化效率来说越底层，需要操作的内容越少越单纯效率越高。
    type 语法按行读取，copy 则按文件，因此 copy 的效率会更高，具体差距可以写一个计时脚本来验证，在大项目中差距明显。

    多线程操作可以增加效率，但自身也会引入一些新的隐患，例如楼主项目中出现某些意外情况新的"线程"的文件还没处理完，主线程就开始执行 copy 操作，就会造成合并的文件不完整，因此对于时间的把握要恰到好处，最好有一些冗余或者增加一个验证。
    此外，批处理没有类似于其他语言（例如C、.net 等）的操作底层语法，追求更高效的话加入 powershell 也是不错的选择。

wudi61600963

大概率不会出什么问题，但正如之前所说，出现了意外情况（I/O 阻塞、单项注册表过大或是其他原因）则会最终造成不完整合并，因此属于存在隐患的“非可靠设计”。

增加可靠性的方法也有很多，例如当全部执行完成后对文件/文件大小/文件数量进行验证，或者是对文件是否正被使用进行验证（正在写入的文件无法通过验证）、收集导出日志/错误日志来核对等等。

从结构上也可以参考面向对象语言的封装结构进行设计。
使用 || 语法可以判断语句是否执行成功，但使用 start/B 会改变执行判断标准，使其成为是否成功执行了 start/B 语句。因此可以设计一个封装模块，实时报告进度，或是无论成功失败都创建一个信号，那么根据信号就可以掌握执行结果了。

当然并非“非可靠设计”就一定不行，找到执行边界（例如单项注册表最大可以多大、执行环境中最多耗时多久等），优化判断和超时时限令边界情况几乎不可复现也不失为一种选择。

wudi61600963

回复 23# aceamuro

花时间仔细琢磨一下上面写的内容，查资料、对比不同方案、做减法、反复进行耗时测试会很容易找到更高效的解。
因此现阶段单纯改代码意义不大，代码会随着思想成长、方案优化而变化。
当楼主靠自身能力无法继续优化时拿出来大家一同修改会更高效。