企业官网建设流程全解析

一个很典型的场景：晚上十一点，方案改到第八版，Word 突然卡住，鼠标转圈，你在任务管理器里点了“结束任务”。再打开 Word，文档恢复面板弹出来一个“文档1（已恢复）”，但内容是空的，或者停留在两小时前的版本。这一刻大部分人的第一反应是“完了，白干了”。

但真实情况往往相反。在 Word 崩溃、断电、强制结束进程这三类事故里，数据真正彻底消失的比例并不高，更多的情况是“数据还在，只是你不知道它被放在了哪里、叫什么名字、用什么方式才能打开”。自动恢复文件、临时文件、所有者文件、备份文件，这四类残留物散落在不同的目录里，它们的后缀名和正常文档完全不一样，Windows 默认还把扩展名藏起来，于是大多数人连找都找不对地方。

这篇文章想解决的不是“Word 怎么用”，而是“事故发生后十分钟内，你能不能把损失压到最小”。网上关于这个问题的答案，八成是让你去%APPDATA%\Microsoft\Word找.asd文件，照着做的人一大半会卡在三个地方：目录是空的、文件找到了却打不开、打开后发现是旧版本。所以下面不会只给你一条路径，而是把“文件为什么会留下”“留在哪”“怎么批量捞出来”“怎么验证捞出来的是不是你要的那份”这一整条链路拆开讲。

适用范围先说清楚：桌面版 Word（Microsoft 365、2016、2019、2021 这一系列的操作逻辑基本一致，具体界面文字以你实际安装的版本为准），操作系统以 Windows 为主，最后会带一句 Mac 用户的差异。如果你的文档存在 OneDrive 或 SharePoint 且开启了自动保存，处理路径完全不同，那种情况基本不用恢复，直接看版本历史就行，文中会单独说明。接下来的内容按“原理—定位—脚本捞取—验证—防再犯”的顺序展开，每一步都能直接照着做。

1. 先厘清一个事实：Word 一直在替你写“草稿”

很多人对 Word 保存机制的理解停留在“我按了 Ctrl+S 才算存过”。这个认知会直接导致事故发生后判断失误。实际上，只要你在文档里敲过字，Word 的内存里就一直维护着这份文档的完整状态，并且会在几个特定时机把它往磁盘上“抄一份”。抄出来的东西不是正式文档，格式也不完全一样，但内容是真的。

真正需要区分的是三类落盘行为。第一类是自动恢复信息，扩展名通常是.asd，Word 每隔一个时间间隔（默认一般是 10 分钟，具体以你安装版本的“文件—选项—保存”里显示的为准）把当前编辑状态写一份到这个文件里，崩溃后 Word 重启时会尝试读它。第二类是临时文件，Word 在编辑过程中会在文档同目录或临时目录生成以~开头的文件，比如~WRL0001.tmp，这些文件在正常关闭时会被删除，非正常退出时就会残留。第三类是所有者文件，形如~$报告.docx，它本身不含正文内容，只记录“谁正在打开这个文档”，但它能证明“这个文档刚才确实被编辑过”。

还有一个经常被忽略的机制是自动保存（AutoSave），它和自动恢复不是一个东西。自动保存只对存放在 OneDrive 或 SharePoint 上的文档生效，开关在 Word 左上角，打开后是真实地把修改写回云端文件，间隔非常短。而自动恢复（AutoRecover）是本地机制，两者名字很像但作用范围完全不同。很多人说“我开了自动保存啊怎么还是丢了”，问题就出在文档存在本地 D 盘，而自动保存那个开关对本地文件根本不起作用。

理解这三类残留物之后，你就会明白为什么“没保存”不等于“没有数据”。崩溃发生的瞬间，Word 内存里那份最新内容确实没了，但上一次自动恢复写入的.asd、崩溃前几秒还在写的.tmp，都是可以抢救的对象。区别只在于：.asd的完整度取决于距离上次自动恢复过了多久，.tmp的完整度取决于 Word 是否已经把它 flush 到磁盘。这两者的时间窗口加起来，往往能把你丢失的内容从“两小时”压缩到“十几分钟”。

