企业官网建设流程全解析

手头几十个 Altium Designer 工程目录里，几乎整齐划一地躺着一个 History 文件夹。这玩意儿是 AD 自动保存历史快照时生成的，平时存在感很低，可一旦你要批量拷贝工程、打包发给板厂、或者把旧项目归档到服务器，它就成了最碍事的角色——里面尽是些碎小的历史版本文件，数量动辄上千，体积随随便便几百 MB，个别老项目甚至能到 1GB 以上。

这篇文章就是围绕“批量删除 AD 生成的 History 文件夹”这个主题写的。我会把 Windows 资源管理器搜索、批处理脚本、PowerShell 三种清理路线都讲一遍，附上可以直接抄的代码，再把删除前必须确认的安全边界、以及我踩过的中文路径、长路径、文件占用这些坑一并整理出来。适合经常交付 AD 工程、维护历史项目档案、或者单纯被磁盘空间逼到墙角的朋友参考。

1. 先把History文件夹的来历弄清楚，再决定怎么删

1.1 为什么每个AD工程都容易长出这个目录

用 Altium Designer 做过几轮原理图、PCB 迭代的人都知道，工程目录下会自动多出一个 History 文件夹。AD 在保存文档、编译工程、生成输出文件时，会悄悄把“改动前的快照”或“产生的新日志”复制一份进去。你可以把它理解成 AD 自带的版本后悔药：今天的走线方案改坏了，还能从本地历史里翻出昨天那一版。

这套机制本身不坏，坏就坏在它太勤快。只要你的工程一直在改，History 文件夹就会不停长肉。文件命名通常是“原文件名_日期时间_随机字符.SchDoc / .PcbDoc”这种格式，又长又多。我见过一个用了五年多的老工程，History 文件夹里有某个 PCB 文件的几百个历史快照，大小直奔 1.5GB。最气人的是，你平时压根不会打开它，纯粹占地方。

顺带一提，这里说的 AD 是指电子设计软件 Altium Designer，不是 Windows 域环境里的那个 AD。如果你是想清理域环境下用户漫游配置文件里的历史记录，那是另一套思路，不在本文范围内。

1.2 删除History到底影响什么，什么情况下不该删

先说结论：删除 History 文件夹对当前工程几乎没有任何伤害。你的原理图、PCB、元件库的当前版本都好好地躺在工程目录里，制板要用的 Gerber、坐标文件、BOM 也都不在这里。这个文件夹不属于交付物，删掉之后工程文件照样打开，照样出图。

真正受影响的是“历史版本回溯”能力。AD 的本地历史面板里，那些旧版本快照就是从这个文件夹读取的。如果你正处于方案反复调整的阶段，今天想对比三天前的某段走线，那先别急着删。另外，如果公司有客户审计、批量投板后需要回溯原始工程记录这样的要求，也建议不要直接物理删除，最好先把整个工程连 History 一起压成压缩包存进冷备盘，再做清理。

我个人的建议是：History 文件夹属于“可再生的临时产物”，它的价值在项目完成那一刻就开始衰减。项目交付并稳定生产之后，它就不再是不可或缺的资产，而是纯粹的包袱。

2. 批量删除实操：三种清洗路线一次讲透

2.1 资源管理器搜索：适合小批量的快速方案

如果你手头只有十几个工程，目录结构也不深，直接用 Windows 资源管理器就能解决。

在存放 AD 工程的根目录搜索框里输入：

type:folder History

这个语法的意思是：只看文件夹，只看名字里带 History 的那些。搜索结果出来后，按“类型”列确认选中的都是文件夹，然后全选删除即可。如果你把工程按年份或客户分在多层目录里，只要搜索起点设置到最上层总目录，Windows 也会递归往下找。

这个方法有两个明显限制。一是 Windows 搜索依赖索引，如果目录在共享盘、移动硬盘或者被排除了索引的位置，结果可能不全，你以为删干净了，其实还有漏网之鱼。二是删除前不方便看每个文件夹的大小，只能多选后看属性。所以它适合“快速清一波”，不适合需要精确确认的归档场景。

