简介这款Winform定时自动删除指定文件夹下文件的应用程序面向需要定期清理日志、临时文件或过期资料的Windows用户与运维人员。基于.NET 3.5框架开发支持按文件日期、前后天数、后缀名、文件大小及系统时间结合删除天数等多种条件灵活筛选例如设置90天可自动清除当前时间90天前的旧日志同时保留90天内的文件所有删除操作均记录至C盘日志目录并通过XML文件方便增删可删除的后缀名列表。程序仅适用于Windows环境压缩包共3个文件包含可直接运行的exe、调试符号pdb及系统配置xml整体仅46KB轻量便捷。目前已有1260人学习下载适合需要自动化维护磁盘空间、减少手动删文件操作的中级以上Windows用户。使用者可直接打开exe选择目标文件夹并配置条件借助界面查询或删除文件有效提升日常文件管理效率。1. 先搞清楚它在解决什么问题定时自动删除指定文件夹下文件适合谁用项目现场听得最多的一句话就是「C盘又满了」。临时文件、过期日志、下载缓存堆在指定文件夹里越攒越多。手动清理费时间任务计划程序加批处理又太僵——没法按文件年龄判断、不留删改记录、误删了只能拍大腿。于是我用WinForms写了一个定时自动删除指定文件夹下文件的小程序设好路径和保留天数到点自动清一次界面能看到删了什么、下次什么时候执行。它解决的痛点是「磁盘要定期收拢但人不该每天手动盯目录」。适合两类人一类是给公司内网机器做磁盘空间治理的运维或开发另一类是自己电脑上有个目录常年膨胀、想定时收拢的桌面用户。新手按第3章的代码能直接跑起来老手重点看第5章的边界参数和踩坑。2. 需求拆解与选型为什么是WinForms而不是任务计划程序加批处理2.1 需求拆解一个自动清理工具真正要管的六件事很多人看到「定时自动删除指定文件夹下文件」第一反应是写个批处理丢进任务计划程序不就行了真做过的人会告诉你任务计划程序能管的只有「到点运行」管不了之后的事。这个需求真正要回答的问题有六个第一删除策略。不是所有文件都该删至少得支持「只删最后写入时间超过N天的文件」否则会把正在生成的日志、刚下载一半的压缩包一起干掉。第二路径边界。删除操作要锁定在指定文件夹内防止配置写错或者用户误操作把整个盘扫了。第三运行方式。是每天定点清理还是每隔几小时清一次两种模式的实现差别很大。第四可视化。用户要能看到当前配置、下次执行时间、最近一次删了哪些文件。第五异常处理。文件被占用、没有权限、目录不存在这些要逐条记录而不是静默失败。第六误删防护。至少要有扩展名白名单和「最小存活时间」两个兜底。把这六件事列出来「任务计划程序批处理」就明显不够用了批处理的日期比较逻辑在Windows下写起来很绕删没删成功只能靠cmd的黑匣子输出双击误跑一次就等着哭吧。2.2 技术选型WinForms的适用边界与定时器选择先说结论内部工具的自动化清理程序WinForms比Windows服务更合适。Windows服务的部署需要installutil或者sc create调试要挂会话对普通运维不友好WinForms程序双击能跑、能看界面、能调参数发布成一个exe拷到目标机器就行。市面上的自动删除文件软件大多是闭源的删除策略不透明出了问题没人能解释为什么删了某个文件自己维护的这一套每一行删除动作都有日志可查。网上搜winform项目案例大多也是这种「小而完整」的桌面工具因为这个框架的定位本来就是快速交付内部应用。定时器选择是个容易被忽略的点。System.Windows.Forms.Timer依赖UI消息循环回调执行在UI线程如果清理大目录卡了几秒界面会直接假死而System.Threading.Timer回调跑在线程池线程不卡界面但回调里访问控件必须用Invoke或BeginInvoke。做这个工具我一般选用System.Threading.Timer因为删除大目录是长时间操作UI线程绝不能阻塞代价是回调里多几行Invoke代码。界面侧就按WinForms标准控件排文件夹选择用FolderBrowserDialog保留天数用NumericUpDown模式切换用ComboBox日志用ListView而不是TextBox否则文件一多控件会卡成PPT。这个需求的控件属性其实没几页「控件属性大全」能覆盖真正花力气的在业务层。顺带一提如果你只是想要电脑定时重启本身有shutdown命令配合任务计划程序就够了不需要这种带文件年龄判断的删除逻辑。需要这个工具的场景一定是对「哪些文件能删、哪些不能删」有要求的。2.3 项目骨架创建一个最小的WinForms工程创建工程的方式看你的环境。装了Visual Studio的直接新建「Windows 窗体应用(.NET Framework)」项目框架选4.7.2习惯命令行的用.NET 6/8的SDK来建dotnet new winforms -n FolderCleaner cd FolderCleaner dotnet build.NET 6以上的WinForms项目默认在csproj里启用了UseWindowsFormstrue/UseWindowsForms这点和.NET Framework时代不一样。Framework版本刻意用4.7.2的原因是企业内网老机器一般都有这个运行时不用额外装.NET桌面运行时如果走dotnet新项目路线发布时记得带自包含参数否则目标机器得先装对应版本的桌面运行时。项目结构我习惯分两个文件FormMain.cs只管界面交互FileCleanerService.cs管扫描和删除。后者不引用任何界面类型方便单独测试。下面先把服务层写出来这是整个程序的地基。3. 核心实现文件清理服务、定时调度与主窗体绑定3.1 文件清理服务按最后写入时间筛选后删除FileCleanerService.cs的核心逻辑如下。注意我用的是Directory.EnumerateFiles而不是GetFiles前者是延迟枚举目录里文件多时内存占用低using System; using System.Collections.Generic; using System.IO; using System.Linq; public class FileCleanerService { public void CleanFolder(string rootPath, int retentionDays, bool recursive, Actionstring log) { if (!Directory.Exists(rootPath)) { log?.Invoke($目标目录不存在跳过本次清理{rootPath}); return; } // 先算出时间阈值再枚举文件避免边遍历边判断时目录被外部改动 DateTime cutoff DateTime.Now.AddDays(-retentionDays); var searchOption recursive ? SearchOption.AllDirectories : SearchOption.TopDirectoryOnly; Liststring targets; try { targets Directory .EnumerateFiles(rootPath, *.*, searchOption) .Where(f File.GetLastWriteTime(f) cutoff) .ToList(); } catch (UnauthorizedAccessException ex) { log?.Invoke($没有权限访问目录{ex.Message}); return; } catch (DirectoryNotFoundException ex) { log?.Invoke($目录不存在或已被移走{ex.Message}); return; } foreach (var file in targets) { try { File.SetAttributes(file, FileAttributes.Normal); File.Delete(file); log?.Invoke($已删除{file}); } catch (IOException ex) { log?.Invoke($删除失败文件可能被占用{file}{ex.Message}); } catch (UnauthorizedAccessException ex) { log?.Invoke($删除失败无权限{file}{ex.Message}); } } } }这里有几个参数要重点说明。retentionDays是文件保留天数传7表示删除7天前最后写入的文件传0表示删除所有非占用文件我一般不允许传负数界面上的NumericUpDown最小值就设为0。用LastWriteTime而不是CreationTime是因为复制过来的文件创建时间很新但内容可能是半年前的按最后写入时间更贴合「这个文件还有没有在被使用」的判断。SetAttributes到Normal这一步不是多余的只读文件不处理直接Delete会抛UnauthorizedAccessException。注意这里没有递归删除目录本身。空目录会残留但不占空间需要连目录一起清理时务必先排除ReparsePoint见5.3。3.2 定时调度两种运行模式与防重入设计调度层我放在FormMain里用一个System.Threading.Timer加一个计算首次延迟的方法。运行模式在界面里二选一每隔N小时或者每天定点。private System.Threading.Timer _cleanTimer; private bool _isCleaning; private DateTime _lastCleanAt; private void StartCleanTimer() { var interval TimeSpan.FromHours(_intervalHours); var dueTime GetFirstDelay(); if (_cleanTimer ! null) _cleanTimer.Dispose(); _cleanTimer new System.Threading.Timer(TimerCallback, null, dueTime, interval); } private TimeSpan GetFirstDelay() { if (_runMode CleanMode.EveryInterval) return TimeSpan.FromHours(_intervalHours); // 每天定点模式算出距离下一次执行还有多久 var now DateTime.Now; var nextRun DateTime.Today.Add(_scheduledTime); if (nextRun now) nextRun nextRun.AddDays(1); return nextRun - now; } private void TimerCallback(object state) { if (_isCleaning) return; // 上一次还没结束就直接跳过本次 _isCleaning true; try { BeginInvoke(new Action(() SetStatus(清理中...))); _service.CleanFolder(_targetPath, _retentionDays, _recursive, AppendLog); _lastCleanAt DateTime.Now; BeginInvoke(new Action(UpdateNextRunLabel)); } catch (Exception ex) { AppendLog($清理过程出错{ex.Message}); } finally { _isCleaning false; } }GetFirstDelay的逻辑是定时调度的核心。每隔N小时模式直接以interval作为首次延迟第一次运行发生在启动后interval时长每天定点模式要算出「下一个执行时间点」如果今天的点已经过了就推迟到明天。有一个隐藏问题如果机器在计划执行时间处于睡眠或关机状态醒来后System.Threading.Timer不会补执行只会顺延到下一个周期。要补齐的话可以在窗体Load事件里检查_lastCleanAt是否落后于预期落后就立即触发一次清理这个逻辑要看你的场景是否需要。回调里的BeginInvoke是重点。System.Threading.Timer的回调跑在线程池线程直接改Label或ListView会抛跨线程异常BeginInvoke把动作封送到UI线程。_isCleaning这个标志位是必须的因为删除大目录可能超过定时周期没有它第二次回调会和第一次并发执行两个线程同时删同一个文件日志会乱成一锅粥。实际生产代码里可以给这个字段加volatile或者直接用Interlocked看团队习惯。3.3 主窗体绑定文件夹选择、参数校验与日志展示界面部分我按从上到下的顺序排目标路径一行TextBox加「浏览」按钮保留天数一行NumericUpDown运行模式一行ComboBox加NumericUpDown/DateTimePicker然后是一排操作按钮启动、停止、立即清理最下面是日志ListView。private void BtnBrowse_Click(object sender, EventArgs e) { using (var dialog new FolderBrowserDialog()) { if (dialog.ShowDialog(this) DialogResult.OK) { txtPath.Text dialog.SelectedPath; // 启动前先校验路径可写减少运行时才发现权限问题的概率 if (!IsDirectoryWritable(dialog.SelectedPath)) { MessageBox.Show(当前用户对该目录没有写权限清理可能失败。, 提示, MessageBoxButtons.OK, MessageBoxIcon.Warning); } } } } private void BtnStart_Click(object sender, EventArgs e) { if (!Directory.Exists(txtPath.Text.Trim())) { MessageBox.Show(请先选择有效的目标文件夹。, 提示, MessageBoxButtons.OK, MessageBoxIcon.Warning); return; } _targetPath txtPath.Text.Trim(); _retentionDays (int)numRetentionDays.Value; _recursive chkRecursive.Checked; _runMode cmbMode.SelectedIndex 0 ? CleanMode.EveryInterval : CleanMode.Daily; StartCleanTimer(); btnStart.Enabled false; btnStop.Enabled true; UpdateNextRunLabel(); }路径校验里那个IsDirectoryWritable是我额外加的小工具方法思路是尝试在目标目录创建并删除一个临时文件。这个方法的失败不一定代表后续删除一定失败但能提前拦住最明显的权限问题。日志展示用ListView列就三列时间、类型、消息。数据量上万条时TextBox会卡ListView是WinForms里最能扛的列表方案之一当然内部工具一般不追求大数据量普通模式就够了。控件布局注意用Dock和Anchor窗口拉大时ListView要跟着撑开别把固定大小写死——这是很多winform项目案例常见的败笔。界面美化方面内部工具不需要复杂皮肤把以下几件事做好就够全程序统一字体微软雅黑9pt、按钮对齐排布、清理中状态用颜色标识绿色运行/红色停止、禁用按钮状态跟着运行态切换。winform界面美化的大量案例其实都是在解决「信息层次不清晰」而不是花哨背景图。4. 后台常驻配置持久化、托盘最小化与开机自启4.1 配置持久化用appSettings保存路径与调度参数每次开机重新配置一遍路径和天数是不现实的。常见做法是把配置写进app.config的appSettings节程序启动时读一次界面参数变化时写回。.NET Framework项目直接用System.Configuration.ConfigurationManager.NET 6需要先装System.Configuration.ConfigurationManager这个NuGet包否则编译会报找不到类型。?xml version1.0 encodingutf-8 ? configuration appSettings add keyTargetPath valueD:\TempLogs / add keyRetentionDays value7 / add keyRecursive valuetrue / add keyRunMode valueDaily / add keyRunAtTime value03:00 / add keyIntervalHours value6 / add keyAutoStart valuefalse / /appSettings /configuration对应读取代码就是一个静态配置类public static class AppConfig { public static string TargetPath GetString(TargetPath, ); public static int RetentionDays GetInt(RetentionDays, 7); public static bool Recursive GetBool(Recursive, true); public static string RunMode GetString(RunMode, Daily); public static TimeSpan RunAtTime TimeSpan.Parse(GetString(RunAtTime, 03:00)); public static int IntervalHours GetInt(IntervalHours, 6); public static bool AutoStart GetBool(AutoStart, false); private static string GetString(string key, string defaultValue) ConfigurationManager.AppSettings[key] ?? defaultValue; private static int GetInt(string key, int defaultValue) int.TryParse(ConfigurationManager.AppSettings[key], out var v) ? v : defaultValue; private static bool GetBool(string key, bool defaultValue) bool.TryParse(ConfigurationManager.AppSettings[key], out var v) ? v : defaultValue; }这里有个值得说的习惯所有读取都带默认值。原因是配置文件的健壮性远低于代码用户手改配置写错一个类型程序启动直接抛异常是最差体验。带了默认值之后最多是清理策略按保守值走不会崩。RunAtTime用TimeSpan.Parse也是同理格式写错就在调试期暴露比运行到半夜三点才发现强。配置项含义默认值备注TargetPath要清理的文件夹空启动时校验存在性RetentionDays文件保留天数7越小删得越狠Recursive是否递归子目录true首次建议falseRunModeDaily或IntervalDaily二选一RunAtTime每天执行时间03:00RunModeDaily时用IntervalHours间隔小时数6RunModeInterval时用AutoStart是否开机自启false写注册表Run键有个细节要注意ConfigurationManager读取的是exe同目录下的FolderCleaner.exe.config不是项目里的app.config。改程序集名称或者部署位置后配置文件路径要跟着确认。很多网上踩坑帖都在说改了代码配置不生效八成就是改错文件了。4.2 最小化到托盘与右键菜单定时清理程序注定要长期挂机。最小化到托盘是这类工具的标配用NotifyIcon加一个ContextMenuStrip实现private NotifyIcon _trayIcon; private bool _allowExit; private void InitializeTray() { _trayIcon new NotifyIcon { Icon SystemIcons.Application, Text 文件自动清理 - 运行中, Visible true }; var menu new ContextMenuStrip(); menu.Items.Add(打开主界面, null, (s, e) { Show(); WindowState FormWindowState.Normal; Activate(); }); menu.Items.Add(立即清理, null, (s, e) RunCleanOnce()); menu.Items.Add(退出, null, (s, e) { _allowExit true; _trayIcon.Visible false; Application.Exit(); }); _trayIcon.ContextMenuStrip menu; _trayIcon.DoubleClick (s, e) { Show(); WindowState FormWindowState.Normal; }; } protected override void OnFormClosing(FormClosingEventArgs e) { if (!_allowExit) { // 点右上角X只是隐藏不是退出 e.Cancel true; Hide(); _trayIcon.ShowBalloonTip(1000, FolderCleaner, 程序仍在后台运行右键托盘图标可退出。, ToolTipIcon.Info); return; } if (_cleanTimer ! null) _cleanTimer.Dispose(); base.OnFormClosing(e); }这段代码里最容易被新手忽略的是OnFormClosing的拦截。默认情况下用户点关闭按钮程序就退了定时任务也跟着消失这不符合「常驻」的预期。我加了_allowExit标志只有托盘菜单里的「退出」才能触发真正关闭。注意这个方案有个副作用如果程序是被系统关机信号结束的拦截会拖慢关机流程稳妥的做法是在OnFormClosing里判断e.CloseReason遇到WindowsShutDown就直接放行。托盘图标在程序退出前一定要置Visible false否则explorer.exe会残留一个幽灵图标直到鼠标移过才消失这个问题在Win10和Win11都出现过。4.3 开机自启与单实例保护开机自启用当前用户注册表Run键就够了不需要管理员权限写HKLMusing Microsoft.Win32; private void SetAutoStart(bool enabled) { try { using (var key Registry.CurrentUser.OpenSubKey( Software\Microsoft\Windows\CurrentVersion\Run, true)) { if (key null) return; if (enabled) key.SetValue(FolderCleaner, \ Application.ExecutablePath \); else key.DeleteValue(FolderCleaner, false); } } catch (UnauthorizedAccessException ex) { AppendLog($设置开机自启失败{ex.Message}); } }注册表值里我给路径加了双引号。这个细节来源于一个真实的坑程序放在带空格的目录下比如Program Files (x86)Run键的值不带引号时会被系统当作启动参数解析结果是开机没反应或者启动方式变成执行一个不存在的文件。加引号是最稳妥的写法。这个SetAutoStart方法绑定界面上的一个CheckBox勾选和取消即时生效再把当前值在窗体重载时读回来打勾。单实例保护放在Program.cs的Main入口用Mutex实现[STAThread] static void Main() { using (var mutex new Mutex(true, FolderCleaner_SingleInstance, out bool createdNew)) { if (!createdNew) { MessageBox.Show(程序已在运行请从系统托盘打开。, 提示, MessageBoxButtons.OK, MessageBoxIcon.Information); return; } Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new FormMain()); } }注意这里不要用Global\前缀的命名互斥体。很多人为了让多用户会话间也生效会加Global\但普通用户默认没有SeCreateGlobalPrivilege权限Mutex构造会抛异常反而把自己坑了。内部工具不做远程会话互斥场景的话本地互斥体就够用。5. 定时自动删除的5个高频踩坑现象、原因与排查方案5.1 文件被占用导致删除失败现象日志里出现「文件正在由另一进程使用」点重试也没用程序一直跳过这个文件。原因日志文件被某个服务或Excel占着句柄。Win32的删除语义不像Linux那样允许删除打开中的文件File.Delete遇到占用直接抛IOException。解决给删除动作加有限次重试每次间隔递增三次都失败就记录到「失败列表」不阻塞后续文件。我写的重试逻辑是这样private bool TryDeleteWithRetry(string filePath, int maxRetries 3) { for (int i 1; i maxRetries; i) { try { File.SetAttributes(filePath, FileAttributes.Normal); File.Delete(filePath); return true; } catch (IOException ex) { if (i maxRetries) { _log?.Invoke($重试{i}次仍失败{filePath}{ex.Message}); return false; } Thread.Sleep(1000 * i); // 退避等待给占用方一点释放时间 } catch (UnauthorizedAccessException ex) { _log?.Invoke($无权限删除{filePath}{ex.Message}); return false; } } return false; }重试次数和退避时间都是经验值。内部工具我一般用3次、1/2/3秒退避不搞指数退避——指数退避更适合网络请求本地文件删除的重试窗口短。如果文件被长期占用的服务锁着重试多少次都没意义不如把路径写进失败日志等人工处理。5.2 只读文件删不掉现象其它文件都删了唯独几个文件一直报UnauthorizedAccessException手动右键删除却提示需要管理员权限。原因文件带只读属性或者是从压缩包解压出来的文件继承了只读标志。File.Delete对只读文件不会像资源管理器那样弹确认框而是直接抛异常。解决删除前先清掉只读属性。注意只要清只读就够了不要用File.SetAttributes重置到Normal去覆盖其它属性否则会误删文件的隐藏、系统标志。正确顺序是先GetAttributes判断再只按位清掉ReadOnlyvar attrs File.GetAttributes(filePath); if ((attrs FileAttributes.ReadOnly) ! 0) { File.SetAttributes(filePath, attrs ~FileAttributes.ReadOnly); } File.Delete(filePath);注意只读属性要按位清除不要用FileAttributes.Normal直接覆盖否则会丢失隐藏、系统等原有标志。这也是我在3.1里直接写File.SetAttributes(file, FileAttributes.Normal)被很多同事提过的一个点。实际两者都能达到目的但如果文件本身带Hidden或System属性直接用Normal会把它们一起抹掉虽然后续目录还在但这类文件的归档性信息就丢了。正规做法是按位操作。如果你不在乎这些属性Normal写法省事我在生产代码里已经改成按位了。5.3 递归清理碰到符号链接与目录Junction现象目录里有个符号链接指向E盘的某目录程序递归清理后E盘对应目录里的文件被删了链接本身还在用户直接懵了。原因SearchOption.AllDirectories会顺着符号链接和junction递归进真实目录。Windows下Directory.Delete(path, true)尤其危险它会把链接指向的真实目录内容一并删掉。这是文件系统层的经典陷阱。解决清理指定文件夹时只删文件不删目录本体的方案3.1的做法天然避开了大部分问题如果还需要处理空目录务必要在枚举时排除ReparsePointvar attributes File.GetAttributes(entry); if ((attributes FileAttributes.ReparsePoint) ! 0) continue; // 跳过符号链接/junction思考题如果只是删文件不递归删目录符号链接指向的目录里的文件会不会被删答案是仍会。Directory.EnumerateFiles(dir, *, AllDirectories)同样会穿透符号链接。所以这个坑和「是否删目录」无关只要用了AllDirectories就必须排除重解析点。我建议无论什么场景都把这个判断加上比事后恢复数据便宜得多。5.4 定时器重入导致并发重复删除现象清理几万个文件的目录时日志出现两个「清理中」状态交替出现同一文件被尝试删除两次。原因上一次清理还没跑完下一次定时周期已经到了System.Threading.Timer的回调重入。清理大目录加网络盘时单次耗时超过定时周期很常见。解决3.2里的_isCleaning标志位就是干这个的。这里补充一个细节bool在多线程下的可见性最省事的是用volatile修饰但volatile不能保证复合操作的原子性更稳的是用Interlocked.Exchange做状态切换private int _cleaningFlag; // 0空闲 1清理中 private void TimerCallback(object state) { if (Interlocked.CompareExchange(ref _cleaningFlag, 1, 0) ! 0) return; try { // 清理逻辑 _service.CleanFolder(_targetPath, _retentionDays, _recursive, AppendLog); } finally { Interlocked.Exchange(ref _cleaningFlag, 0); } }Interlocked方案比bool加lock更轻量也比较容易读明白。注意finally里必须复位标志否则回调一旦抛异常这个定时器就永远不再执行了。这是我调试定时任务时遇到最多的一种「程序还活着但什么都不干」的假死状态。5.5 误删刚生成的重要文件现象半夜定时任务把另一个系统刚生成的临时数据删了第二天业务方找上门。原因删除策略只看了「目录匹配」就删没有考虑文件生成时间和类型。比如某些程序启动时会生成.lock、.tmp文件这些文件虽然旧但进程还在使用句柄删了就可能让业务进程崩溃。解决除了LastWriteTime阈值再加两道保险。第一道是「最小存活时间」比如普通文件要求最后写入时间早于当前时间至少2小时才允许删短暂停留的文件不碰。第二道是扩展名白名单/黑名单private static readonly HashSetstring NeverDeleteExtensions new HashSetstring(StringComparer.OrdinalIgnoreCase) { .lock, .pid, .keep, .tmp, .partial }; private static bool CanDelete(string filePath) { var ext Path.GetExtension(filePath); if (NeverDeleteExtensions.Contains(ext)) return false; // 文件最后写入时间必须早于2小时前 return File.GetLastWriteTime(filePath) DateTime.Now.AddHours(-2); }这道双保险的思路是定时自动删除不该追求「全部清干净」而是追求「不删错」。遇到拿不准的文件宁可留着占空间也别删了惹麻烦。这也是这个工具在项目里能长期跑下去的核心信誉问题——它只要误删一次重要文件就没人敢再让它自动运行了。6. 交付前验证与白名单进阶怎么证明这个工具可靠6.1 用假目录做回归验证程序写完别直接挂生产路径。我的验证流程是建一个D:\TestClean塞三种文件旧文件改LastWriteTime为10天前、新文件、.lock文件然后设保留天数1天跑一遍看日志。# 造一批旧文件来验证删除阈值 $dir D:\TestClean New-Item -ItemType Directory -Force -Path $dir 1..20 | ForEach-Object { $f Join-Path $dir old_$_.txt Set-Content -Path $f -Value old (Get-Item $f).LastWriteTime (Get-Date).AddDays(-10) } Set-Content -Path (Join-Path $dir new.txt) -Value new Set-Content -Path (Join-Path $dir keep.lock) -Value lock预期结果是old_*.txt全删、new.txt和keep.lock保留。这个验证跑通之后再把RetentionDays改成0跑一轮确认所有普通文件被删但.lock不动。这样就把核心逻辑和两道保险都验证到了。6.2 长期运行的观察项验证完成后还有三个观察项值得持续盯。第一是「失败列表」每天扫一眼哪些文件反复删除失败持续失败的往往是某个服务的日志文件考虑是否要加白名单或改用日志轮转方案。第二是「清理耗时」如果一次清理超过半小时说明目录文件量超预期可能需要把清理频率调高或改成按子目录分片清理。第三是「磁盘空间曲线」以周为单位记录清理前后磁盘可用空间评估这个工具对磁盘压力缓解是否真的有效。我自己的使用习惯是新接管一台机器时先用「保留30天非递归关自启」跑一周只观察不信任连续一周日志没有异常才逐步调成「保留7天递归开机自启」。自动删除类工具最怕的不是技术问题而是信任问题——宁可慢一点、留得多一点也别在还没摸清目录规律时就把删除策略调激进。这个思路希望帮到你。本文还有配套的精品资源点击获取