Windows 入门指南

本文信息

作者：The Only Ethene

状态：尚未审阅

虽然 LCPU 并不推荐使用 Windows 作为我们的开发工具，但是 Windows 目前依然具有以下的优势：

• 占有了目前计算机系统市场的最大份额
• 与其配套的 Microsoft Office 系列更是目前比 LaTeX 使用更广泛的办公软件
• 目前使用最广泛的游戏编程语言是微软的 C#，而 C# 跨平台做得很一般，导致开发几乎不得不用 Windows
• Linux 和 Mac 不太能打游戏

因此我经过深思熟虑还是写了这一章。

由于 Windows 版本繁多，我们在这里讲述的是 Windows 11 23H2 及其更高版本系统。

同时，为了简便起见，我将会模仿 Linux 规定以下“语法糖”：

在路径中，~ 全等于 C:/Users/YourName

Windows 风格的路径中会使用反斜杠 \ 代替 Linux 中的 / ，但是在微软拼音中 \（顿号） 比 / 难打得多，我个人也因为长期使用 Linux，也更喜欢使用 /（Windows 往往也兼容） 。 本文约定：在路径中的反斜杠和斜杠语义相同。

Windows 的大小姐脾气

找不到路的迷宫症候群

Windows 的注册表记录着系统最重要的配置信息，随意修改就像用马克笔在大小姐的日记上涂鸦——可能让系统直接崩溃。

与之类似的还有另一个迷宫——环境变量。虽然 Windows 安装软件只需要鼠标点点点就可以解决问题，但是装完以后你在 Powershell 里面把命令行一打，哇，

The term 'conda' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

虽然很离谱，但是这就是事实：装完软件以后，大多数情况下，终端并不知道自己已经增加了一个功能。

强制更新的茶话会

Windows 会在你最需要专注时突然宣布：“我要更新啦！”，并擅自决定 15 分钟后重启你的电脑。这种强制更新在温良的 Win7 那里还可以轻松地商量着关闭，但是在刁蛮的 Win11 那里这是不能碰的话题。这除了强制重启你的计算机，还有可能会影响你的系统环境，导致一些软件无法运行。

如果用 Arch Linux 这类滚动更新系统当生产服务器，然后一不小心sudo pacman -Syu的同学们应该对此深有体会；而 Windows 则是定期强制自动运行上述滚动更新命令，这非常令人不悦。话不多说，还是让我们看看 2024 年 7 月 19 日，全球多地同时发生的超大蓝屏事件吧。

你的权限呢？

用户账户控制（UAC）和 Defender 防病毒构成了双重枷锁。开发者编译程序要穿越证书签名、SmartScreen 过滤、Defender 误报三重关卡，其严格程度堪比过境海关。这种安全策略本质是微软对自家闺女衣服打的补丁—— Windows 的漏洞极多。当然，这一套管理机制虽然牺牲了自由度，但是确实显著增加了 Windows 系统的安全性。

这种“大小姐脾气”与开源生态形成鲜明对比：Linux 默认相信用户是系统的真正主人，所有组件都可审查、可修改、可替代。

警告

不要执行下面代码块的命令！你的 Linux 必然会在执行以下命令后坏掉！

> sudo rm -rf /
> Password: ********
然后你的Linux就坏掉了，而且是接受你的命令后不带一丝迟疑自毁的（悲）

一个更经典但是不那么常见的例子：
> sudo pacman -Rc python
> Password: ********
（我初学Linux时电脑就是这么坏掉的）（大悲）

实际上当你被迫在 Windows 上开发时，本质上是在微软划定的游乐场里玩沙盒游戏——看似自由，实则每个操作都受限于 invisible wall（隐形墙）的约束。（其实 Mac 也一样，但是 Mac 比 Windows 舒服多了，这我认为应该是因为 Windows 做得太差而不是 Mac 做得太好导致的）

Windows 其实还有不少别的大小姐脾气，足见其不好用，尤其是开发上。那我们这些管理员的目的，当然就是把这位大小姐调教为能正常上岗的社畜；不求能像 Linux 一样完美契合工作，至少也得能用吧……

提权：获取真正的 Administrator 权限

警告

对于小白，一定不要随便开 Admin。常规使用下，普通管理员基本足够。