2. 核心原理：崩溃瞬间，数据到底留在了哪里

要做得快，就得知道 Word 写文件的顺序。这里不讲源码级细节，只讲对恢复有用的部分。

Word 保存一个已有路径的文档时，走的不是“直接覆盖原文件”，而是“先写一个临时文件，写完再替换原文件”。这个设计的目的是防止写到一半断电导致原文件被破坏——原文件在替换完成前始终是完整的。这就带来一个很关键的推论：如果崩溃发生在保存过程中，原文件大概率还是旧的完整版，而新内容躺在一个临时文件里。所以你在原文件位置看到的“还是昨天的版本”，并不代表你今天的工作丢了，它可能就在同目录的某个.tmp里。

对于从未保存过的新文档（比如你直接打开 Word 就开始写，从来没点过保存），情况又不一样。这类文档没有“原文件”，Word 会把它当成文档1这样的临时对象处理，自动恢复信息会写到默认的自动恢复目录。这个目录的位置可以在“文件—选项—保存—自动恢复文件位置”里看到，不同版本、不同安装方式（比如 Office 365 的即点即用和 MSI 安装）默认路径会有差别，常见的是%APPDATA%\Microsoft\Word\和%LOCALAPPDATA%\Microsoft\Office\UnsavedFiles\这两处。另外还有一个容易被漏掉的目录是%TEMP%，Word 的~WRL####.tmp常常落在那里。

崩溃和断电的区别也值得说一句。如果是 Word 进程崩溃或被强制结束，Windows 还活着，Word 的自动恢复信息通常能完整落盘，重启 Word 后会主动弹出恢复面板。如果是整机断电，操作系统自身的文件缓存可能还没来得及刷盘，这时候.asd可能只写了一半，甚至完全没写，需要靠%TEMP%里的临时文件或者系统的文件系统日志去碰运气。所以“断电”这一类事故，成功率天然低于“Word 崩了”，这不是方法问题，是物理层面的时间窗口问题。

还有一个绕不开的边界：如果崩溃前你恰好点了保存，而且保存动作已经完成了文件替换，那么新内容就是安全的；如果保存动作还在写临时文件阶段就崩了，原文件是旧的、临时文件是新的，你要找的是临时文件。这也是为什么恢复的第一步永远是“先别动那个目录里的任何东西”，包括别用清理软件、别重启、别再打开同名文档去覆盖保存。很多二次损失都是在这几步里发生的。

3. 四条恢复路径，按成功率从高到低排

下面这四条路径，建议严格按顺序尝试。原因很简单：越靠前的路径操作成本越低、对原始文件的破坏风险越小。上来就改后缀、动注册表，反而可能把本来能救的文件搞坏。

3.1 路径一：重启 Word 后等“文档恢复”窗格

这是成功率最高、也最容易被错过的一条。Word 崩溃后重新打开，左侧会出现一个“文档恢复”任务窗格，列出它认为可以恢复的文件。很多人一看到这个窗格就急着点“关闭”，或者直接去点新建空白文档，窗格一关就再也调不出来了。

正确的做法是：崩溃后先别急着重开一堆文档，单独启动一次 Word，等这个窗格出现，把里面带时间戳的条目全部看一遍。条目名后面一般会标注“已恢复”“原始文件”这类状态，选时间最接近崩溃时刻的那个，点开确认内容，然后立刻“另存为”到一个新路径，不要直接点保存覆盖原文件。这一步的本质是把内存残留转成磁盘上的正式文件，转完才算安全。

如果窗格没出现，也不要认定没戏，说明 Word 这次没检测到待恢复项，继续走后面三条。

3.2 路径二：文件 → 信息 → 管理文档 → 恢复未保存的文档

