Perl unlink模拟测试实战：从Test::MockModule到CORE::GLOBAL重定义

1. 认识unlink：它到底删的是什么

写Perl的人，几乎都跟文件操作打过交道，unlink这个函数算是文件删除操作里的标配了。但很多人在实际项目中用着用着就会发现，unlink远没有文档里写得那么轻描淡写。它在Unix/Linux上表现得很直接，到了Windows上却时不时给你闹点脾气。加上现在不少人用Strawberry Perl在Windows环境里做开发，unlink就成了一个“看起来简单、用起来头疼”的典型函数。

先把这个函数的基本动作说清楚：unlink接收一个文件路径列表，逐个尝试删除这些文件，返回实际删除成功的文件数量。正常情况下，你写unlink $file，只要文件存在且当前用户有权限删除，它就会返回1，表示删掉了。如果在列表上下文里调用，它返回的是成功删除的文件个数，而不是列表。

my $count = unlink 'a.txt', 'b.txt'; print "成功删除 $count 个文件\n";

注意，这个函数删除的是文件名所指向的“目录项”，即文件系统中指向该文件硬链接的条目。对于普通文件，删掉目录项就相当于释放了文件占用的空间。但你要是对目录调用unlink，它通常是直接报错的——删除目录得用rmdir，这也是很多新手踩的第一个坑。

还有一个容易忽略的地方：unlink不会询问你“确定要删除吗”，也不会把文件放进回收站。误删就是永久性损失，尤其是生产环境里的数据文件，手一抖就追悔莫及。所以我们在写删除逻辑的时候，往往会在前面加一个存在性判断，或者干脆用一个自定义的封装函数，避免对不存在的文件重复调用unlink而产生多余的逻辑分支。

我记得自己在实际项目里遇到过的最离谱的问题，是在Windows上跑了很长时间的脚本突然报错：删除临时目录里某个文件时，返回了错误，提示“resource busy or locked”。当时第一反应是代码写错了，但排查了很久才发现，原来是另一个进程（一个日志分析线程）正占用着那个文件句柄。Windows的文件锁定机制和Unix不同，Unix下你删除一个被打开的文件完全没问题，删除操作只是摘掉目录项，已打开的文件描述符继续有效，文件占用的磁盘空间等最后一个句柄关闭后才真正释放。Windows则不允许删除一个被其他进程以非共享模式打开的文件。

如果你用的刚好是Strawberry Perl，在Windows环境下做开发，这种问题会尤其常见。因为Strawberry Perl本身附带了完整的GCC工具链和大量CPAN模块，很多人拿它跑自动化脚本、做批处理、处理日志文件，而Windows的文件锁定策略让unlink变得没那么“随性”。

所以在深入模拟和测试技巧之前，先把unlink的底层行为搞清楚，才是所有技巧的前提。

2. 为什么需要模拟unlink：测试中的真实痛点

很多刚接触测试的人会问：unlink不就是删个文件吗？测试的时候直接创建一个临时文件、调用unlink、再断言文件不存在，不就行了？这个思路在简单场景下确实可行，但一旦项目复杂起来，你就会发现直接把unlink跑在真实文件上会带来一堆麻烦。

第一，测试环境里不一定有真实文件。比如你想测试一个“批量清理过期日志”的函数，这个函数会遍历指定目录，找出符合条件的老文件，然后逐个unlink。为了测试它，你每次都要在测试代码里去构造一批过期的日志文件。如果只是偶尔测一次倒还好，但每次跑测试都要生成、清理这些真实文件，测试速度会变慢，而且很可能在测试结束后留下“残留物”，污染测试环境。

第二，真实文件系统操作具有不确定性。文件删除涉及权限验证、磁盘状态、并发访问等因素。如果你在一台没有写权限的CI机器上跑测试，或者临时目录的路径不存在、磁盘满了，unlink就会失败，导致测试结果不稳定。这种“环境相关”的失败是最让人头疼的，因为代码本身没有问题，测试却在不同的环境上表现不一致。

第三，你未必想真的删除文件。有些测试场景里，被测试函数的核心逻辑是“判断哪些文件该删、按什么顺序删、删除失败怎么处理”，而不是真的在意文件系统里少了哪个文件。这种情况下，如果mock掉unlink，你就能精准捕获“被删除的文件列表”和“被删除的顺序”，而不必真正操作磁盘。这就像陪审团要判断的是一起案件的证据链是否完整，而不是真的去现场重演一遍犯罪过程。

