Python watchdog文件监测与自动整理：789监测工具实践

1. 为什么我会写这个“789监测”工具，它到底在解决什么问题

1.1 桌面乱成垃圾场，这才是真实的痛点

大概两个月前，我接到一个很让人抓狂的活儿：帮一个做项目的朋友整理他电脑里的产出文件。他每天的工作是接收各种数据文件、截图、临时导出的报表，全都一股脑丢在桌面上。到了交付的时候，他要在几百个文件里一个个翻：哪个是昨天导的、哪个是改过的版本、哪个是最终交付版。整整一个下午，我俩都在玩“桌面寻宝”。

那阵子我自己也差不多。我的桌面长期堆着各种安装包、截图、从微信接收的文件，还有IDE自动导出的日志。Windows的桌面有个特性：它既是文件夹，又是系统最早加载的Shell界面，所以几乎所有人都习惯把文件往桌面一丢，想着“一会儿再整理”。实际上那个“一会儿”永远不会来，直到桌面图标密到看不清壁纸。

那段时间我就在想：与其逼自己养成“随时整理”的习惯，不如写一个工具，让它24小时盯着桌面和指定的文件夹。只要出现新文件，就按我定好的规则复制（或移动）到对应目录，顺便把重名、临时文件、超大文件这些乱七八糟的情况都处理好。这个想法落地之后，就是我这次要分享的“789监测”工具。名字没什么讲究，就是随手拍的代号，比“文件监测复制工具V3.2”好记，而且带点个人项目的烟火气。

1.2 工具的定位与边界

先把这个工具能做什么、不能做什么说清楚，免得读者带着错误的预期往下看。

它能做三件事：

• 持续监测一个或几个目录（桌面、指定文件夹，也可以是网络映射盘、移动硬盘里的目录），实时捕获文件的新建、修改、移动事件。
• 根据预设规则，把符合条件的文件复制到目标文件夹，目标文件夹不存在时自动创建。
• 处理复制过程中的常见问题：文件被占用、重名冲突、短时间内重复触发、临时文件混入。

它不适合做什么：

• 它不是网盘同步工具，不同步删除操作，也不做双向镜像。
• 它不解析文件内容。你要的是“根据内容判断归类”，得自己在回调函数里加逻辑。
• 它默认采用复制而非移动，原文保留在源目录。想搬走原文件，加几个参数就行。

适合谁来用？桌面整理强迫症、需要自动收集产出物的测试人员、常年收报表的运维、不想让下载目录爆炸的普通用户，都可以直接抄作业。底层逻辑是跨平台的（Windows/Linux/macOS都能跑），但我在文中会以Windows为主要场景，毕竟桌面路径、权限、中文文件名这些坑在Windows上最多。

2. 技术选型：watchdog、轮询，还是系统API

2.1 轮询为什么不行

很多初学者拿到这个需求，第一反应是写个循环：每隔几秒扫描一次桌面目录，把文件列表存下来，下次扫描对比一下，多出来的就复制。这方案我也试过，代码确实简单，但坑特别多：

• 延迟不可控。轮询间隔设短了CPU占用明显，设长了又发现不了文件刚生成时的那次重要变化。
• 对比逻辑很难写对。要记录文件大小、修改时间、路径，还得处理文件被改名、被移走、被删除的情况。实际做下来，明明只是“发现新文件”一个需求，对比逻辑却越写越复杂，超过一半的代码在处理边界情况。
• 大目录下性能难看。桌面如果堆了几千个文件，每轮扫描都在做无意义的目录遍历，哪怕文件没变化也得全部stat一遍。

轮询不是不能用，但它适合“分钟级延迟可以接受、目录体量小”的场景。像我这种希望文件一出现就立刻处理的，轮询从一开始就不合适。

2.2 watchdog为什么行

我最终用的是Python生态里最常见的watchdog库。它做的事情，是在底层调用操作系统原生的事件通知接口：

• Windows上对应ReadDirectoryChangesW，
• Linux / Android上对应inotify，
• macOS上对应FSEvents。

这些接口的通用特点是：由操作系统在文件系统发生变更时主动推送通知，而不是由应用层反复扫目录对比。你订阅的是事件流，来一条处理一条，CPU占用几乎可以忽略，响应速度是毫秒级。

