Anaconda误删自救手册：conda环境备份与快速恢复指南

上周三晚上十一点，朋友在群里发了张截图，我隔着屏幕都能感觉到他手在抖。下午他清理D盘空间，看到那个装了几个月、日常总觉得没怎么用到的Anaconda文件夹，顺手就Shift+Delete了。晚上打开项目准备跑代码，才发现conda、python、虚拟环境连带整个解释器全没了。他给我打电话的时候声音都在发飘，我在这边一步步指挥他排查、重装、恢复环境，最后大约花了半个小时把开发环境拉了回来。今天把这套急救流程整理成文——Anaconda误删这事儿，看着吓人，但绝大多数情况下都能救回来，关键是得知道每一步在干什么，以及哪些东西能救、哪些东西救不了。

先说个结论方便你安心：误删Anaconda后，你最担心的"代码全没了"通常不成立——项目源码只要不在Anaconda安装目录里就安然无恙。真正丢的是Python解释器、虚拟环境、已经装好的第三方包。这套东西的恢复思路很简单：先诊断现场，再止损抢救，然后重装Anaconda本体，最后重建环境和依赖。如果你之前做过环境导出备份，30分钟完全够用；没有备份，也能靠记忆和项目代码反推出需要的包，只是要花时间多试几轮。

1. 先给事故定级：你的Anaconda是哪种死法

1.1 三种最常见的误删场景

我接触到的误删案例，基本可以归成三类，先对号入座一下，后面恢复的难度和策略完全不同。

第一类是直接删除整个Anaconda安装目录，也就是我朋友这种。清理磁盘空间的时候，对着C:\Users\你的用户名\anaconda3或者D盘某个自建的文件夹，右键Shift+Delete一把梭。这类事故最惨烈，因为envs虚拟环境目录、pkgs包缓存、base环境下的所有第三方包全跟着没了。不过好消息是，如果你把Anaconda装在非系统盘（比如D盘），而且删除前没有大量写文件，数据恢复工具还有可能捞回来一部分。

第二类是通过Windows"添加或删除程序"里卸载Anaconda，然后用着用着发现少了东西。比如之前创建过的虚拟环境在某些IDE配置里还挂着路径，点了运行直接报错找不到解释器；或者你在Anaconda Prompt里建的虚拟环境，卸载时没做conda env export备份，整个环境列表就没了。这类误删属于"反悔型"，卸载程序确实会删掉安装目录里的内容，但用户目录下的.conda、.condarc、.jupyter这些配置往往还会残留，恢复起来比直接Shift+Delete温和得多。

第三类是"部分误删"。常见于迁移环境、整理文件夹时，把某个虚拟环境文件夹envs\pytorch_env单独删了，或者手滑把用户目录下的.conda文件夹清空。这一类恢复成本最低——base环境还在，Anaconda本体没坏，你只需要重建那一个虚拟环境；但如果你连当初创建这个环境时装了哪些版本的包都记不清了，要花的时间也不一定少。

1.2 临床诊断：确认Anaconda当前状态

不管哪种死法，第一步永远是诊断，而不是直接去装新的。你要在命令行里做三个快速检查，判断Anaconda现在是"瘫痪"还是"彻底消失"。

Windows下打开cmd或PowerShell，Mac/Linux打开终端，依次敲：

bash复制conda --version
python --version
where conda

如果第一行提示conda不是内部或外部命令（Mac/Linux是command not found），说明conda的可执行文件已经不在PATH里了；接下来where conda能帮你确认系统里是否还残留任何conda相关路径。注意where conda在Windows下有特殊含义，如果命令不存在会直接提示找不到文件，这本身就是一条诊断信息。

然后去检查原始安装目录。默认路径各系统不一样，Windows通常是C:\Users\用户名\anaconda3，Mac是/opt/anaconda3或/Users/用户名/anaconda3，Linux常见于/home/用户名/anaconda3。文件管理器里看一眼目录还在不在，注意目录存在但里面的envs或python.exe消失的情况也很常见。