第四，老代码里的全局函数调用很难替换。假如你的项目里有一段十年前写的老模块，直接在代码里满天飞地调用unlink。现在要给它写单元测试，你总不能去改原始代码把每个unlink都替换成依赖注入吧？这时候“运行时模拟”就成了救命稻草——在测试期间将CORE::GLOBAL::unlink替换成mock版本，让被测代码感知不到区别。

我知道有些朋友会说：不就是一个文件删除函数吗，至于这么复杂？但等你真正接手一个数据清理项目、一个日志轮转系统、一个CI/CD管道里的临时目录自动清理工具，就会明白，文件删除往往是整套自动化流程里最容易出故障的环节，也是测试里最容易被忽视的一环。模拟unlink不是为了偷懒，而是为了让测试更可靠、更快速、更聚焦于业务逻辑本身。

3. 从零开始：在真实文件系统上测试unlink的基本方案

在引入复杂的模拟方案之前，还是先看看最朴素的真实测试怎么做。这样做的好处是直观、底噪少，适合测试文件数量少、操作明确的小模块。

最简单的方案是用File::Temp创建临时文件，然后调用unlink，再断言返回值和文件存在状态。

use strict; use warnings; use File::Temp qw(tempfile); use Test::More; my ($fh, $filename) = tempfile(); close $fh; ok(-e $filename, '临时文件已创建'); my $ret = unlink $filename; is($ret, 1, "unlink 返回值应为1，实际为 $ret"); ok(!-e $filename, '文件已被删除'); done_testing();

这段代码看起来没问题，但里面藏着一个重要细节：File::Temp默认会在对象销毁时自动清理临时文件。如果你用了tempfile的标量上下文返回方式，有些版本还会保留文件句柄，导致Windows上删除失败。所以我习惯用tempfile(UNLINK => 0)显式关闭自动删除，或者干脆在合适的时机手动unlink，避免双重删除带来的困惑。

如果你要测试的是一个接受目录参数的清理函数，那就得在临时目录里创建一批文件，再有目的地调用函数，最后检查目录内容。

use File::Temp qw(tempdir); my $dir = tempdir(CLEANUP => 1); for my $name ('old.log', 'new.log', 'tmp.txt') { open my $fh, '>', "$dir/$name" or die $!; print $fh "test"; close $fh; }

这里我通常会把CLEANUP设为1，让File::Temp在测试结束时自动把整个临时目录删掉，避免测试残留。但这里有个矛盾点：如果你测试的函数负责删除$dir里的文件，而File::Temp在最后又自动删除一遍$dir，那么第二次删除时目录已经不存在了，File::Temp会静默忽略掉这个错误吗？实测下来它会尝试清理，但不会报错，因为底层用的是_force_remove这类容错逻辑。不过为了稳妥起见，我还是倾向于在测试最后手动清理，或者把临时目录的自动清理关掉。

真实文件测试最大的优点是代码简单、语义清晰。但它有个硬伤：你测试的是当前文件系统下的行为，如果某天换了一个文件系统类型（比如FAT32和NTFS的差异），或者换了一台文件锁策略不同的操作系统，测试结果可能就变了。这也是我在做跨平台项目时，逐渐把重心转向“模拟”的原因。

4. 核心技巧：用Test::MockModule模拟unlink调用

当你需要把unlink从真实文件系统行为中剥离出来时，就要请出Perl测试世界里的经典模块：Test::MockModule。这个模块允许你在运行时覆盖包内的函数定义，包括Perl内置函数在特定包空间里的调用。

要理解Test::MockModule的工作原理，首先要明白Perl中函数调用的路由策略。当你写unlink $file时，Perl到底调用的是哪个函数？如果这段代码在一个包内，且该包导出了一个名为unlink的自定义子程序，那么调用的就是这个自定义子程序。如果没有自定义子程序，Perl会尝试调用CORE::GLOBAL::unlink，如果这个也没有定义，才会调用内置的CORE::unlink。

Test::MockModule的核心思路，就是把你需要覆盖的包（比如main或某个业务模块）的符号表中的unlink条目，临时替换成你提供的mock实现。在测试结束时，再恢复原来的定义。这样就实现了“只有被测代码能感知到mock，外部世界一无所知”的效果。

一个典型的用法是这样的：