打个比方：轮询就像你隔5分钟去一次快递柜，看看有没有新包裹；watchdog是快递柜安了个门铃，包裹一到，它直接按铃通知你。前者不会漏，但永远慢半拍；后者又快又省力气，只要你有接收门铃的耳朵。

2.3 环境准备与最小Demo

先交代一下环境。我用的是Python 3.10，理论上3.8以上都可以。安装watchdog就一条命令：

pip install watchdog

装完验证一下：

python -c "import watchdog; print(watchdog.__version__)"

然后是最小可运行Demo，先让事件能打出来：

import time from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class DemoHandler(FileSystemEventHandler): def on_created(self, event): print(f"创建: {event.src_path} 是目录: {event.is_directory}") def on_modified(self, event): print(f"修改: {event.src_path} 是目录: {event.is_directory}") def on_moved(self, event): print(f"移动: {event.src_path} -> {event.dest_path}") def on_deleted(self, event): print(f"删除: {event.src_path}") observer = Observer() observer.schedule(DemoHandler(), path=r"C:\Users\你的用户名\Desktop", recursive=False) observer.start() try: while True: time.sleep(1) except KeyboardInterrupt: observer.stop() observer.join()

跑起来之后，往桌面随便新建个文本文件，终端会立刻打印出创建事件。如果这个Demo能跑通，说明系统环境和库都正常，下面就可以进入核心逻辑了。

这里有个小细节值得提醒：recursive=False表示只监听当前目录，不递归子目录。桌面这种场景建议设成True，不然桌面上的文件夹内部变动你根本收不到。但如果子目录特别多，事件量会变大，后面讲的防抖和过滤就更重要了。

3. 核心实现：从“事件发生”到“文件到位”的完整链路

3.1 事件类型：并不是所有事件都要处理

watchdog的FileSystemEventHandler一共暴露四类事件：on_created（创建）、on_modified（修改）、on_moved（移动/重命名）、on_deleted（删除）。

很多第一次写的人会把四类全处理一遍，结果发现日志乱七八糟。实际上对于“监测变动并复制到指定文件夹”这个需求，真正要关心的是两类：

• on_created：新文件出现了。这是最常见的搬运对象——桌面被丢进来一个新文件，应该及时复制走。
• on_moved：文件从别处移动进来，或者被重命名了。比如从微信接收文件时，通常先下载到临时目录再move到桌面；又比如用户把“最终版(1).docx”改名为“最终版(2).docx”，改名本身也是一次moved事件。
• on_modified：文件内容发生变化。一个文件创建之后，写内容的过程会触发多次modified。直接把modified当搬运信号，容易在文件还没写完时就复制了残缺版本。
• on_deleted：源文件被删除，跟“复制”这个动作没关系，可以忽略。

实际的策略是：新文件优先在on_created里处理；如果on_created之后短时间内伴随大量on_modified，说明文件仍在写入，需要等它静默下来再复制。后文会讲防抖，正好解决这个问题。

事件里的is_directory也要注意。目录变化和文件变化在事件回调里都能拿到，但我们要复制的只有文件。所以回调函数开头先判断：

def _is_ignored(self, event): if event.is_directory: return True return False

目录本身的新建不需要触发复制，但如果你需要“整个新建目录内的所有文件”，那就得用os.walk递归进去，这个可以作为扩展，后文细说。

3.2 防抖：解决一个文件触发五六个事件的问题

文件系统事件是低层的，它不会管“一个文件被写了三次”这种语义。保存一个Word文档，或者从浏览器下载一个文件，实际产生的事件可能是这样的：

1. 创建临时文件（.tmp）
2. 重命名为最终文件名（moved）
3. 多次写入内容（多次modified）
4. 关闭文件句柄（系统层面可能再触发一次modified）

如果每次事件都立刻复制，你会发现：第一次复制来的文件可能是0字节，第二次复制到一半写坏的，第三次才正确。更糟糕的是，同一条路径在短时间内被重复复制多次，目标文件夹里出现一堆带序号的文件，看着就头大。

解决办法叫“防抖”（debounce），核心思路很简单：记录每个路径最近一次被处理的时间，如果两次事件间隔小于阈值，就忽略后一次，或者把复制动作延后到文件安静下来再执行。