最后一步，Windows用户去"控制面板 -> 程序和功能"里搜Anaconda；Mac用户看一眼/Applications下有没有Anaconda Navigator。这里要区分一个坑：如果目录还在、程序列表还在，但命令行用不了，通常是环境变量被改坏了，或者Anaconda Prompt的快捷方式指向了不存在的路径；这种情况压根不用重装，重新配置环境变量就行。如果目录没了、程序列表也没了，直接跳到重装步骤。

1.3 信息采集：恢复前的黄金线索

诊断的同时，赶紧做一件事：把你能回忆起来的信息写下来。恢复环境最怕的是"记得装过，但忘了装的是什么版本"。需要记录的线索包括：

• 原Anaconda安装路径和目录名（后面装新版本时可以选同路径，省很多事）
• base环境的Python版本（比如Python 3.9），旧项目的要求大致能推断出来
• 你创建过哪些虚拟环境，每个环境大概用途（项目A用的、深度学习用的、写爬虫用的）
• 特别看重的大包版本：pytorch、tensorflow、paddlepaddle这类框架，版本错了GPU都用不了
• 之前是否导出过environment.yml或requirements.txt
• 有没有用conda-pack打包过环境

我朋友的情况是：日常写过一次pip freeze > requirements.txt，但文件存在Anaconda目录里的某个项目文件夹下，结果被一起删了。如果你也是这类情况，先别急着哭，磁盘还没被大量覆盖的话，数据恢复工具还有机会。这一节的信息，直接决定后面第4章的重建方案是"照单复原"还是"猜谜式安装"。

2. 前10分钟：止损、清残、抢救配置文件

2.1 立即停止对原目录所在盘的大量写入

误删之后，大多数人打电话求助之前还会干一件事：把系统里能开的软件都开一遍，或者继续下载新的安装包。千万打住。尤其是你原来的Anaconda装在系统盘C盘，删除后那个区域的空间一旦被新写入的文件覆盖，被删的数据就真的回不来了。

如果你是机械硬盘，或者SSD没开Trim（很多老款SSD），删掉的文件其实还躺在磁盘上，数据恢复工具能找回。NVMe固态基本没戏，因为Trim会立刻清空被删块的数据。但即便希望渺茫，你也没有损失——停止写入，然后尽快用恢复工具扫一遍。

你应该做的止血操作是：不再往Anaconda原目录所在分区下载东西、不安装新的Python环境、不跑大型编译、不清理"已删除的文件空间"。如果Anaconda在D盘，那么C盘该用用，D盘尽量少写。这个动作的成本为零，但很多时候能救回一整个虚拟环境。

2.2 抢救还能读的配置：.condarc和用户目录

很多人不知道，Anaconda安装在哪个目录只代表程序本体，而你真正重要的配置大多散落在用户目录下。这些文件只要没被主动删除，卸载Anaconda也不会动它们。恢复时先检查这些，能救回一大半的环境痕迹。

打开文件管理器，进入用户目录（Windows是C:\Users\你的用户名，Mac/Linux是~），找下面这些东西：

• .condarc：conda的配置文件，里面记录了镜像源、channel地址、默认环境路径
• .conda目录：包含environments.txt（记录创建过哪些虚拟环境的路径）、envs下的软链
• .jupyter目录：如果用过Jupyter Notebook，你的自定义配置、kernel列表在这里
• 项目目录下的requirements.txt、environment.yml、conda_packages.txt：这些是环境的快照文件

把这些文件原样复制到一个安全位置。.condarc里面可能有你手工配置的清华源、阿里源，恢复后直接把文件拷回去就能用，不用重新配。.conda\environments.txt则记录了之前所有conda环境的位置，后面装好Anaconda后，可以通过命令让conda重新认这些路径。

2.3 清理Windows残留的环境变量与注册表项

如果你决定重装Anaconda，安装之前最好先把旧的残留清一下，否则可能出现装完还是conda命令不可用，或者打开Anaconda Prompt报出一堆路径错误的情况。

Windows下主要看三处：

一是用户环境变量里的PATH。按Win + R输入sysdm.cpl打开系统属性 -> 高级 -> 环境变量，检查用户变量和系统变量里的Path，把指向原Anaconda目录的条目删掉，比如C:\Users\xxx\anaconda3、C:\Users\xxx\anaconda3\Scripts、C:\Users\xxx\anaconda3\Library\bin。不删的后果是：新装的Anaconda如果换了路径，旧PATH会先被找到，导致各种错乱。