这是 Word 内置的一个专门入口，位置在“文件”菜单的“信息”页，找到“管理文档”按钮，下拉里有一项“恢复未保存的文档”。点它之后会弹出一个文件选择对话框，直接定位到自动恢复目录，把里面的.asd文件列出来，选中打开即可。

这个入口的价值在于：它不需要你去手动拼路径，Word 自己知道自动恢复目录在哪。如果这里弹出来的目录是空的，说明自动恢复机制在这台机器上要么被关掉了，要么确实没来得及写入，那就只能走路径三手动找。

顺带提一个常见误区：有人在这里看到文件列表，但文件类型下拉框默认只显示.asd，找不到.tmp。这时候把下拉框改成“所有文件”，才能看到其他残留物。

3.3 路径三：手动进自动恢复目录，按时间筛选

这是最“笨”但最可靠的一条。打开资源管理器，在地址栏直接粘贴下面这行，回车：

%APPDATA%\Microsoft\Word

如果这里是空的，再试另外两个：

%LOCALAPPDATA%\Microsoft\Office\UnsavedFiles %TEMP%

进去之后不要靠文件名判断，按“修改日期”倒序排列，重点看崩溃时间点前后半小时内的文件。.asd可以直接双击尝试用 Word 打开（有时会提示格式不符，见第 7 节的排查表）；.tmp需要先复制一份出来，改名为.doc或.docx再打开，务必复制而不是原地改名，原地改名会破坏原始证据，万一失败就彻底没得救了。

这一步真正容易踩坑的地方是扩展名被隐藏。Windows 默认“隐藏已知文件类型的扩展名”，你看到的~WRL0001其实全名是~WRL0001.tmp，改名的时候加上.doc会变成~WRL0001.tmp.doc，自然打不开。先在“查看”选项卡里把“文件扩展名”勾上，再动手。

3.4 路径四：回到文档原目录，找同名残留

如果文档本身有明确路径（比如D:\项目\方案.docx），一定要回到这个目录看一眼。这里最可能出现的是~$方案.docx（所有者文件，不含正文，删掉即可）和方案.wbk（备份文件，含上一次保存的完整内容）。

还有一种情况：目录里出现了一个名字很像但后缀奇怪的文件，比如方案.docx.tmp或者一串十六进制名字。这类文件不要凭名字放弃，用第 5 节的脚本按文件头识别，能直接判断出它到底是不是 Word 文档、是.doc还是.docx，比看后缀靠谱得多。

4. 动手前的环境准备与三件不能做的事

恢复这件事，工具不是关键，纪律才是关键。开始操作前，先把环境和禁忌确认一遍，能避免大量二次损失。

环境方面，你需要一台能正常运行 Word 的 Windows 机器，登录的必须是事故发生时那个 Windows 账户。自动恢复目录是跟着用户账户走的，用管理员账户去C:\Users\另一个名字\AppData下面翻，翻到的可能是别人的文件。如果文档在公司的域账户或漫游配置文件下，路径里的%APPDATA%会指向服务器重定向的位置，这一点在“文件—选项—保存”里能看到真实路径，以那里显示的为准。PowerShell 建议用 5.1 及以上（Windows 10/11 自带），Python 脚本需要 3.8 以上，标准库足够，不需要装第三方包。版本细节请以你实际项目环境为准，这里重点演示通用思路。

三件不能做的事，逐条说清楚原因。

第一，不要关机重启。很多人第一反应是“重启一下试试”，但重启会清空%TEMP%下的部分内容，也可能触发系统的磁盘清理。如果确实需要重启，先把第 5 节的脚本跑一遍，把候选文件复制到另一个盘。

第二，不要用清理软件“一键加速”。各类管家类的清理功能会把临时文件当作垃圾直接删除，~WRL####.tmp正好在清理名单里。事故当天，清理软件的自动清理计划最好先关掉。

第三，不要在原来的路径上做任何“保存”动作。包括打开同名文档后习惯性按 Ctrl+S。这一步会把原文件覆盖掉，如果原文件本身是完整旧版，覆盖之后就只剩半成品了。正确姿势是：所有恢复出来的文件都“另存为”到新目录，比如D:\recover_out\，验证内容无误后再决定是否替换。