我采用的是“延后执行”方案：收到事件时，先记录这个路径的“最后修改时间戳”，然后用一个定时器延迟3到5秒再检查——如果这个期间又有新事件刷新了时间戳，就继续延后；如果文件真的安静了，就开始复制。

这样做的理由是：有些文件下载需要十几秒，延迟3秒只是让复制动作稍微滞后一点，但能保证复制到的是完整文件。真正需要秒级响应的场景，可以把这个阈值调成1秒，甚至去掉直接复制。

防抖的代码骨架：

import threading class Debouncer: def __init__(self, delay=3): self.delay = delay self._timers = {} self._lock = threading.Lock() def debounce(self, key, callback): with self._lock: if key in self._timers: self._timers[key].cancel() t = threading.Timer(self.delay, self._run, args=(key, callback)) self._timers[key] = t t.start() def _run(self, key, callback): with self._lock: self._timers.pop(key, None) callback()

每次事件进来，调用debounce(full_path, lambda: do_copy(full_path))即可。同一个路径被反复触发时，前一个定时器被取消，换一个新的，保证最终只有一次复制。

3.3 复制冲突：重名、占用、大文件都不放过

防抖解决的是“什么时候复制”的问题，接下来要解决的是“复制时遇到什么情况”。我根据经验把最常见的坑整理成了一张表：

异常情况	表现	处理方法
目标文件已存在	复制直接抛错或覆盖掉旧文件	默认加时间戳后缀，保留两个版本
源文件被占用	PermissionError，文件正被Word/Excel等打开	重试3次，间隔递增，放弃时打日志
源文件是0字节	可能是创建瞬间的事件	延迟再取一次，如果仍为0字节则跳过
超大文件	复制过程耗时久，容易被后续事件干扰	分块复制，完成后比对大小
文件名为隐藏/临时	~$开头、.tmp结尾	直接忽略，见4.2
源目录无权限	事件正常但复制失败	捕获权限异常并记录，而不是让程序崩溃

重名处理我用了最简单也最可靠的方式：文件名_YYYYMMDD_HHMMSS.ext。确保即使一秒钟内复制两个同名文件，时间戳也基本不会冲突。如果你想更文件系统友好，可以用毫秒级时间戳。

def _unique_path(self, target: Path) -> Path: if not target.exists(): return target stem = target.stem suffix = target.suffix ts = time.strftime("%Y%m%d_%H%M%S") return target.with_name(f"{stem}_{ts}{suffix}")

占用问题的处理思路是：复制前先尝试用open(source, 'rb')读它，抛错就等1秒、再等2秒、再等3秒，最多三次。超过三次就直接跳过并记录。文件被占用通常只是Windows上Office/照片查看器等软件的短暂锁定，几秒之后就会释放。真正长期被占用的，等多久也没有意义，不如让日志暴露问题，然后人工决定。

大文件复制，我建议用shutil.copy2配合分块校验。copy2会保留文件的元数据（修改时间等），对文件整理场景比较友好。但copy2是整体复制，不提供进度。对付超大文件更稳的做法是批量读写入：

def _copy_large_file(self, src, dst, chunk_size=1024*1024): src_size = os.path.getsize(src) copied = 0 with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst: while True: chunk = fsrc.read(chunk_size) if not chunk: break fdst.write(chunk) copied += len(chunk) if os.path.getsize(dst) != src_size: raise RuntimeError(f"复制大小不一致: {src}")

这个方法本质是“边读边写”，复制完成后再对比目标文件大小和源文件大小，不一致就认为失败。对于几GB的素材文件，这个方法比一次性copy2更不容易撑爆内存，也更容易定位断点问题。

3.4 完整代码：能直接跑的789监测脚本

把上面的逻辑拼到一起，就是一套可以直接使用的脚本。我在GitHub仓库里维护的版本大概150行左右，这里贴一个核心精简版，删掉了GUI和通知，但保留了完整功能：