这和 Linux 老手也不会随便用 root 的原因完全一样：权限太高、自由度太高、安全度太低且几乎毫无容错。虽然 UAC 令人诟病，但是 Windows 系统有很多防呆设计确实都设计在这里。而 Admin 会凭借自身的超高权限，力大砖飞地绕过去，然后，大概率就造成 sudo rm -rf / 一样严重的错误了。

即使是 Linux，非 sudo 情况下上述命令也属于危险命令，不会让你执行。但是对于权限甚至高于系统的root，有没有sudo都一个样，那就很酸爽了。

我们知道，在 Linux 和 Mac 上，最高管理员是 root，他是真正的最高权限者，其所有权限默认为 sudo 的；对于其他管理员而言，只需要一句轻描淡写的 sudo，就可以获得 root 的力量。而 Windows 虽然也有 sudo，但是并不好用。

当然我自己都忘了全新的 Windows 上有没有 sudo 了，反正我电脑有，要是没有那就是我自己装的

我们在 Windows 使用常规手段创建用户的时候，可以看到普通用户和管理员两个选项。一般情况下，你在电脑店购入一台全新的 Windows 机器，所提供的初始账户就是这个普通管理员账户。

不过，在 Windows 的庄园中，普通管理员虽说也是管理员，大小姐的许多房间他依然无权进入：

• 普通管理员执行敏感操作时会触发 UAC（用户账户控制）弹窗，这种设计相当于大小姐要求管家每次触碰银餐具都必须当面请示；
• 试图修改 C:\Windows\System32 这类核心目录时，普通管理员会被大小姐的贴身护卫 Defender 提着后领子踹出去（错误 0x80070005）；
• 创建系统级自动化任务时，普通管理员只能设置早八自动播放起床铃声这种小事，这实在是微不足道了；
• 当需要修改 HKEY_LOCAL_MACHINE 这个象征最高权限的注册表分支时，普通管理员只能在外围的 HKEY_CURRENT_USER 花园散步，剩下的啥都改不了。

警告

HKLM 是 Windows 注册表的核心根键之一。对于会调注册表的人而言，该注册表可以调优系统启动项或者其他性能参数。

对于小白，我建议你永远不要动这个东西。如果一个教程说要修改HKLM项目，如可能，请试着寻找其他替代手段。

直接修改 HKLM 可能导致系统崩溃或软件故障，操作前务必备份注册表并创建系统还原点——无论你能不能事先确认该修改是否正确。

而真正的超级大管家 Administrator 却从不露面；我们要完成不少工作，都不得不请求他的首肯。对于以上问题，Administrator 静默提权、随意替换系统文件、随意修改系统时间同步规则，随便按需修改注册表……实在是太轻松啦！

既然如此，那么我们为什么不启用Administrator呢？那么就打开计算机管理面板：

开始 > 计算机管理 > 本地用户和组 > 用户

你会看到 Administrator 正静静地躺在那里。点开他，解除他的封印（把 “账户已禁用” 关掉）。

一个更简单的办法是命令行（必须以管理员身份运行！）

net user administrator /active:yes

然后切换用户到他身上即可，是不是感觉你的力量无穷无尽如同群星呢？

不过我依然要给你泼盆冷水：虽然这实际上是 Windows 中我们能够访问的最高权限账户，但是他的权限实际上依然比不上 Linux 中的 root 。即使开启 Administrator，修改 TrustedInstaller 保护的文件仍需进行 “管理员取得所有权”；涉及安全启动或 BitLocker 的操作，即使 Administrator 也要被大小姐踹飞。

环境变量：让大小姐认识路

Windows 大小姐的庄园错综复杂，连她本人都只能堪堪记住系统自带房间的路。而在庄园里开辟新的房间的时候（指安装新的软件），她几乎从不知道自己应该怎么去到那个房间。如果我们对她做出命令“Windows，移动”，她大概率无动于衷，并一口气给你爆一大堆红色警告。而这并不是因为她生性懒惰：她只是不知道罢了。那么，当务之急就变成了“让她知道怎么走”。

增加环境变量也有两个手段：视窗操作和命令行操作。

我们以 GCC 为例。在视窗环境下：

系统 > 高级系统设置 > 环境变量 > Path (系统变量)

然后把新的 Path 手动加进去，例如 C:\Program Files\mingw64\bin。然后一路确定即可。或者直接使用更简单的命令行（管理员权限！）

$env:Path += ";C:\Program Files\mingw64\bin"

这个分号一定要打半角分号，否则后果不堪设想！

然后开一个新的终端，输入 gcc，你发现终端终于识别出来这玩意了！！！