2.2 bat脚本：一个命令递归清掉所有History

要覆盖几十个甚至上百个工程，最稳的做法是用批处理递归遍历，把指定根目录下所有名叫 History 的文件夹全部揪出来删掉。

在工程根目录上右键新建一个文本文件，改成clean_history.bat，内容如下：

@echo off setlocal enabledelayedexpansion set "ROOT=D:\Projects\AD" set "LOG=%~dp0clean_history.log" echo === Start %date% %time% ===>>"%LOG%" for /d /r "%ROOT%" %%i in (History) do ( echo Delete: %%i echo %date% %time% %%i>>"%LOG%" rd /s /q "%%i" 2>>"%LOG%" ) echo === Done ===>>"%LOG%" pause

逐行解释一下关键点。set "ROOT=D:\Projects\AD"是扫描起点，改成你自己的工程存放目录就行。for /d /r负责递归往下找所有目录，括号里的History是目标目录名；%%i就是匹配到的完整路径。rd /s /q "%%i"是递归删除目录及里面所有内容，/q表示不弹确认信息。

这里有个新手必踩的坑：在 cmd 窗口里直接敲命令时用%i，保存成 .bat 文件运行时要写成%%i。写反了会出现各种奇怪报错。强烈建议先把删除动作换成 echo 跑一遍预览：

for /d /r "D:\Projects\AD" %%i in (History) do echo %%i

这样只列路径不删除，先把匹配列表过一眼，确认都是 AD 工程目录再执行正式删除。

2.3 PowerShell脚本：更优雅、带日志、还能试删

如果你更习惯 PowerShell，下面这个脚本更皮实，对中文路径和特殊字符的处理也更好：