另外提醒一句，如果文档涉及公司敏感信息，恢复过程中复制出来的临时副本要注意存放位置，别随手丢在公共共享盘或者临时目录里长期不清理。恢复完成后，把D:\recover_out里的中间文件按需删除，只保留确认有用的版本。这既是安全习惯，也避免以后自己搞混哪份是最终版。

5. 完整实操：用脚本把残留文件捞出来

手动翻目录适合“我知道大概在哪”的情况。如果你不确定文档当时存在哪个盘、或者崩溃前折腾过好几个位置，手动翻效率太低。下面三段脚本分别解决“找出来”“认出来”“以后别再丢这么多”。

5.1 用 PowerShell 批量扫描候选残留文件

第一个脚本做的是广撒网：在几个高概率目录里，把最近三天内修改过的、后缀匹配的、大小超过阈值的文件全部列出来，按修改时间倒序。之所以加时间过滤，是因为这些目录里常年堆着历史垃圾文件，不过滤的话输出几百条，根本没法看。

# 文件路径：C:\Tools\Find-WordRecovery.ps1 # 用途：扫描 Word 残留文件候选，按修改时间倒序输出 $searchRoots = @( "$env:APPDATA\Microsoft\Word", "$env:LOCALAPPDATA\Microsoft\Office\UnsavedFiles", "$env:TEMP", "$env:USERPROFILE\Documents", "$env:USERPROFILE\Desktop" ) # 只关心最近 3 天内改动过的文件，按事故时间自行调整 $since = (Get-Date).AddDays(-3) $patterns = @('*.asd', '*.wbk', '*.tmp', '*~$*') $results = foreach ($root in $searchRoots) { if (-not (Test-Path -LiteralPath $root)) { continue } Get-ChildItem -LiteralPath $root -Recurse -File -Include $patterns -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -ge $since -and $_.Length -gt 1024 } | Select-Object @{Name='Root';Expression={$root}}, FullName, @{Name='SizeKB';Expression={[math]::Round($_.Length / 1KB, 1)}}, LastWriteTime } if (-not $results) { Write-Host "未找到候选文件，请确认账户与时间范围是否正确。" -ForegroundColor Yellow } else { $results | Sort-Object LastWriteTime -Descending | Format-Table -AutoSize Write-Host "共找到 $($results.Count) 个候选文件。" -ForegroundColor Green }

关键逻辑有三处。-Include必须配合-Recurse一起用，否则不生效，这是 PowerShell 里一个很常见的坑。-LiteralPath而不是-Path，是为了防止路径里出现方括号之类的字符被当成通配符解析。Length -gt 1024这个过滤条件是为了排掉大量 0 字节的占位文件，Word 崩溃后经常会留下空壳，这些空壳没有恢复价值，只会干扰判断。

运行方式：在 PowerShell 里执行下面这行。如果系统默认禁止运行脚本，先按提示调整执行策略，注意只对当前进程生效，不要全局放开。

powershell -ExecutionPolicy Bypass -File C:\Tools\Find-WordRecovery.ps1

5.2 用 Python 按文件头识别真实类型并归集

找到一堆候选文件之后，下一个问题是“哪个才是真正的 Word 文档”。这时候不能信后缀，要信文件头。.doc和.asd这类老的复合文档格式，开头四个字节是D0 CF 11 E0；.docx这类基于 OOXML 的新格式，本质是个 zip 包，开头是PK\x03\x04。脚本读前四个字节就能判断，然后把命中的文件复制到一个统一目录，重命名成规范的.doc/.docx，方便你挨个打开试。