use Test::More; use Test::MockModule; my $mock = Test::MockModule->new('My::FileCleaner'); my @deleted; $mock->redefine('unlink', sub { my @files = @_; push @deleted, @files; return scalar @files; }); # 被测代码 My::FileCleaner::cleanup_files('/tmp/expired'); is_deeply(\@deleted, ['/tmp/expired/a.log', '/tmp/expired/b.log'], 'unlink 收到两个文件路径'); done_testing();

这里的关键是，My::FileCleaner模块内部如果直接写unlink $file，Perl在编译时就会确定这个unlink是内置函数，而不是动态查找包内子程序。具体表现是：如果你在别的包重新定义了CORE::GLOBAL::unlink，但My::FileCleaner已经编译好了，它仍然会调用内置的unlink。这就涉及到Perl编译期和运行期的差异了。

所以Test::MockModule之所以能生效，是因为它在运行时修改了My::FileCleaner包的符号表，把unlink这个名字指向了mock子程序。而Perl在调用一个函数时，会先查找当前包（或明确指定的包）内是否存在同名子程序，如果存在，就调用它。这就解释了为什么$mock->redefine('unlink', ...)能覆盖内置函数——因为包作用域内的同名子程序优先级更高。

不过这里有一个连很多Perl老手都会搞混的点：如果你在被测代码里写成CORE::unlink $file，那就等于明确指定了调用内置函数，任何包级别的模拟都对它无效。所以，要保证mock生效，被测代码里应该直接写unlink $file，而不是加CORE::前缀。这也是我在代码评审时特别关注的点——有些程序员为了语法严谨，喜欢写CORE::unlink，结果到测试阶段就傻眼了。

另外，Test::MockModule不仅能模拟unlink，还能模拟system、open、mkdir等大量内置函数。你在写文件清理相关测试时，经常需要同时限制多个文件操作函数的行为，这时就可以一次性redefine多个函数。

my $mock = Test::MockModule->new('My::LogCleaner'); $mock->redefine('unlink', sub { ... }); $mock->redefine('rmdir', sub { ... });

用Test::MockModule有几个注意点。第一，它只能模拟“通过包符号表调用的函数”，那些在模块内部被编译为CORE::直接调用的函数，它管不了。第二，它在redefine之后要记得在测试结束时让mock对象销毁，这样才能自动恢复原函数；如果你用Test::More的done_testing，建议把mock对象限制在局部作用域内，或者显式调用$mock->unmock。第三，如果测试过程中出现了异常退出，mock可能来不及恢复，导致污染后续测试。所以有些团队会倾向用Test::Exception配合local块来确保恢复。

这里我也遇到过一种特别隐蔽的情况：如果被测模块里使用了use subs qw(unlink);，那么模块内部对unlink的调用就会被强制解析为本地子程序调用，而不是内置函数。这在某些老代码里很常见，因为程序员想基于unlink再封装一层自己的逻辑，于是提前声明了use subs qw(unlink)，后面的调用就会走自定义子程序。这会让Test::MockModule的redefine失效，因为你已经改写了本地符号表，但模块内的自定义子程序可能不叫unlink这个名字了。遇到这种情况，我建议干脆用下一节要讲的方法：直接模拟CORE::GLOBAL。

5. 进阶方案：重定义CORE::GLOBAL::unlink实现全局模拟

如果unlink的调用点分散在很多模块里，而你又不想一个一个去mock每个模块的符号表，那么全局模拟CORE::GLOBAL::unlink是更高效的选择。

原理是这样的：Perl在编译内置函数调用时，对于unlink这种“列表操作符”，会先检查CORE::GLOBAL::unlink是否已定义。如果已定义，就生成对该子程序的调用代码；如果没有，就直接生成内置操作的字节码。这意味着，如果你在编译被测代码之前就定义了CORE::GLOBAL::unlink，那么所有模块里的unlink调用都会走你的模拟版本。

举个例子：

use strict; use warnings; BEGIN { *CORE::GLOBAL::unlink = sub { my @files = @_; warn "模拟unlink: 删除 @files"; return scalar @files; }; } use My::LogCleaner; My::LogCleaner::clean('/tmp/expired');

这个BEGIN块非常关键——它必须在被测试模块编译之前执行。如果被测试模块已经被use加载并编译完成，那时它的unlink调用就已经被解析为内置操作了，再在运行期定义CORE::GLOBAL就来不及了。