import os import time import shutil import logging import threading import argparse from pathlib import Path from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler logging.basicConfig( level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s", datefmt="%Y-%m-%d %H:%M:%S", ) logger = logging.getLogger("789-monitor") class Debouncer: def __init__(self, delay=3): self.delay = delay self._timers = {} self._lock = threading.Lock() def debounce(self, key, callback): with self._lock: if key in self._timers: self._timers[key].cancel() t = threading.Timer(self.delay, self._run, args=(key, callback)) self._timers[key] = t t.start() def _run(self, key, callback): with self._lock: self._timers.pop(key, None) callback() class MonitorHandler(FileSystemEventHandler): def __init__(self, target_dir, debounce_seconds=3, move=False): self.target_dir = Path(target_dir) self.target_dir.mkdir(parents=True, exist_ok=True) self.debounce = Debouncer(debounce_seconds) self.move = move # 忽略常见临时文件 self.ignored_patterns = [ "~$", # Office 临时文件 ".tmp", # 临时文件 ".temp", # 临时文件 ".crdownload", # Chrome 下载中 ".partial", # 下载器临时文件 ] def _should_ignore(self, path: str) -> bool: if Path(path).is_dir(): return True name = Path(path).name if name.startswith("."): # 隐藏文件 / macOS 索引文件 return True for p in self.ignored_patterns: if name.endswith(p) or name.startswith(p): return True return False def _copy_file(self, src_path: str): try: src = Path(src_path) if not src.exists() or src.is_dir(): return size = src.stat().st_size # 0字节文件通常还在写入中，等待下一次事件 if size == 0: return # 重名历史时间戳 dst = self.target_dir / src.name if dst.exists(): ts = time.strftime("%Y%m%d_%H%M%S") dst = dst.with_name(f"{dst.stem}_{ts}{dst.suffix}") # 最多重试3次，应对Windows文件占用 for attempt in range(3): try: if self.move: shutil.move(str(src), str(dst)) logger.info("移动: %s -> %s", src, dst) else: shutil.copy2(str(src), str(dst)) logger.info("复制: %s -> %s", src, dst) break except PermissionError as e: logger.warning("占用中(%d): %s, 等待重试", attempt + 1, src) time.sleep(1 + attempt) except Exception: raise except Exception as e: logger.error("处理失败: %s, 原因: %s", src_path, e) def on_created(self, event): if self._should_ignore(event.src_path): return self.debounce.debounce(event.src_path, lambda: self._copy_file(event.src_path)) def on_modified(self, event): if self._should_ignore(event.src_path): return self.debounce.debounce(event.src_path, lambda: self._copy_file(event.src_path)) def on_moved(self, event): if self._should_ignore(event.dest_path): return self.debounce.debounce(event.dest_path, lambda: self._copy_file(event.dest_path)) def main(): parser = argparse.ArgumentParser(description="789监测：监听目录变动并复制文件") parser.add_argument("--source", required=True, help="要监测的源目录，如桌面路径") parser.add_argument("--target", required=True, help="要复制到的目标目录") parser.add_argument("--move", action="store_true", help="移动文件而不是复制") parser.add_argument("--recursive", action="store_true", help="递归监听子目录") parser.add_argument("--debounce", type=int, default=3, help="防抖延迟秒数") args = parser.parse_args() event_handler = MonitorHandler(args.target, args.debounce, args.move) observer = Observer() observer.schedule(event_handler, path=args.source, recursive=args.recursive) observer.start() logger.info("789监测已启动: 监听 %s -> %s", args.source, args.target) try: while True: time.sleep(1) except KeyboardInterrupt: observer.stop() observer.join() if __name__ == "__main__": main()

用法示例：

python 789monitor.py --source "C:\Users\me\Desktop" --target "D:\自动收集" --recursive

如果要把文件从桌面“搬走”而不是复制，加个--move即可。

4. 实测踩坑录：监听不生效、日志爆炸、临时文件乱入

4.1 事件重复触发，日志直接刷屏的秘密

我第一次跑通这个脚本时，往桌面拖了一个文件，终端里瞬间刷出五六条日志：创建、写入、再写入、关闭、修改……我当时还以为是什么死循环，后来检查才发现，这是文件系统事件最正常的形态。

一个文件从无到有，本来就是分好几个阶段完成的：

1. 应用程序先创建文件（触发一次created）。
2. 向文件写入内容（触发一次或多次modified）。
3. 写完之后关闭文件（某些应用会再触发一次modified）。
4. 如果是下载软件，还会先写临时文件再重命名（触发created+moved）。

如果对每个事件都立即执行复制，大概率会复制到不完整的文件。我一开始没做防抖，直接复制，结果目标目录里出现一堆大小不对的文件，逼着我回去认真看事件流。

解决方案就是前面写的Debouncer。另外有个细节想强调：防抖不只是为了让日志安静，它真正解决的是“什么时候文件不再变了”这个判断问题。延迟3秒是经验值，下载大文件时我会手动把它改成10秒，否则文件还在下载过程中就被当成“静默状态”复制走了。

4.2 Office临时文件和隐藏文件，复制过来就是一堆垃圾

这是我踩过的第二个坑，也是最容易被忽略的。Word、Excel、PowerPoint在打开文档时，会在同一目录下生成一个以~$开头的临时文件。比如你打开报告.docx，旁边会有个~$告.docx，这是Office用来记录编辑锁定信息的，并不是真正的文档内容。如果不加过滤，这些临时文件会被当成真实文件复制走，目标文件夹里全是垃圾。

还有一类是下载工具的临时文件。Chrome下载文件时默认命名带.crdownload，迅雷是.td，IDM是.part。这些文件在下载过程中不断追加内容，监听到了复制过去，复制完可能发现文件还没下完，最后拿到一个残缺版。

过滤规则就一句话：宁可漏掉一个真实文件，也不要复制一个临时垃圾。因为漏掉的真实文件顶多是晚点再处理，而垃圾被复制走了要人工去清理。我在_should_ignore里默认过滤了隐藏文件、~$开头、.tmp/.temp/.partial/.crdownload结尾的文件。这套规则在Windows和macOS上都适用，macOS的隐藏文件还多一个._开头，一并过滤更保险。

4.3 桌面路径被重定向，监听失败却没人知道

耗了我最久的一个问题：脚本在某台Win11机器上怎么都监听不到桌面变化，但同样的代码在另一台机器上跑得好好的。检查了半天，最后发现那台机器把桌面重定向到了OneDrive目录——看起来是C:\Users\xxx\Desktop，实际文件全在C:\Users\xxx\OneDrive\Desktop下。

这种情况很常见，只要开了“文件夹备份”或者手动移动过桌面位置，就会出现“桌面路径和系统实际保存路径不一致”的问题。解决办法：

• 在脚本启动时，用os.path.join(os.path.expanduser("~"), "Desktop")自然兼容多数人。
• 但更准确的做法是用系统API查询已知文件夹路径。Windows下可以用PowerShell查：

  [Environment]::GetFolderPath('Desktop')

  这个返回的是系统认定的真实桌面位置，不会被表面路径骗到。

我自己在脚本里加了个小工具函数：启动时先打印“实际监听目录是XX，存在：是/否”，如果目录不存在直接警告。别小看这行日志，它能在省下一整天的排查时间。我当时要是第一天就看一眼这个日志，根本不用定位大半天。

4.4 中文文件名与系统权限的隐性坑

中文文件名在Windows上表现还算正常，但如果你把脚本放到Linux上跑，或者用network share路径，就可能会遇到编码问题。比如从watchdog事件拿到的路径是Unicode字符串，但你用os.path拼接时如果混入了手工拼的GBK字符串，就会出现“既打不开也删不掉”的奇怪文件。

我的建议很简单：所有路径操作全部用pathlib.Path，杜绝手工拼字符串。Path在Windows上会自动处理反斜杠和正斜杠，在Linux上也不会出问题。路径比较、取名字、加后缀，都用Path的方法，能省掉大多数编码坑。

权限问题则出现在“目标目录不可写”的场景。比如目标文件夹在C:\Program Files下，普通用户的脚本根本没有写权限，复制会静默失败或者抛PermissionError。我的脚本里把权限异常也捕获了，但这里想多说一句：目标目录尽量选用户目录下的位置，或者手动创建好后给脚本确定可写。你让脚本去写系统保护目录，它不是不能写，而是需要提权，后台运行的服务往往没有这种交互式提权环境，失败是常态。

还有一类权限问题藏在网络路径里：监听一个\\NAS\共享目录，或者从FTP服务器下载后再复制到本地。这类路径的权限管理更严格，很多本地能用的API在network share上表现不同。如果你真要监听网络盘，建议先确认共享目录的NTFS权限是否允许你的用户账号“写入”，否则脚本报了“复制成功”实际却没写进去，排查起来会很痛苦。

5. 让它真正“跑起来”：配置化、自启动、扩展方向

5.1 把路径和规则从代码里拆出去

脚本写完能跑只是第一步，真正要当工具用，就得把路径和规则从代码中拆出来。不然每次想换一个监听目录，都得改代码、重启进程，太不优雅。

我现在的做法是：把配置放到一个简单的config.ini里，用Python自带的configparser读。配置内容大致如下：

[monitor] source = C:\Users\me\Desktop target = D:\自动收集\桌面 move = false recursive = true debounce_seconds = 5 [filter] ignore_prefix = ~$.,_ ignore_suffix = .tmp,.temp,.crdownload,.partial,.td

代码里启动时先读配置，然后打印出来让用户确认。这样想加一台机器、换一个目录，改配置文件重启即可，脚本本身的代码不需要动。如果你有更复杂的需求，比如“把图片放到图片文件夹，把PDF放到文档文件夹”，可以在配置文件里加一个[rules]段，用正则表达式匹配文件名和扩展名，这是很自然的演进方向。

5.2 常驻任务与开机自启

Windows下让脚本开机自启，我能想到三种方案：

1. 计划任务（schtasks）：最可靠，适合后台服务场景。
2. 启动文件夹快捷方式：最简单，但每次开机都会弹出控制台窗口，体验差。
3. 服务方式（NSSM包装）：适合长期运行的服务器场景，NSSM把Python脚本包装成Windows服务，崩溃能自动重启。

我日常使用是计划任务，因为可以在“触发器”里设置“计算机启动时”运行，且允许“不管用户是否登录都运行”。如果你怕麻烦，启动文件夹快捷方式也够用，但记得打包成.vbs或.pyw来隐藏控制台窗口：

Set WshShell = CreateObject("WScript.Shell") WshShell.Run "pythonw C:\scripts\789monitor.py --config C:\scripts\config.ini", 0, False

pythonw启动时不会创建命令行窗口，跑在后台很干净。Linux下的话，systemdservice或者nohup都可以，代码层面不用改。

5.3 进阶玩法：这工具稍加改造就能监测恶意文件

这个项目做完之后，我突然想到：文件监测+分类复制这个模型，本质上就是一个“目录事件代理”骨架，往回调函数里塞不同的业务逻辑，它就成为完全不同的工具。

最典型的是恶意文件监测。把_copy_file换成“检查扩展名和文件属性”：如果是.exe、.scr、.bat、.ps1等可执行文件，不复制，而是单独扔进隔离目录，同时向日志发送告警。对运维人员来说，在文件共享目录、下载目录上挂一个这样的探针，能第一时间发现异常文件落地。

另一个方向是自动化流水线。我目前已经在用了：让设计师把终稿丢进桌面上的“交付入口”文件夹，脚本自动把新文件复制到项目期的交付目录，再加上日期前缀；测试环境的日志收集、报表的定时归档，都可以用同样方式实现。灵感在于：别把“复制”想得太死，把它理解成“对特定事件做出一个可编程的响应”，扩展空间就打开了。

至于大家可能关心的“桌面/文件监测会不会被安全软件拦截”，这个要看具体环境。Windows Defender对监听系统目录的行为偶尔会告警，但一般只要程序来源可靠、没有写注册表或启动项，放行即可。如果你是给公司电脑部署，记得提前跟IT打个招呼，免得被误伤。

5.4 最后分享一点我的实际体会

说实话，这个工具本身并不复杂，真正的复杂度全在日常跑起来之后遇到的各种“小意外”上。文件系统是操作系统里最基础也最活跃的部分，任何第三方程序、杀毒软件、云同步工具都可能往你监听的目录里塞东西、改东西。所以写这类工具最重要的不是一开始就把代码写得多么完备，而是把日志写好、把异常路径处理好，遇到问题能快速定位。

我的习惯是：日志里面除了时间和事件类型，永远带上完整的源路径和目标路径。很多次我都是靠日志里“路径对不上”才发现有两套盘符表示同样的物理位置。另外，我强烈建议先用一台不重要的机器跑上一周，把目录里真实会发生的事件类型摸一遍，再拿到正式环境用。文件系统事件远比想象中热闹，先见见世面，后面就不慌了。

如果你也打算写一个属于自己的“789监测”，记住这句话：先把事件看清楚，再谈规则和效率。事件模型没摸透就急着做花哨功能，最后大概率会回来重做。