# 文件路径：recover_docx.py # 用途：按文件头识别 Word 文档残片，归集到指定目录 import os import shutil from datetime import datetime, timedelta OLE_MAGIC = b"\xd0\xcf\x11\xe0" # 复合文档：.doc / .asd / .wbk 等 ZIP_MAGIC = b"PK\x03\x04" # OOXML 包：.docx / .docm 等 def sniff_kind(path): """读取文件头 4 字节，返回 doc / docx / None""" try: with open(path, "rb") as f: head = f.read(4) except OSError: return None if head == OLE_MAGIC: return "doc" if head == ZIP_MAGIC: return "docx" return None def collect(src_dirs, out_dir, days=3, min_size=1024): os.makedirs(out_dir, exist_ok=True) deadline = datetime.now() - timedelta(days=days) hits = [] for d in src_dirs: if not os.path.isdir(d): continue for root, _, files in os.walk(d): for name in files: path = os.path.join(root, name) try: st = os.stat(path) except OSError: continue if st.st_size < min_size: continue if datetime.fromtimestamp(st.st_mtime) < deadline: continue kind = sniff_kind(path) if kind is None: continue hits.append((path, kind, st.st_size, st.st_mtime)) hits.sort(key=lambda x: x[3], reverse=True) for idx, (path, kind, size, mtime) in enumerate(hits, start=1): stamp = datetime.fromtimestamp(mtime).strftime("%Y%m%d_%H%M%S") target = os.path.join(out_dir, f"recovered_{idx:03d}_{stamp}.{kind}") shutil.copy2(path, target) print(f"[OK] {target} <- {path} ({size} 字节)") print(f"\n共找到 {len(hits)} 个疑似 Word 文档残片，已复制到 {out_dir}") if not hits: print("建议放宽 days 参数，或确认扫描目录是否正确。") if __name__ == "__main__": collect( src_dirs=[ os.path.expandvars(r"%APPDATA%\Microsoft\Word"), os.path.expandvars(r"%LOCALAPPDATA%\Microsoft\Office\UnsavedFiles"), os.path.expandvars(r"%TEMP%"), ], out_dir=r"D:\recover_out", days=3, min_size=1024, )

这里有两处设计值得说明。shutil.copy2而不是move，是为了保留原始的修改时间，同时不破坏源文件，万一这个文件还有别的用途，原样还在。命名里带上%Y%m%d_%H%M%S的时间戳，是为了你打开的时候一眼能看出哪个最接近崩溃时刻，不用再回去翻属性面板。输出目录放在 D 盘而不是%TEMP%，是因为%TEMP%本身就可能被清理，把恢复结果放进去等于白干。

运行：

python recover_docx.py

5.3 用注册表把自动恢复间隔调短

前三步是“事后补救”，这一步是“事前减损”。Word 的自动恢复间隔默认偏保守，如果你写长文档经常一写两小时，把间隔调成 3 到 5 分钟，最坏情况下的损失会小一个数量级。图形界面在“文件—选项—保存—保存自动恢复信息时间间隔”，如果要批量部署或者给团队统一设置，用注册表更快。

下面这段reg命令里的16.0对应当前几代 Office，更早的版本可能是15.0或14.0，先跑第一条查询确认你机器上实际存在哪个版本号再执行后面的写入，不要盲目照抄。

@echo off REM 文件路径：C:\Tools\set-autorecover.bat REM 用途：开启自动恢复并把间隔调为 3 分钟 REM 第一步：确认本机 Office 的版本号目录 reg query "HKCU\Software\Microsoft\Office\16.0\Word\Options" >nul 2>&1 if errorlevel 1 ( echo 未检测到 16.0 版本目录，请先手动确认实际版本号。 goto :eof ) REM 第二步：写入配置 reg add "HKCU\Software\Microsoft\Office\16.0\Word\Options" /v Autorrecover /t REG_DWORD /d 1 /f reg add "HKCU\Software\Microsoft\Office\16.0\Word\Options" /v AutorrecoverTime /t REG_DWORD /d 3 /f reg add "HKCU\Software\Microsoft\Office\16.0\Word\Options" /v AutoSaveTime /t REG_DWORD /d 3 /f echo 配置已写入，完全退出 Word 后重新打开生效。