可喜可贺可喜可贺，不过一想到 Linux 直接 sudo pacman -S gcc 之后就解决一切问题以后，我突然笑不出来了。

使用 PowerShell 而不是 CMD

对于 Linux 用户而言，Terminal 是不可不用的一个东西，而它也是 Linux 小姐最喜欢的工作服。而 Win 小姐的默认终端是 cmd（命令提示符），这玩意极其难用。而 B 站竟然还有一堆低质量营销号教人怎么用 bat 脚本，思之令人发笑

都 2025 年了，这 CMD 还在遵从 1981 年的祖训：批量处理依赖批处理脚本这种活字印刷术，调试循环变量堪比在迷宫找出口，操作注册表要忍受 reg add 参数里反人类的斜杠森林……还沉浸在过往之中吗？这种又难看又难用的旧式终端早该被扔掉了好吧？！

好在微软已经看不下去了，亲自下场给 Win 小姐做了一套新的衣服：Windows PowerShell（不少地方简称 PowerShell，甚至直接使用 pwsh 或者更简洁的 PS 代替了）。

PowerShell的命令则人性化得多，不仅可以正常输入成行的命令，也可以进行交互式命令行操作。比方说你要给一大堆东西重命名，你在 CMD 要写 *.bat 去批处理，或者死记硬背 ren 要咋用。但是你在 PS 只需要把 ren 打进去，然后跟着下面的交互式命令行一步步走下去，岂不美哉？

这是CMD的ren：

C:\Users\Administrator>ren
The syntax of the command is incorrect.

---------------

这是PS的ren：

> ren

cmdlet Rename-Item at command pipeline position 1
Supply values for the following parameters:
Path: rename.txt
NewName: powershell_is_good.txt

PS 不仅是一个终端，它还是一门完备的语言。因此它能做到的事情比你想象的更多，且能对系统进行非常深度的控制。

然而，PS 的一个显著的缺陷是用惯 Linux 的人难以适应这玩意。对于简单操作而言，其命令的繁琐程度令人汗颜。同样是创建文件，Linux 简简单单 touch，PS 则得用 New-Item。

其实这倒也无可厚非，因为 PS 是基于 .NET 框架的，它的设计理念是“对象”而不是 Linux Shell 的“字符串”，命令行 C# 化不是不可理解。不过 git 等第三方命令倒是无所谓，这个在哪里都一样。

对于喜欢给 Win 小姐化妆的管理员们，我推荐一个比较好的终端美化工具：Oh My Posh，有兴趣的可以自己去了解。而且这玩意在 Linux 上也可以用。

winget：大小姐的自动化包管理

最终我们还是厌倦了手动下载安装软件包，其配环境等过程实在是依托答辩。我们想到，Linux 有著名的 apt、pacman、yay 等包管理器，Mac 也有 Homebrew。那么能否在 Windows 下使用同样的手段安装和管理包呢？

有的，兄弟，有的。下面请让我隆重介绍微软为大小姐钦定的包管理器 winget。

winget 是 Windows 10/11 内置的包管理工具，专司软件安装与更新。当然它也可以进行卸载操作，但是我们一般不使用它卸载软件。

安装：通过 winget install VSCode 可以安装 Visual Studio Code；

更新：通过 winget upgrade --all 可同时更新所有软件，避免逐个点击更新按钮的繁琐。

它非常适用于安装一些比较底层的包，例如 Node.js 等。不过这个 winget 有一个很巨大的问题：因为它是微软钦定的包管理器，所以自然极为依赖微软本身，导致它只能安装微软钦定的包！像 yay 一样从 GitHub 上面下载包然后给你直接 build 了那更是不可能的！（但是如果在 GitHub 上面有合适的 release 的话还是会给你拉下来的，例如 clash-verge-rev 和 oh-my-posh）

而更搞笑的事情在于，对于部分包而言，它甚至是直接把安装用的 exe 或者 msi 给你拉下来然后自动运行的（例子：我刚刚提到的两个软件）。于是我们发现这个除了批量安装开发工具链以外，实在是用处有限。

winget install Python Nodejs Git

这导致 PowerShell 和它的 Linux 亲戚相比，确实是没趣得多；但是它确实比从网上一个个地下载东西方便的多了！

警告

不建议使用 winget 更新 conda 系列软件，这可能会导致 winget 给你的 conda 卸了！

MSYS2：使用更好的终端

