C# 无法直接使用 eBPF 或 DTrace 监控系统调用，因其运行在用户态 .NET 运行时，无内核探针接口；FileSystemWatcher 是唯一跨平台、免提权的路径级监控方案，但不捕获 syscall 细节。
C# 无法直接使用 eBPF 或 DTrace 监控文件系统调用——这两个是操作系统内核级的动态追踪框架，运行在 Linux（eBPF）或 BSD/macOS（DTrace）内核中，而 C# 运行在 .NET 运行时之上，与内核探针无直接接口。
为什么 eBPF 和 DTrace 在 C# 里不能“调用”
eBPF 程序需用 C 编写、编译为字节码、经内核验证器加载；DTrace 使用自己的 D 语言编写探测脚本，由内核模块解析执行。C# 没有机制把托管代码翻译成 eBPF 字节码，也没有权限在用户态直接注册内核 tracepoint 或 syscall hook。
常见错误现象：System.PlatformNotSupportedException、AccessViolationException（强行 P/Invoke 内核接口时）、或进程静默崩溃。
- 所有试图用
DllImport直接调用bpf()系统调用的尝试，都会因缺少 CAP_SYS_ADMIN 权限或未适配 BPF_PROG_TYPE_TRACEPOINT 而失败 - .NET 的
FileSystemWatcher是基于 OS 层事件（如 inotify / ReadDirectoryChangesW），它不捕获 open/read/write 等系统调用本身，只反馈“文件被修改了”，无法知道是谁、什么参数、是否成功 - 跨平台场景下，DTrace 在 Windows 上不可用，eBPF 在 macOS 上不原生支持，.NET 6+ 的
EventSource也无法导出 syscall 级别细节
替代方案：用 FileSystemWatcher 做路径级变更监控
这是 C# 唯一开箱即用、跨平台（Windows/Linux/macOS）、无需提权的路径监控方式，适用于监听目录增删改，但不是“系统调用”监控。
使用场景：日志目录轮转检测、配置文件热重载、临时文件清理触发。
- 必须设置
IncludeSubdirectories = true才能递归监听，否则子目录内变动不会触发 -
NotifyFilter默认只含FileName | DirectoryName，若想捕获内容修改，要显式加LastWrite，否则Changed事件可能不触发 - Linux 下依赖 inotify，单进程默认上限 8192 个 watch，超限时抛
InvalidOperationException，需调整/proc/sys/fs/inotify/max_user_watches - 不要在
Changed事件处理器里做耗时操作（如读大文件），会阻塞后续事件，建议用Task.Run或发到Channel<string></string>
示例关键片段：
var watcher = new FileSystemWatcher("/tmp/myapp");
watcher.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName;
watcher.IncludeSubdirectories = true;
watcher.Changed += (s, e) => Console.WriteLine($"File changed: {e.FullPath}");
watcher.EnableRaisingEvents = true;真要抓 openat、write 这类系统调用？得绕道外部工具
如果业务确实需要 syscall 级审计（比如合规要求记录谁以什么 flag 打开了哪个 fd），C# 只能作为数据消费者，不参与采集本身。
可行路径：
- Linux：用
bpftool+ 自定义 eBPF 程序捕获sys_enter_openat，输出到 perf ring buffer 或libbpfmap，再由 C# 通过MemoryMappedFile或 Unix socket 读取结构化日志 - macOS：用
dtrace -n 'syscall::open*:entry { printf("%s %s", execname, copyinstr(arg0)); }'输出到管道，C# 启动Process并读取StandardOutput - Windows：用 ETW（
Microsoft-Windows-Kernel-Fileprovider）配合EventLogReader，但仅限于文件对象操作，不包含完整 syscall 参数
性能影响明显：eBPF 程序每秒处理数万次 syscall 没问题，但 C# 实时解析并入库高频率事件（如每秒上万次 write）容易成为瓶颈，建议先用 ring buffer 聚合，再批量处理。
真正难的不是“怎么写代码”，而是厘清需求边界：你要的是“某个目录有没有被改”，还是“进程 A 是否在毫秒级内以 O_APPEND 方式向 /etc/passwd 写入了 37 字节”。前者 FileSystemWatcher 够用；后者必须离开 C# 生态，在内核或 tracer 层解决。