Autorrecover是总开关，AutorrecoverTime是自动恢复间隔（单位分钟，合法范围一般是 1 到 120），AutoSaveTime和自动保存相关。改完必须把 Word 完全退出（包括托盘里的后台进程）再启动，否则注册表值不会重新读取。如果是公司统一管理的电脑，注册表可能被组策略锁定，写不进去属于正常现象，走图形界面设置即可，不要强行破解权限。

6. 结果验证：怎么判断哪个文件才是你要的

脚本跑完，D:\recover_out里可能躺着十几个文件。这时候最怕的是“挨个双击”，一方面是慢，另一方面是万一某个文件已经损坏，Word 反复报错反而让人心态崩掉。更稳妥的顺序是这样：

先按文件名里的时间戳排序，把范围缩小到崩溃时间点之前 30 分钟内的几个。然后用 Word 的“打开”对话框打开，不要双击，因为双击可能触发某些默认关联程序。打开时如果弹出“文件格式与扩展名不一致”的提示，选“是”继续，这是正常现象，.asd改成.doc之后必然会有这个提示。

打开之后看三个指标判断完整度：一是文档末尾是不是你最后写的那段内容；二是页数、字数统计是否接近预期；三是样式、表格、图片有没有明显错位。如果末尾缺一段，说明这个文件是较早的自动恢复快照，回去再试时间戳更晚的那个。如果打开就报“文件已损坏，无法打开”，说明这个文件写到一半就断了，换下一个，不要反复尝试修复同一个。

还有一种情况需要特别说明：打开发现内容是别的文档。这通常是因为%TEMP%里堆着历史上多个文档的残留，你打开的是上一次事故的遗留物。这也是脚本里加days=3时间过滤的原因，把范围收窄能大幅降低这种误判。

确认无误后的动作是固定的：立即“另存为”一个正式文件名，存到你的工作目录，然后关掉恢复出来的文件。不要直接在恢复文件上继续编辑，因为这类文件的内部结构可能不完整，继续编辑保存有概率触发二次损坏。另存为一次，等于把内容迁移到干净的容器里。

7. 常见问题与排查思路

下面这张表覆盖的是实际处理时最常撞上的几种情况。每一条都尽量给出“先看哪里”，而不是笼统地说“重试”。

表格里最值得展开的是第一条和第七条。第一条的坑在于：很多人%APPDATA%粘进去发现是空的，就以为没救了，其实是文档从来没保存过、自动恢复又恰好没触发。这种情况下%TEMP%里的~WRL####.tmp才是唯一希望。第七条的坑在于认知错位——OneDrive 上的文档根本不用本地恢复那套流程，版本历史里通常保留着多个时间点的快照，比本地恢复靠谱得多，前提是同步已经完成。

8. 让“忘记保存”不再致命：工程化习惯与备份策略

恢复技术再熟，也是事后补救。真正把损失压到接近零的，是把“保存”这件事从依赖人的记忆，变成依赖机制。下面这几条按投入产出比排序，前两条几乎零成本。

第一条，把自动恢复间隔调到 3 到 5 分钟。这是本文所有建议里性价比最高的一个动作，一次设置，长期受益。代价是 Word 会稍微多写一点磁盘，对现代机器完全可以忽略。

第二条，养成“分段另存”的习惯。写长文档时，每到一个小节点就“另存为”一个带日期的副本，比如方案_v3_20250310.docx。这听起来很土，但它是唯一不依赖任何软件机制的保底手段。软件会崩、云会断、盘会坏，多一个物理副本就多一层保险。

第三条，重要的本地文档放进 OneDrive 同步目录。注意这里说的是“同步目录”，不是“上传一份到网盘”。放进同步目录后，Word 左上角的自动保存开关才会真正生效，而且每一次保存都会在云端形成版本记录，误删、误改、覆盖保存都能从版本历史里捞回来。这条对经常改稿的人价值极大，代价是要接受文件在云端有一份副本。