虽然我们确实是利用 PowerShell 解决了 Windows 的种种问题，但是我们也看到在执行许多操作的时候依然很别扭，如同穿着高跟鞋在工厂打螺丝。这并不十分适合我们这群开发者。而这时，一群程序员找到了 Linux 小姐的一套衣服，于是在他们的精巧裁缝之下，一件又新又好的衣服诞生了，它就是 MSYS2。

安装 MSYS2 可以前往其官网 msys2.org下载其安装程序。下载下来的同样是可执行文件，一路确定到底就行了（别忘记把这东西加入环境变量）。

然后你会发现多了一些可以用的终端（建议使用 MSYS2 UCRT64 这个终端；其他终端不知道什么时候就暴毙了，不建议使用）。这些终端有着不同环境，编译的软件往往存在不同的依赖行为。当然，我们往往也不太需要管那么多。

当你安装完成后，你就会惊奇地发现：

这难道不是和 Arch Linux 一模一样吗？

从形式上看这玩意确实是和 Arch Linux 一样的，自然也支持 Linux 的各种各样的命令，例如在 PowerShell 中使用ls、touch这类的语句，以及使用pacman进行包管理等。

MSYS2 这类终端有一个更加高大上的名称：预构建工具链，与之类似的还有 Cygwin 等。这些工具链在 Windows 下的一大亮点在于引入了 Unix 世界依赖管理的哲学，Windows 下复杂的开发依赖安装可以借助移植过来的包管理器轻松完成，例如 MSYS2 可以使用pacman快速且舒适地安装 GCC 等在 Windows 上难以安装的软件，非常方便。

需要注意的是，我们使用pacman安装的软件，其环境变量是在MSYS2的终端中；如果你需要在 Windows 的相关终端中使用这些终端，你需要将它们增加到Windows 系统的环境变量。部分 MSYS2 软件在 Windows 终端中可能行为异常，多版本 Python 等软件也有可能产生冲突，这都是正常现象；类似于chmod 777这种东西也大概率是摆设。

不是摆设的情况

在某些情况下，随便在 MSYS2 终端用 chmod 还可能带来麻烦，比如说 git 可能会遇到在 Windows 下发生意外的权限更改的情况。为了防止以上情况出现，建议 Windows 下使用以下命令：

git config --global core.fileMode false

关于 MSYS2 的更进一步使用，我们可以参考大佬 wszqkzqk 的blog星外之神的恩情还不完。

WSL：脚踏两条船？全对！

Windows 大小姐虽然娇蛮任性，但偶尔也会展现出惊人的包容力——比如她居然允许你在她的闺房里养一个 Linux 小情人！

没错，我说的正是 WSL，它可以允许 Linux 程序在 Windows 里原生运行。

WSL 的安装方式非常简单：

wsl --install

片刻之后，一个完整的 Ubuntu 终端便从她的系统内核里长了出来！这场景堪比大小姐的衣柜里突然钻出个穿 Tux 企鹅服的少女，而她居然只是挑了挑眉。

更离谱的是，这个 Linux 子系统不仅能和 Windows 共享文件系统（/mnt/c 直通 Windows 的 C 盘），还能用 apt 安装软件、用 gcc 编译代码、甚至运行 Docker——而这一切都不需要虚拟机那笨重的隔离层。

一个使用例是让两个系统互相查看对方文件目录：

# 在WSL里查看Windows的C盘文件
ls /mnt/c/Users/YourName/Documents

# 在PowerShell里查看Linux根目录
wsl ls /home

这种跨系统的文件操作流畅得令人发指，以至于开发者们纷纷把项目扔进 WSL 的 ~/workspace，然后在 VS Code 里用 Remote-WSL 插件远程开发——表面上是 Win 小姐在运行编辑器，实际干活的全是 Linux。

当然，这两个系统并非一直相安无事，毕竟是在 Windows 里挂载了 Linux 系统，因此很容易引发以下问题：

• 硬件占用：CUDA 程序在 WSL2 里跑得飞起，但游戏本用户常发现独显被 Linux 占了，用 Windows 打游戏时帧数暴跌；
• 网络端口占用：当 WSL 的 Apache 监听 80 端口时，IIS 会气得拒绝启动；
• 文件权限错乱：用 Windows 编辑器修改 WSL 的文件可能导致权限错乱，Linux 会报 Permission denied。

