让我一步步帮你理清这个问题，给出靠谱的解决方案：

首先明确：你的代码完全没有任何锁机制，在Apache并发调用这个脚本时，会出现严重的问题：

• 当多个进程同时执行open(FH, '>', "file.txt")时，这个操作会直接截断文件（清空原有内容），后执行的进程会覆盖先执行进程的截断操作，导致之前进程写入的内容直接丢失。
• 就算你是用追加模式（>>），多个进程同时写入也会导致内容乱序、穿插，最终文件内容混乱不堪。

简单说，无锁的文件读写在并发场景下完全不可靠，数据损坏是必然的。

你想用lsof检查文件是否被占用，然后再操作？这绝对是个坑！因为这里存在竞态条件：
你刚用lsof查到文件没被占用，但是在你执行open打开文件的那一瞬间，另一个进程可能已经抢先打开了这个文件。这中间的时间差会让你的“检查-操作”逻辑完全失效，根本起不到同步的作用。这种方式本质上是“伪同步”，完全不可靠，别浪费时间在这上面。

方案A：用Perl内置的flock文件锁（简单场景首选） #

Perl自带的flock函数可以实现系统级的文件锁，支持排他锁（写操作）和共享锁（读操作），能完美解决并发读写的问题。给你修改后的示例代码：

#!/usr/bin/perl
use strict;
use warnings;
use CGI ":standard";
use Fcntl qw(:flock); # 导入锁相关的常量

my $file_path = "file.txt";

# 以读写模式打开文件（+< 表示可读可写，不会自动截断）
open(my $fh, '+<', $file_path) or die "ERROR opening file: $!";

# 加排他锁（同一时间只有一个进程能拿到锁，写操作必须用这个）
flock($fh, LOCK_EX) or die "ERROR locking file: $!";

# 现在可以安全地执行读写操作了
my @existing_content = <$fh>; # 读取原有内容
seek($fh, 0, 0); # 将文件指针移回开头
truncate($fh, 0); # 清空文件（如果需要覆盖拼接的话）

# 拼接原有内容和新文本，写入文件
print $fh @existing_content, "something new to add\n";

# 释放锁（其实关闭文件时会自动释放，这里写出来更清晰）
flock($fh, LOCK_UN);
close($fh);

如果是纯读操作，可以把LOCK_EX换成LOCK_SH（共享锁），这样多个进程可以同时读取文件，但写操作会被阻塞直到所有读锁释放，保证数据一致性。

方案B：使用数据库（复杂场景首选） #

如果你的业务逻辑越来越复杂，或者需要更可靠的持久化、查询能力，用数据库（比如SQLite、MySQL）确实是更优的选择：

• 数据库内置了事务、锁机制，不需要你手动处理文件同步的细节，原子性操作有保障。
• 可以轻松实现更复杂的逻辑，比如按条件更新、查询历史记录等，比直接操作文件灵活太多。
• 避免了文件系统层面的各种问题，比如权限冲突、文件损坏、锁的跨进程/跨机器问题。

比如用SQLite的话，Perl有DBD::SQLite模块，不需要单独的数据库服务器，直接操作本地文件就能实现可靠的并发控制，非常适合小型CGI应用。

• 别用lsof做同步，竞态条件是无解的死穴；
• 简单的文件读写场景，用Perl自带的flock就足够可靠；
• 复杂业务或需要更强扩展性的话，直接上数据库是一劳永逸的选择。

内容的提问来源于stack exchange，提问作者PaulM