二是开始菜单快捷方式。如果之前装过Anaconda Navigator，删除后开始菜单里可能留着指向不存在路径的快捷方式，顺手清理掉。

三是注册表。大部分情况下不需要手动改注册表，但如果你是用官方卸载程序卸载的，它其实会在注册表里留下HKCU\Software\Python\PythonCore这类条目。重装Anaconda时安装程序会尝试覆盖，一般没事。除非你是想彻底清干净再装，否则不建议轻易动注册表，误删了其他Python的注册项反而更麻烦。

2.4 Mac/Linux的shell配置清理

Mac和Linux上，Anaconda安装时会往shell配置里追加一段初始化代码。打开~/.bashrc、~/.zshrc或~/.bash_profile，你会看到类似：

bash复制# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/opt/anaconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/opt/anaconda3/etc/profile.d/conda.sh" ]; then
        . "/opt/anaconda3/etc/profile.d/conda.sh"
    else
        export PATH="/opt/anaconda3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

如果原Anaconda目录已经被删，这段代码每次打开终端都会报错找不到路径。重装前可以把这段注释掉或删掉，也可以用conda init重新生成。这里要特别提醒：不要在执行conda init之前手动改PATH把新Anaconda的bin目录加进去，否则容易和你系统自带的Python搅在一起。正确顺序是：先删旧初始化块，重装，再让新Anaconda的conda init自己生成。

3. 中间10分钟：重装Anaconda的正确姿势

3.1 下载渠道与版本选择：官方还是镜像

诊断做完了，残清得差不多，接下来就是装回一个能用的Anaconda。

下载渠道有两种，一个是官方渠道repo.anaconda.com，另一个是镜像站。国内网络环境下，官方下载经常慢到怀疑人生，我一般直接用清华镜像的Anaconda安装包：https://mirrors.tuna.tsinghua.edu.cn/anaconda/archive/。这里能看到历史上所有版本的安装包，推荐选择最近几个月发布的版本，不要追最新，也不要选太老的，2023年以后的版本对Python 3.11/3.12支持得都很好。

版本选择的原则：如果你的项目代码没有历史包袱，直接装最新版；如果项目里用了很多老依赖，比如tensorflow很老、numpy编译版本敏感，那最好装一个和原来接近的版本。举个例子，原来用的是Anaconda 2023.09，那新装也尽量选这个跨度内的，因为conda defaults通道里的包版本会跟安装器版本走，太新的Anaconda默认Python 3.12，部分老包还没适配，装完再降版本反而麻烦。

3.2 安装路径与关键选项

安装路径我强烈建议你选得跟原来一模一样。为什么？因为.condarc里的envs_dirs、PyCharm里关联的解释器路径、Jupyter kernel的配置文件，全都写着绝对路径。你装回同一个位置，这些配置直接复活；换一个新路径，就得一条条去改绝对地址，费时还容易漏。

Windows安装时有两个关键选项要注意。第一个是"For All Users"（所有用户），选这个通常需要管理员权限，安装后C盘外的路径更自由，但权限问题可能影响后续写入；如果没有多用户需求，选Just Me就行。第二个最关键的"Add Anaconda to my PATH environment variable"——官方安装器默认不勾选。我建议恢复场景下也别勾，因为勾了以后，你系统里如果还有别的Python，两边的python命令会打架。正确的使用方式是装完之后，用Anaconda Prompt或者执行conda init来管理环境。

Mac安装时注意安装器末尾会让你选择"Install for me only"还是"Install for all users"，然后有一个"Add Anaconda to my PATH"的选项，同理建议不选。Linux下用.sh脚本安装时，默认是装到/home/用户名/anaconda3，后面会让你选是否conda init，这一步选yes就行。

3.3 安装完成后的初始化配置

装完以后，第一步不是急着建虚拟环境，而是先做三件初始化的事。

第一件事，打开新的命令行窗口，运行conda --version确认conda已经可以被找到。如果提示找不到命令，而你又没勾选Add to PATH，就用Anaconda Prompt（Windows）或者手动执行：

bash复制export PATH="/你的安装路径/bin:$PATH"