不过这些问题都有解法，比如用 wsl --shutdown 强制重启 Linux，或者配置 %USERPROFILE%\.wslconfig 限制其资源占用。

这和我们常说的双系统并不一样。目前常用的双系统中，虽然两者实际是平等的，但是操作中往往是 Linux 装 grub 带 Windows，不能同时启动，也难以相互管理。而 WSL 的全称 Windows Subsystem for Linux 则道明了一切：大小姐允许你在她那里使用 Linux 的前提是，她必须占决定性的主导地位！

减肥：解放 C 盘

对于 Win 小姐而言，C 盘一直是最重要的磁盘或磁盘分区。然而，大小姐似乎对 C 盘有着近乎偏执的占有欲——如果不加监管，她就会把各种乱七八糟的东西都往里面塞，直到 C 盘亮起刺眼的红色警告，然后导致系统运行变缓慢，某些占用较大的软件甚至无法运行。这时，我们就不得不帮这位大小姐清理她的"闺房"。

C 盘里面有什么可以转移或者删除的内容？

不加约束的情况下，Windows 的 C 盘很像我们家里的衣帽间或者乡下的小仓库，什么都往里扔。最终，往往就会堆积一大堆的文件，这些文件我们疑似很久很久都用不上，那么不如清理或者转移了为好。以下是一些很常见的大文件：

• 系统更新残留堆积在C:\Windows\SoftwareDistribution\Download
• 休眠文件hiberfil.sys
• 虚拟内存pagefile.sys
• 临时文件散落在%Temp%（受环境变量影响）
• WinSxS 组件库C:\Windows\WinSxS（其实并不大，但是这玩意会随着时间逐渐膨胀到惊人的体积）
• 桌面、回收站（这个应该不用我多说了）
• conda 虚拟环境和缓存（你不要笑，对于不会调教 conda 的人而言，这玩意能占几十 GB）

实际上以上文件的大多数内容确实就是鸡肋，如果 C 盘空间足够，我们确实没啥清理的必要；另一个方法就是给 C 盘单独拉出一个巨大的空间（笔者的 C 盘完全是一个没特别分区的容量 1TB 的固态硬盘，这是因为对 SSD 而言磁盘分区的意义非常有限），这样可以一劳永逸地解决问题。然而，对于不愿意动磁盘分区什么不愿意动，积重难返罢了的读者而言，我们不得不进行定期大扫除。

磁盘扫除参考方案

警告

以下内容经常涉及到管理员权限。你可能需要启用账户 Administrator，或者属于 Admininstrators 组的其他账户。如果你不愿意用这些账户，右键“以管理员权限运行”或者按住 Ctrl+Shift 运行，也会弹出窗口确认提权。

危险操作

以下操作可能影响系统稳定性：

• 直接删除System32或WinSxS中的文件
• 随意修改注册表中不明键值
• 关闭所有虚拟内存（可能导致系统崩溃）

和常规减肥一样，系统清理也要缓慢、分批、循序渐进，突然的极端"节食"可能导致大小姐"晕厥"（系统崩溃）。建议每次大操作前先创建系统还原点：

Checkpoint-Computer -Description "Before Disk Cleanup" -RestorePointType "MODIFY_SETTINGS"

磁盘清理工具

对于新手，我们可以使用系统自带的、最温和的清理工具，适合新手：

开始 > 磁盘清理 > 选择 C 盘 > 勾选"临时文件"、"系统错误内存转储"等选项

除此之外，点击"清理系统文件"按钮，还能处理 Windows 更新遗留的安装文件等。

如果对于需求较高或者较为有钱的用户，可以使用 CCleaner 这个饱受赞誉的清理工具（当然本人使用的是免费版）。由于众所周知的原因，我们不建议使用 360 或者电脑管家这种软件（对于不会调教这种东西的人而言，它们跟下崽器无异）。

禁用休眠功能

Windows 系统实现休眠功能的方法可以通俗地理解为：在关机时将物理内存里的内容移到外存上，这样再次开机的时候就可以把这些东西移回物理内存，这样就可以快速恢复工作现场。如果我们并不需要这一功能，可以在 PowerShell 关闭之：

powercfg -h off

这个命令会关闭休眠功能，并删除hiberfil.sys文件，通常能释放相当于内存大小 75%的空间。

转移虚拟内存

对于多硬盘用户，可以把虚拟内存搬到其他分区（一般是搬到读写性能最好的盘中）：