$root = "D:\Projects\AD" $log = "D:\Tools\clean_history.log" Get-ChildItem -LiteralPath $root -Directory -Recurse -Filter "History" | ForEach-Object { $path = $_.FullName Write-Host ("Delete: {0}" -f $path) Add-Content -LiteralPath $log -Value ("{0} {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $path) Remove-Item -LiteralPath $path -Recurse -Force }

简单说明几个设计思路。用-LiteralPath而不是-Path，是为了防止工程目录名里带[ ]这类通配符字符时被误解析；-Filter "History"在文件系统层直接过滤，比把所有目录拉回来再Where-Object筛选快很多；Remove-Item -Recurse -Force能处理只读文件。

正式删之前，建议先跑一行统计命令，看看总数是多少：

(Get-ChildItem -LiteralPath $root -Directory -Recurse -Filter "History").Count

如果数字和你预期一致，再执行删除。清理完再跑一次这个命令，结果为 0 就说明全部删完了。这比肉眼检查靠谱得多。

三种方式各有各的适用场景，我做了一张简单的对比表：

3. 动手前必须确认的安全边界，别一股脑删到底

3.1 先关闭AD再动手，否则删除会中途卡壳

这个顺序问题我翻过车。AD 在后台是会持续写文件的，尤其是大的工程打开状态下，History 文件夹可能正被占用。这时候跑删除脚本，常会遇到“另一个程序正在使用此文件，进程无法访问”的报错。目录删了一半、剩一半，看着更难受。

所以清理前先彻底退出 Altium Designer，顺手打开任务管理器确认一下进程列表里没有 DXP.exe 之类的 AD 相关进程。注意有些后台组件不会随着主窗口关闭而立刻退出，等几秒或者手动结束一下最保险。

3.2 物理删除不进回收站，后悔药得自己留

rd /s /q和Remove-Item -Recurse -Force都是物理删除，不过回收站，删完就没有了。我第一次给同事推荐脚本时，特意强调过这一点：这不是 Windows 里按 Delete 那么温柔，是连根拔起。

如果你心里没底，可以先对整个工程根目录做一次压缩备份，再跑清理脚本。另一种做法是用 PowerShell 调用回收站接口，把 History 文件夹送进回收站而不是物理抹掉：

Add-Type -AssemblyName Microsoft.VisualBasic [Microsoft.VisualBasic.FileIO.FileSystem]::DeleteDirectory($folderPath, 'OnlyErrorDialogs', 'SendToRecycleBin')

注意这种方式的删除速度比物理删除慢很多，批量大时回收站空间也可能不够。我一般只在第一次帮别人清理时用它，让同事多一道后悔药；自己日常清理就直接物理删。

3.3 严格圈定扫描范围，别扫到C盘根目录去

脚本里的 ROOT 路径是生死线。有次我在一台机器上调试脚本，随手把 ROOT 写成了C:\，预览列表一出来，好家伙，里面蹦出来一堆非 AD 工程产生的 History 目录，比如某些开发工具缓存、数据库临时目录，甚至 Windows 自带功能的备份目录。如果直接删下去，误伤范围不可控。

所以脚本设计上最好把 AD 工程统一放在一个固定根目录下，比如D:\Projects\AD，然后只扫这一层。宁可多跑几个根目录，也别图省事直接扫盘符。删除前强制输出一遍匹配列表，看路径是不是都指向“工程根目录\History”这种结构，再决定是否继续。

3.4 小心同名文件夹陷阱

History 是个很通用的名字。Windows 的某些备份特性、Python 环境、git 工具的缓存目录里都可能出现同名文件夹。脚本只认名字不认爹，所以我在脚本里加了日志，每次删除前都会把完整路径记下来。如果删完后发现某条路径压根不是 AD 工程的，那也是事后能查的。

最稳妥的做法：在脚本启动后先进入预览模式，把所有匹配路径输出到屏幕和日志文件，人工扫一眼，确认没有非预期目录，然后再正式删除。这个习惯我保持了很长时间，至今没再误删过别的东西。

4. 高频踩坑记录：中文路径、长路径与只读文件

4.1 中文路径在bat里乱码，这是我翻过最狠的车

AD 工程目录很少是纯英文的，大多数同事会按“项目名_客户名”建文件夹，中文是常态。批处理脚本如果保存编码不对，中文路径会被 cmd 按 ANSI 代码页错误解析，脚本跑完，日志里记录的全是乱码，看着像删了，实际上匹配不到任何目录。

解决方法有两个。一是把 .bat 文件用记事本“另存为 ANSI”编码保存，在简体中文系统上就是 GBK，这时候中文路径基本正常。二是干脆放弃 bat，用 PowerShell 跑清理，PowerShell 对 Unicode 的支持好很多，中文路径一般不容易出问题。

如果你一定要用 bat，又不想被编码折磨，可以在 bat 里不写死中文路径，改成拖拽目录到脚本图标上执行，让它用%~1拿路径参数。这样脚本文件本身是纯 ASCII，中文路径由系统通过参数传进来，乱码概率会小很多。

4.2 深目录长路径删不动的解法

AD 的历史文件名真是又长又怪：原始文件名、日期、时间、随机字符全拼在一起，很容易让文件完整路径超过 Windows 的 260 字符限制。删除时报“文件名或扩展名太长”，一连串文件卡在那，脚本显得很无力。

遇到这种删不动的目录，我常用的兜底方案是 robocopy 空目录镜像法。先建一个空目录，再用 robocopy 把目标目录镜像成空目录：

mkdir D:\empty_tmp robocopy D:\empty_tmp "D:\Projects\AD\某工程\History" /MIR rmdir /s /q D:\empty_tmp

/MIR会把源目录（空目录）镜像到目标目录，使目标目录内容和源一致，也就是把目标目录里的文件全部清空。清空之后，剩下的就是个空壳目录，再正常删除就简单多了。这个方法对很多顽固目录都有效，不只是 AD 的 History。

如果你的 Windows 环境允许，从系统层面打开 Win32 Long Path 支持也能解决问题，但这属于系统配置变更，在部分公司电脑上未必有权限操作。相比之下，robocopy 方案不涉及系统设置改动，更通用。

4.3 只读文件、占用文件导致删除半途而废

History 里偶尔会有被 AD 打上只读属性的文件，或者文档在某个后台进程里被短暂占用。Remove-Item -Force能对付只读，但对付不了进程占用。如果批量删除过程中遇到占用文件，脚本会报错，但不会把整个目录删得乱七八糟，只是留下一个残缺目录。

所以我的习惯是：脚本日志里记录错误信息，跑完一遍之后，再重跑一次。由于脚本本身是幂等的，不存在的目录自然会被跳过，只有那些上次失败的目录会再次被处理。对绝大多数历史文件夹来说，AD 退出后重跑一次基本都能清理干净。

4.4 删除之后怎么验证是不是真的干净了

验证这步别省。最简单的验证命令是用 PowerShell 再数一遍：

Get-ChildItem -LiteralPath $root -Directory -Recurse -Filter "History" | Select-Object FullName

如果输出为空，说明干净了。还可以在清理前后各看一次磁盘可用空间：

Get-PSDrive D | Select-Object Used, Free

对比数字更直观，也方便你向同事或上级证明清理效果。别只盯着任务管理器看，它显示的是全局，没法精确到某个工程目录。

5. 治本思路：让AD少生成历史，给脚本留点后路

5.1 调低本地历史保留份数，从源头控制膨胀

清理脚本再好用，也只能治标。AD 的本地历史机制是默认开启的，如果你不管它，History 文件夹迟早长回来。

在 AD 的 Preferences 设置里，直接搜索 Local History，就能找到本地历史相关配置。里面通常能设置保留的版本数量。我习惯把保留份数压到 3~5 份，日常画板够用，文件夹体积也能控制在一个相对理性的范围。不同版本的 AD 菜单位置会有差异，但搜索 Local History 基本都能定位到。

5.2 把历史目录移出工程目录，工程结构立刻清爽

有些版本的 AD 允许你自定义本地历史记录文件夹的存放位置。如果条件允许，可以把历史目录统一指向工程目录之外，比如%LOCALAPPDATA%\Temp\ADHistory或者某个专门放临时文件的盘。

这样做的好处是：工程目录里永远不会出现 History，批量拷贝、打包交付时少一个心病；历史文件仍然存在，真需要回溯时还能找到。代价是历史文件分散在工程外，平时看不到，清理依赖一个独立的历史目录管理策略。这个方案不是所有版本都支持，配置前先确认一下自己的 AD 版本。

5.3 版本控制系统统一忽略History，别让它污染仓库

如果你的工程用 Git 或 SVN 管理，History 目录是最容易污染仓库的东西之一。各种历史快照一旦提交进版本库，仓库体积会飞速膨胀，同事克隆的时候哭都来不及。

Git 工程就在.gitignore里加一行：

History/

SVN 项目可以对 History 目录设置忽略属性。这一步是治本，能让团队协作时的仓库长期保持干净，也和批量删除脚本形成配合：仓库层面拦住新文件，脚本负责清理历史遗留。

5.4 给脚本加点参数，做成能长期用的清理工具

最后建议别把删除脚本写成一次性的东西。稍微改造一下，就能变成一个能反复用的工具。

先加根目录参数支持：双击运行时用默认目录，拖拽某个工程目录进来时扫描拖进来的目录：

@echo off if "%~1"=="" ( set "ROOT=D:\Projects\AD" ) else ( set "ROOT=%~1" )

再加一个 dry-run 开关，比如用--check参数控制只列路径不删除。这样每次清理前先预览一遍，确认无误再正式执行，基本不会出幺蛾子。日志文件保留每次删除的完整记录，万一后面要追查哪个工程的历史被清了，翻日志就知道。

最后分享一点个人体会。清理 History 文件夹这事，本质上不是“删一次就完”，而是要把生成策略、版本管理、归档流程串起来。我现在每个季度末固定做一次归档清理，跑之前一定先确认 AD 彻底退出、任务管理器里没有 DXP.exe，再进入预览模式核对一遍路径清单，确认无误后才真正删除。唯一一次翻车就是 AD 还开着的时候强行清理，中途报了几十个占用项，清理不干净，最后还是重跑搞定。把脚本变成习惯，比记住某个命令重要得多。