但这不是永久方案。Windows下在Anaconda Prompt里执行conda init cmd.exe或conda init powershell，Mac/Linux执行conda init bash（zsh用户执行conda init zsh），然后重新打开终端窗口，conda命令就自动挂进shell了。

第二件事，检查.condarc配置。如果你在前面抢救阶段把原有的.condarc复制回来了，直接覆盖回去，然后运行conda info查看channel配置；如果没有，现在手动配置镜像源，否则后面创建环境时下载包会慢得让你怀疑人生。关于换源和那个让人头疼的404报错，我在第5章会专门讲，这里先不展开。

第三件事，更新conda自身：

bash复制conda update conda
conda update --all

这个步骤不能省。旧版的conda对新的channel地址解析、Python 3.12支持都不好，新装的Anaconda自带conda可能不是最新版，先更新能避免不少坑。

3.4 重装后的目录结构自检

装完初始化完，花一分钟检查一下目录结构是否正常，避免后面建环境时才发现问题。看一眼你的Anaconda根目录下应该有这几个标准文件夹：

• envs：存放所有conda虚拟环境，初始应该是空的或只有base
• pkgs：包缓存的目录，新装完里面会预置一批包的缓存
• Library（Windows专属）：运行库
• Scripts（Windows）/bin（Mac/Linux）：可执行命令所在目录

如果这些目录不齐全，比如连envs都没有，后面创建环境时会自动生成，不用太担心。但如果你看到原有pkgs目录还有残留的缓存，这反而是个好消息——里面存的包缓存能加速环境恢复，只要conda配置的pkgs_dirs指向对了就行。

4. 最后10分钟：重建虚拟环境与包依赖

4.1 有备份的情况：environment.yml与conda_packages.txt还原

这是最理想的情况，照单复原，基本不会出错。

如果你之前导出过environment.yml，恢复就是一条命令的事：

bash复制conda env create -f environment.yml

这个命令会按照yml文件里的依赖列表创建同名的虚拟环境。但有个细节坑必须提醒你：用conda env export导出的yml文件，最后一行通常带着prefix: /你的原路径/envs/环境名。如果你新装的Anaconda路径和原来不一样，conda会试图往这个旧路径写文件，然后报错。解决办法很简单，用文本编辑器打开yml文件，把最后一行prefix删掉再执行。

如果你拿到的是requirements.txt，那就要分两步。先创建环境，再装pip包：

bash复制conda create -n myenv python=3.9
conda activate myenv
pip install -r requirements.txt

分两步的原因是：requirements.txt里通常只有pip包名和版本，没有Python本身的信息。如果你直接pip install -r，pip会用当前环境（比如base）的Python去装包，万一base是Python 3.12而项目要3.9，装出来的包很容易出兼容性问题。

至于conda list --export导出的conda_packages.txt，恢复方式和resources类似，但它会完整记录包的channel和build版本号，所以同样的环境能还原得更加精确：

bash复制conda create -n myenv --file conda_packages.txt

4.2 没有备份的情况：凭记忆重建的目标引导式安装

没备份是常态，毕竟大多数人是误删之后才意识到"原来环境也是资产"。但没备份不等于只能从头瞎装，你项目代码本身就是最好的线索。

先进入项目目录，看有没有requirements.txt或者pyproject.toml、environment.yml这类文件躺在里面。很多项目初始化时会顺手生成依赖清单，只是你没注意到。没有的话，翻一下项目源码顶层，import语句会直接告诉你需要哪些库。用我朋友的项目举例：他的代码里import了torch、numpy、pandas、matplotlib，那么重建时至少要把这些装齐。

推荐的安装顺序是：先根据项目要求确定Python版本，创建虚拟环境，再装框架级大包，最后装小功能包：

bash复制conda create -n project_env python=3.9
conda activate project_env
conda install pytorch torchvision torchaudio pytorch-cuda=11.8 -c pytorch -c nvidia
pip install numpy pandas matplotlib scikit-learn jupyter

大包比如pytorch、tensorflow，用conda装更好，因为conda会解析C++依赖（CUDA、MKL）；小功能包用pip装更快，因为pypi上包通常比conda defaults上版本新。混合安装虽然不算"最优雅"，但实际项目里这已经是最快的恢复路径了。装完先别急着写代码，把项目根目录跑到能import，确保基础依赖都齐，再继续加。