系统 > 高级系统设置 > 性能设置 > 高级 > 虚拟内存更改

虽然通过以上手段我们可以更改虚拟内存，但是不建议贸然降低这玩意的大小。

检视 WinSxS 组件库

这个"备胎仓库"看似庞大，实则很多是硬链接。这边建议使用官方工具检视和清理：

# 检视大小
Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

# 清理
Dism.exe /Online /Cleanup-Image /StartComponentCleanup

软链接大法

对于某些顽固的软件（比如微信默认把聊天记录放在 C 盘），可以用 mklink 施展"空间魔法"：

# 1. 先把原文件夹移动到其他分区
mv "C:\Users\YourName\Documents\WeChat Files" "D:\"
# 2. 创建符号链接
mklink /J "C:\Users\YourName\Documents\WeChat Files" "D:\WeChat Files"

当然另一个办法就是直接修改微信的相关设置，这也非常舒适。不过修改设置要趁早，积重难返就不好办了。

预防性调理措施

修改默认安装路径

在注册表中修改 ProgramFilesDir 值，让新软件安装到其他分区（这是一个比较懒惰的方式，如果不愿意动注册表，我们也可以在安装软件的时候手动指定安装到其他分区）：

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion" -Name "ProgramFilesDir" -Value "D:\Program Files"

看到 HKLM，请问读者：我在提权那一节说过什么？如果忘了，罚你重读。

维持良好的存储习惯

有不少人喜欢把东西堆满桌面或者回收站，这两个东西在默认情况下都是挂在 C 盘的，东西装多了就会导致 C 盘爆满。我们应当维持良好的存储习惯，尽可能不要把大文件放在桌面，并定期清理回收站。

除了这样，我们还可以把桌面挂到 D 盘：

文件资源管理器 > 桌面 > 属性 > 位置

conda 专清

conda 是目前最流行的 Python 虚拟环境管理器，其文件默认是存在~/.conda/envs，占地极大。我们可以通过一些手段把这个东西移动到别处。

然而，值得注意的是，conda 极为娇贵，随便移动以上内容会导致 conda 崩溃。因此，我们需要手动修改配置文件。

# 如果你未能找到~/.condarc，执行下面这一行命令
conda config --set show_channel_urls yes

使用你喜欢的编辑器打开~/.condarc，然后加入以下内容：

envs_dirs:
  - D:\conda_envs
pkgs_dirs:
  - D:\conda_pkgs

这相当于给 conda 下了两道命令：以后所有新环境必须住进 D:\conda_envs 这个集体宿舍；下载的包缓存统统扔到 D:\conda_pkgs 仓库。

然而，修改路径后新建的环境会遵循新规则，但已存在的环境不会自动迁移。如果已有环境需要搬家，可以克隆环境到新位置，再删掉旧环境：

conda create --prefix D:\conda_envs\new_env --clone old_env
conda remove --name old_env --all

除此以外，还可以使用以下命令定期清理缓存：

# 清理无用的包缓存
conda clean --all -y

# 查看各环境占用空间
conda env list --verbose

当然，防患于未然的方式也有，例如我们在安装的时候就指定包位置等。

遇到部分比较呆的 IDE 强烈要求搜索 conda 默认安装位置的时候，我们也可以使用软链接大法：

# 1. 原文件夹到新位置
mv C:\Users\YourName\.conda D:\conda_storage
# 2. 符号链接
mklink /J C:\Users\YourName\.conda D:\conda_storage

冷知识

Miniconda 比 Anaconda 更轻量，适合不需要预装数百个科学计算包的用户。就像准备行李，与其带整个衣帽间，不如只带几套换洗衣物。

经过这番调理，相信你的 Win 小姐又能轻装上阵了。不过要记住——就像真正的减肥一样，系统瘦身也是个需要长期坚持的好习惯！

其他

咕咕咕，后面有再加，欢迎去LCPU Getting Started提 Issue！

目前计划：不知道

结语

结语我竟然不知道写些什么，令人感叹。

或许 Windows 就是这么令人又爱又恨：不要看 Windows 有这么多缺陷，但是你要是作为一个新手玩 Linux 那更有你受的了，把系统搞坏几次是 Linux 新手的常态。而对于一些非常简单的工作而言，用 Linux 更是有杀鸡焉用牛刀之嫌疑，此时 Windows 则成为一种良好的替代。

当然，最好的使用方式当然是“都强都带”，因地制宜地使用对应的系统才是王道。