在实际测试中，我通常会用Test::MockModule配合CORE::GLOBAL重定义，或者用Test::MockObject配合redefine。但CORE::GLOBAL的方法有一个额外的限制：Perl的内置函数和操作符调用有优先级和语法规则。unlink在列表上下文里接受文件列表，在标量上下文里接受一个文件。你的模拟子程序得同时兼容这两种调用方式，否则就会产生微妙的行为差异。

下面是我在项目中实际用过的完整模拟方案：

use strict; use warnings; use Test::More; use Test::Exception; my @mock_deleted_log; BEGIN { *CORE::GLOBAL::unlink = sub { my @paths = @_; push @mock_deleted_log, @paths; # 模拟“大部分文件删除成功，但特定文件失败” my $success = 0; for my $p (@paths) { if ($p =~ /protected\.txt$/) { $! = EACCES; # 模拟权限错误 next; } $success++; } return $success; }; } # 被测代码 use FindBin; use lib "$FindBin::Bin/lib"; use My::FileCleaner; my $cleaner = My::FileCleaner->new; $cleaner->remove_files('/data/tmp/old.log', '/data/tmp/protected.txt'); is_deeply( \@mock_deleted_log, ['/data/tmp/old.log', '/data/tmp/protected.txt'], 'mock unlink 收到正确的文件路径' ); done_testing();

这里我故意让protected.txt删除失败，从而验证被测代码是否妥善处理了部分失败的情况。这种“先记录所有调用参数，再模拟不同返回结果”的模式，是我在测试文件清理工具时最常用的套路。

但使用CORE::GLOBAL模拟时要小心一个坑：如果测试模块本身也用到了unlink（比如File::Temp清理临时文件时），那么它也会被你的全局模拟捕获，导致测试基础设施自身行为异常。我在实际项目中就遇到过：File::Temp在测试结束时执行自动清理，结果触发了我mock的unlink，把日志文件路径也被记录了一遍，导致断言失败。解决办法是：要么在测试结束后把CORE::GLOBAL::unlink恢复原位，要么用动态调度——在mock子程序里判断调用者是否是特定包，如果是File::Temp就调用真正的内置unlink。

BEGIN { my $orig_unlink = \&CORE::unlink; *CORE::GLOBAL::unlink = sub { my $caller = caller(); if ($caller eq 'File::Temp') { return $orig_unlink->(@_); } # 自己的模拟逻辑 ... }; }

这个技术用好了，在大型遗留系统里做测试是神器；用不好，各种诡异的连锁反应会让你排查到怀疑人生。我的建议是：优先使用Test::MockModule按包模拟，只有跨模块全局调用点太多时，才考虑CORE::GLOBAL重定义。

6. 另辟蹊径：用对象接口替代unlink直接调用

如果你有权限修改被测代码，还有一个更优雅的思路：抽象文件删除操作。即不直接裸调unlink，而是封装成一个方法，然后通过依赖注入或者继承来替换。

比如定义一个极简的文件系统抽象类：

package My::FS; sub unlink_file { my ($class, @paths) = @_; CORE::unlink @paths; } sub rmdir_dir { my ($class, @paths) = @_; CORE::rmdir @paths; } 1;

业务代码在删除文件时，不再直接调用unlink，而是通过My::FS->unlink_file(@paths)。测试代码里可以创建一个mock子类：

package Mock::FS; our @deleted; sub unlink_file { my ($class, @paths) = @_; push @deleted, @paths; return scalar @paths; } 1;

然后测试时把业务代码里的FS类替换成Mock::FS：

$business_module->fs_class('Mock::FS'); Mock::FS->clear_deleted; $business_module->cleanup_expired_files; is_deeply(Mock::FS->deleted, ['/tmp/a.log', '/tmp/b.log']);

这种对象接口方案的优点是测试完全可控，不依赖任何模拟模块的黑魔法，心智负担小，维护起来也直观。缺点是必须修改业务代码，对旧代码的改造成本比较高。但如果是新项目，我非常推荐先定义文件操作抽象层，再写业务逻辑，这样测试会轻松很多。

当然，这种做法在实际项目中会面对一个阻力：有些人觉得为了测试去改代码结构有点过度设计。我的看法是，如果你的项目里unlink调用点超过5个，或者文件删除逻辑存在重试、权限判断、路径规范化等操作，那么抽象一层几乎是必然的。这跟设计模式无关，纯粹是让代码结构更清晰、更可测。

另外，如果在业务代码里还有-e $file这样的文件存在性判断，建议也一并抽象。因为你既然模拟了unlink，文件的真实存在与否就变成了一件“不可靠”的事。在mock状态下，unlink被模拟了，但-e仍然是真实文件系统操作，两者会脱节。你可以让mock子类同时维护一个“虚拟文件系统状态”，记录哪些文件存在、哪些被删了，从而让-e和unlink一致。

package Mock::FS; my %virtual_fs; sub setup_file { my ($class, $path) = @_; $virtual_fs{$path} = 1; } sub unlink_file { my ($class, @paths) = @_; my $count = 0; for my $p (@paths) { if ($virtual_fs{$p}) { delete $virtual_fs{$p}; $count++; } } return $count; } sub file_exists { my ($class, $path) = @_; return $virtual_fs{$path} ? 1 : 0; } 1;

这种做法在测试复杂业务逻辑时尤其好用——因为你可以在内存里模拟出一整套目录结构，而不必真实创建任何文件，测试速度会飞快，而且不会在开发机上留下垃圾文件。

7. Windows平台上的unlink痛点与Strawberry Perl实战

在Windows上用Perl开发的人，对unlink的体验跟Unix下是完全不同的。最典型的问题，就是我开头提到的“resource busy or locked”。这个错误在Unix下几乎不存在，但在Windows下非常常见。原因是Windows的文件管理机制与Unix有着本质区别：Windows采用“文件句柄引用计数”加“共享模式”来控制文件访问，如果你打开文件时没有指定FILE_SHARE_DELETE，那其他进程在文件被关闭之前是不能删除它的。

如果你用Strawberry Perl在Windows上跑脚本，遇到unlink返回EBUSY或Permission denied，第一反应应该是：有没有哪个文件句柄没有关闭？在Perl里，最常见的场景是：你用open my $fh, '<', $file读取文件，处理完后忘记close $fh，接着就调unlink $file。在Unix下这通常不会报错，但在Windows下，即使你只打开了读句柄，只要没有显式关闭，就足以阻止删除操作。

所以我的第一个建议是：在Windows上，任何文件删除前都要确保所有文件句柄已关闭。你可以用close显式关闭，或者把文件读取放在一个子例程的作用域内，让句柄自动回收。

sub read_file { my ($path) = @_; open my $fh, '<', $path or die $!; local $/; my $content = <$fh>; close $fh; return $content; } # 删除前必须确保 read_file 返回后句柄已关闭 my $content = read_file($file); unlink $file or warn "删除失败: $!";

第二个常见坑是：Windows下的unlink不能删除只读文件。即使文件没有其他进程占用，只要属性标记为只读，unlink就会失败。Unix下没有这个概念，所以很多从Unix迁移过来的代码到了Windows上就会莫名奇妙地删除失败。解决办法是删除前先清除只读属性。

use Win32; # 或直接用系统命令 system('attrib', '-R', $file) if $^O eq 'MSWin32'; unlink $file or warn "删除失败: $!";

第三个坑是路径分隔符和路径格式。Windows下路径可能包含盘符，以及反斜杠。如果你在拼接路径时用了Unix风格的正斜杠，Perl内部通常也能处理，但某些模块会返回带反斜杠的路径，导致你在比较或断言时对不上号。建议在测试里统一用File::Spec->catfile来构建路径，避免硬编码分隔符。

关于Strawberry Perl，它最吸引人的地方在于：即使在Windows上，它也自带完整的GCC工具链和CPAN模块安装能力，所以在Windows上装各种XS模块非常方便。但正是因为工具链的复杂性，它在删除文件时也会受到Windows文件夹联、杀毒软件扫描、索引服务等额外影响。有时候你会发现，一个明明没有被任何进程占用的文件，unlink还是失败了，原因可能是杀毒软件正在对这个文件做实时扫描。这种情况下，可以稍等片刻再重试删除，或者用Win32 API里的MoveFileEx配合MOVEFILE_DELAY_UNTIL_REBOOT来标记为重启时删除——虽然这个方案在绝大多数场景下用不上。

在测试层面，Windows上写unlink测试时，我强烈建议在测试环境和真实环境之间明确区分。CI服务器如果跑在Linux上，而开发者在Windows本地跑，同一套测试在两种平台上的表现可能截然不同。Test::More的plan skip_all可以配合$^O实现平台差异跳过：

plan skip_all => 'Windows下跳过文件锁定相关测试' if $^O eq 'MSWin32';

但这样做也有代价：Windows独有的bug就测不到了。所以我通常会把测试拆成两部分：一部分是通用的、与平台无关的逻辑测试（用mock实现），另一部分是专门的Windows集成测试，只在Windows环境下执行，并设置更宽松的重试机制。

8. 常见问题速查：unlink测试中的典型陷阱

做unlink相关测试时，有几类问题是反复出现的。我把它们整理成表格，方便你排查时快速定位。

这里再额外提一个比较冷门但实际遇到过的坑：如果文件路径以-开头，unlink会把路径当成一个选项来解析。比如unlink '-foo.txt'可能会被错误解释。解决办法是用./前缀显式指定路径，或者传递完整的绝对路径。

my $file = '-temp.txt'; unlink "./$file"; # 避免被解析为命令行选项

另一个容易被忽略的问题是unlink在标量上下文中的行为。如果你习惯性地写unlink $file，其实Perl会把它当成一个“老式列表操作符”，如果$file是数组或列表，它会一次性删除所有文件，而不是只删除第一个元素。这跟很多其他语言里函数只接受单个参数的习惯不同。所以如果一个变量后面跟了逗号和更多参数，你会意外删掉多个文件：

my $file = 'a.txt'; unlink $file, "b.txt"; # 两个文件都会被删除

这种语法糖带来的“隐形多删除”在测试里也不容易发现，因为mock版本的unlink如果只处理第一个参数，就会丢掉后面的文件。建议在mock实现里严格模拟Perl内置函数的列表语义，即遍历所有传入参数。

至于测试里要不要真的检查$!的值，我的经验是：除非业务代码会针对不同的错误类型做分支处理，否则测试里只要断言“成功/失败”两个状态就够了，不必过度校验具体的错误码。因为不同平台的$!值有差异，Windows上的EBUSY和Unix上的EACCES往往不是同一个数字，硬编码在测试断言里会让测试失去跨平台可移植性。

9. 实操心得：我在项目里的测试策略总结

最后分享一点我自己的项目经验。我带过一个日志清理模块，负责按保留天数轮转和删除旧日志，跨平台运行。最开始测试用的是真实文件操作，每次测试要在临时目录里造几十个假日志文件，跑完再清理，速度慢且不稳定。后来我引入了Test::MockModule来模拟unlink和rmdir，测试时间从原先的每分钟几十个用例下降到几百个用例，而且彻底摆脱了平台差异。

但全局模拟后来也遇到了一个问题：随着业务模块越来越多，某些模块内部不仅有unlink，还有rename、open、chmod等文件操作，只mock一个unlink不够。后来我把文件操作全部收敛到一个内部工具类里，用对象接口的方式做依赖注入。这样测试代码就是纯粹的业务逻辑测试，不再依赖任何模拟模块的“魔法”。

如果你正在做的是一个新项目，我的建议顺序是：

• 第一层：抽象文件操作，封装成独立模块。
• 第二层：业务逻辑使用封装模块，不直接调用内置函数。
• 第三层：测试时用Mock子类替换封装模块，维护虚拟文件系统状态。

如果你接手的是老项目，无法大规模重构，那就用Test::MockModule按包逐个模拟。如果调用点太多，就使用CORE::GLOBAL重定义，但务必小心测试基础设施自身被影响。

还有一个小技巧，测试unlink删除失败分支时，别只模拟“全部失败”或“全部成功”。业务代码里往往存在“部分成功、部分失败”的临界状态。用mock实现时，可以根据文件名或路径特征来决定哪些返回成功、哪些返回失败，这样才能覆盖完整的错误处理分支。

$mock->redefine('unlink', sub { my @files = @_; my $ok = 0; for my $f (@files) { if ($f =~ /keep.*\.txt$/) { warn "保留文件: $f"; next; } $ok++; } return $ok; });

这种带条件的mock，能帮你测出那些在真实环境里很难稳定复现的边界情况。

在我个人看来，文件删除看似琐碎，但在自动化运维和数据处理管道里，它往往是数据安全的关键节点。测试unlink不是说代码写得有多复杂，而是通过模拟和断言，确保删除逻辑在正确的时间、以正确的顺序、处理正确的文件。这一点，比“能不能删掉文件”本身重要得多。

最后再提一个环境层面的建议：如果项目跑在Windows上且使用Strawberry Perl，尽量保证CI环境与生产环境的平台一致。如果做不到，就至少要在测试里显式标记哪些用例依赖平台行为，避免你在本地跑得欢天喜地，CI上却红成一片。文件操作这种东西，平台差异永远比想象中大。