4.3 恢复Jupyter、PyCharm等周边关联

环境重建完，还要处理周边工具的关联。这部分最容易被忽略，导致你明明环境建好了，打开PyCharm却还是找不到解释器，或者Jupyter里看不到新恢复的kernel。

Jupyter方面，如果你新装了Anaconda，jupyter命令是在base环境里的。要让Jupyter能用你新建的虚拟环境，先激活那个环境，然后安装ipykernel并注册kernel：

bash复制conda activate project_env
conda install ipykernel
python -m ipykernel install --user --name project_env --display-name "Python (project_env)"

这样打开Jupyter Notebook时，新建笔记本的下拉列表里就会出现你恢复的环境。如果你抢救回了.jupyter里的自定义配置，把它放回用户目录，之前的主题、快捷键、密码这些设置都能恢复。

PyCharm这边，打开File -> Settings -> Project -> Python Interpreter -> Add Interpreter -> Add Local Interpreter，选择Conda Environment，Python解释器路径指到你新装的Anaconda目录下的python.exe（Windows）或bin/python（Mac/Linux），Conda可执行文件路径指到conda.exe或conda，然后在下拉框里选中你新建的虚拟环境。如果之前项目里只有一个解释器路径，PyCharm的配置其实存储在.idea里，重新选一次就完事，不算麻烦。

5. 恢复后的体检：验证环境并避开常见坑

5.1 一套可复用的环境完整性检查清单

环境搭好别急着庆祝，先过一遍体检清单。我每次恢复环境后都会跑一整套命令，确保没有隐藏的坑。

bash复制conda --version
conda env list
python --version
python -c "import numpy; import pandas; print('core ok')"

然后进入项目目录跑一下python main.py或者pytest，看能否完整跑通。如果项目里用了GPU，再多一步验证CUDA在你的PyTorch里真的可用：

bash复制python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

还有一个很容易忽略的点：检查自己的命令行终端里pip是不是指向当前环境的pip。很多人激活环境后敲pip --version，发现pip还是base那个，然后一股脑装到了base里。解决方法是激活环境后执行python -m pip --version来确认，这也是为什么我在恢复依赖时都建议用python -m pip install而不是直接pip install。

5.2 换源后404报错的根因与处理

热搜词里几乎天天有人搜"unavailableinvalidchannel: http 404 not found for channel anaconda/pkgs/free"，包括pkgs/msys、pkgs/r这几个路径。这个报错是conda在安装包时试图访问一个已经不存在的channel地址导致的，几乎全和老的镜像源配置有关。

历史原因大概是这样的：清华镜像早年提供过anaconda/pkgs/free、anaconda/pkgs/msys这些子路径，后来上游频道调整，这些路径被合并或移除了。如果你在.condarc里还写着这些旧地址，conda第一次安装包时就会去访问，拿到404。

正确的.condarc配置应该是这样（以清华源为例）：

yaml复制channels:
  - defaults
show_channel_urls: true
default_channels:
  - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main
  - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r
  - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2
custom_channels:
  conda-forge: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud
  pytorch: https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud

注意msys还是msys2，别写错。配置完执行conda clean -i清一下索引缓存，再conda update --all验证。如果你用的是其他镜像，建议直接对照镜像站给出的最新配置，不要用网上抄来的旧配置。

5.3 包版本冲突的排查思路

恢复环境时最磨人的不是装不上，而是装了A后B又崩了。比如你先pip install装上了一个新版本的numpy，后面conda装pandas时想要旧版numpy，conda一看不满足就报冲突。

我自己的经验是遵循两条原则，能规避大多数冲突：第一，能交给conda装的大包（涉及编译依赖的）就统一用conda装；第二，pip只装纯Python包的场景，或者conda里实在没有的包。如果安装过程中遇到依赖冲突，不要反复pip install强行覆盖，那会把conda的依赖树搞乱。正确姿势是：

bash复制conda list --explicit > explicit_pkg_list.txt
conda list | grep 冲突的包名

看看到底是谁在冲突，然后决定是调整包的版本（比如conda install numpy=1.24）还是把环境推到重建。如果环境已经改得乱七八糟，与其在里面解冲突，不如删掉新建一个，更快也更干净。很多人不敢删环境，其实环境这东西本来就是可以反复迭代的资产，只要代码和依赖清单在，重建成本远小于修的成本。