第四条，用 VBA 做一个轻量的定时备份。如果你的 Word 环境允许宏（很多公司出于安全考虑会禁用，禁用时不要强行绕过），可以在 Normal 模板里挂一个定时器，每隔一段时间把当前文档另存一份到指定目录。这类脚本要写在个人模板里，不要写进共享模板，避免影响其他人。

' 文件路径：Normal.dotm 中的 ThisDocument 模块 ' 用途：每 10 分钟自动备份当前文档到指定目录 ' 注意：宏安全性由公司策略决定，禁用环境下不要强行启用 Dim NextBackup As Date Private Sub Document_Open() NextBackup = Now + TimeValue("00:10:00") Application.OnTime When:=NextBackup, Name:="DoBackup" End Sub Sub DoBackup() On Error GoTo Done If ActiveDocument.Path = "" Then GoTo Done Dim target As String target = "D:\WordBackup\" & Format(Now, "yyyymmdd_hhnnss") & "_" & _ ActiveDocument.Name ActiveDocument.SaveCopyAs target Done: NextBackup = Now + TimeValue("00:10:00") Application.OnTime When:=NextBackup, Name:="DoBackup" End Sub

这段宏的关键是SaveCopyAs，它把当前内容写一份副本出去，但不改变当前文档的“已保存”状态，也不会覆盖原文件，安全性比较好。On Error GoTo Done是为了防止某次备份失败导致定时链断掉，出错后仍然会排下一次。目标目录D:\WordBackup\需要提前建好，路径不存在时SaveCopyAs会直接报错。

第五条，团队层面统一模板和存放规范。这一条听起来和恢复无关，其实关系很大。文档散落在桌面、下载目录、U 盘、微信接收文件夹里，事故发生后光“确认文件在哪”就要花十几分钟。约定一个统一的存放目录结构，等于把恢复时的搜索范围从“整个硬盘”缩到“一个文件夹”。另外，共享目录的写入权限按最小权限原则分配，避免有人误覆盖别人的稿子。

最后补一句 Mac 用户的差异：macOS 版 Word 的自动恢复文件位置在~/Library/Containers/com.microsoft.Word/Data/Library/Preferences/AutoRecovery/，第 5 节的 Python 脚本稍改路径就能用，PowerShell 换成 shell 即可，思路完全一致。

9. 收尾：把恢复能力变成流程，而不是运气

回过头看这件事，真正决定成败的不是某个“神技”，而是三个判断：崩溃之后你有没有立刻停手、你知不知道数据可能落在哪几个目录、你能不能在几十个候选文件里快速锁定正确的那一个。这三点分别对应“不制造二次损失”“知道去哪找”“会用脚本筛”，缺任何一环，都可能把一次本可挽回的事故变成彻底重来。

如果你现在手上正有一份没保存的文档，动作顺序应该是：先别关机，先跑一遍 5.1 的扫描脚本，再用 5.2 归集，然后按时间倒序逐个用 Word 打开验证，确认后立刻另存为。整个过程控制在半小时内，比重新写一遍划算得多。如果事故已经过去、文档也重写完了，那更该做的是把第 8 节的前三条落下去：调短自动恢复间隔、养成带日期另存的习惯、把重要文档放进同步目录。这三件事加起来不超过十分钟，但它们决定了下一次事故来临时，你是花十分钟恢复，还是花一晚上重写。

还有一点值得延伸：.asd和.tmp能被识别出来，本质是因为它们保留了完整的文件头结构。同样的思路可以迁移到其他办公格式上，比如 Excel 的恢复文件、PPT 的临时文件，识别逻辑大同小异，只要把脚本里的文件头常量和后缀匹配改一改就能复用。真正值得掌握的不是某个具体目录路径，而是“先看文件头、再看时间戳、最后看内容完整度”这套判断方法。把脚本和这份排查表存下来，下次不管是自己还是同事遇上，都能少慌一会儿。