6. 复盘与防复发：环境备份的实际做法

6.1 误删Anaconda的深层原因与防误删操作

误删Anaconda很少是因为故意，更多是视觉疲劳——那个文件夹在磁盘里躺了好几个月，你都快记不清它干嘛的了，某次清理磁盘时顺手就删了。在动手删除之前，你可以做几个低成本的动作，从源头上杜绝惨案。

第一，在Anaconda根目录下放一个README.md说明文件。一开始可能觉得有点傻，但它确实管用。文件里写上"这是Anaconda环境根目录，删除前先看环境备份：conda env export"。下次你或别人看到文件夹，打开文件一看就冷静了。第二，把Anaconda目录在PyCharm或资源管理器里重命名成更显眼的名字，比如anaconda3_DO_NOT_DELETE。第三，Windows用户可以在回收站属性里把"不将文件移到回收站"的选项关掉——很多人习惯勾选这个，以为删了就直接清空是省事，实际上是给自己挖坑。

6.2 适合开发者的轻量级备份方案

比起文件和目录级的备份，我强烈建议你把"环境配置"当成核心资产来备份。一个环境真正的价值不是python.exe文件本身，而是那几十上百个包的版本组合。备份环境有几种思路，从轻到重排个序。

最轻量的是定期导出依赖清单。给每个重要项目维护一份environment.yml或requirements.txt，放在项目仓库里。导出命令很简单：

bash复制conda activate 某环境
conda env export > environment.yml
pip freeze > requirements.txt

这两个文件都能直接还原环境。区别是：environment.yml还包含conda的channel和依赖关系，还原出的环境和原来的接近度最高；requirements.txt只覆盖pip层，纯Python项目的常用选择。Git仓库里最好两个都留一份，反正都是文本，体积小到可以忽略。

如果有那种特别依赖系统库的环境，光是清单还不够，推荐用conda-pack打包成压缩文件。它会把整个环境目录打成tar.gz，别人拿到手直接解压，激活一下就能用，不用重新下载任何包。适合跨机器迁移的场景，比如换电脑、给同事部署。命令是：

bash复制conda install conda-pack
conda pack -n myenv -o myenv.tar.gz

我的习惯是每个月跑一次环境导出，把yml和txt文件推进项目的Git仓库，版本变了自动有记录，哪天环境出问题了，直接拉历史版本回来还原。

6.3 换个思路：Miniconda是否更适合你

这次误删之后其实是个反思的机会：你真的需要Anaconda这个全家桶吗？很多人在恢复时纠结"要不要换回Miniconda"，我的建议是，如果你日常开发主要依赖pandas、numpy、scikit-learn、pytorch这些包，而且对Jupyter Notebook有需求，那么装Anaconda是因为它开箱即带了一百多个常用包，不用一个个装。但如果你常年只在一个虚拟环境里工作，或者大部分时间在用PyCharm/VSCode而不是Jupyter，那么Miniconda会是一个更清爽的选择。

Miniconda只有conda、Python和极少数基础包，体积大概四分之一。安装后你需要什么就conda install什么，环境配置思路完全一样，environment.yml两边通用。用Miniconda的好处是base环境极其干净，不会出现Anaconda自带了一堆旧版本包、然后你要花时间升级的尴尬。代价是装新环境时需要多敲几条命令，但这对想保持环境可控的人来说反而是优点。

如果你决定换到Miniconda，恢复步骤基本一致：装好Miniconda，配置.condarc，然后conda env create -f environment.yml。以前在Anaconda里建的环境，在Miniconda里一样能重建。

最后再分享一个我自己的小技巧：我会在每次装好一套新环境、跑通项目之后，立刻conda env export > environment.yml，然后把这份文件外加一份README放进项目目录。这件事花不了两分钟，但一旦碰上今天这种误删事故，你就能真正体会到什么叫"手里有粮，心里不慌"。要是连项目目录都一起被删了，那也别急，先试试数据恢复工具扫一遍，你要是平时把项目代码推到Git远端，环境清单也一起提交上去，那些就都还在云端躺着，等你回来。