VS Code 导览与配置¶
VS Code 不是只有“装上就能用”的编辑器，它更像一个可以陪你走很久的工作台。你不需要一开始把它折腾得很花，但至少应该把它调到顺手、稳定、能支撑你日常学习与写作。
这页适合这样的人：
- 已经在用 VS Code，但界面、文件、终端总让自己有点乱
- 刚接触开发或文档写作，想先建立一个稳定入口
- 容易把编辑器越装越重，最后反而更卡、更乱
如果你连电脑和文件系统都还不太熟，建议先看 电脑认知；如果你之后想补插件选择，再去看 插件推荐。
这页主要解决什么问题¶
很多人初次接触 VS Code 时，会把重点放在“别人装了什么插件”或者“界面怎么更酷”。但对大多数大学场景来说，真正先要解决的是三个问题：
- 你能不能快速打开、定位和管理自己的项目或资料
- 你能不能在一个环境里稳定完成编辑、搜索、终端操作
- 你有没有把编辑器调到足够顺手，而不是每次都被小摩擦打断
所以，VS Code 的入门重点不是炫技，而是让它成为一个低摩擦的工作环境。只要这件事做好，它既能服务写代码，也能服务写 Markdown、整理文本和处理轻量项目。
1. 先把工作区用明白，而不是到处双击单文件¶
VS Code 最值得建立的习惯之一，是尽量以“文件夹 / 项目”为单位打开内容，而不是零散地双击单个文件。
因为一旦你只打开一个文件，很多能力就很难形成：侧边栏结构看不清、全局搜索不好用、相对路径容易混乱、终端默认位置也不稳定。长期来看，这会让你一直停留在“临时改点东西”的使用方式里。
更推荐的做法是：
- 给每门课、每个项目、每段文档整理一个清晰的文件夹
- 用 “Open Folder” 打开整个目录
- 在侧边栏中管理文件，而不是反复去系统文件管理器里找
这样你会很快习惯一种更清楚的工作方式：文件在哪、相关内容有哪些、自己现在正在改什么，一眼都能看出来。对于经常写 Markdown、管理课程材料或做小项目的人，这比任何花哨配置都更值。
2. 优先配好最常用的三块：搜索、终端、自动保存¶
如果只选三件最值得先调顺的功能，我会建议是：全局搜索、内置终端、自动保存。
全局搜索¶
很多初学者遇到内容找不到、配置不知道在哪儿改，就会回到系统里一个文件一个文件翻。其实 VS Code 的搜索面板非常适合日常定位：
- 找某个关键词出现在哪里
- 找一段配置是在哪个文件里定义的
- 快速理解一个项目中相同内容的分布
只要你开始用工作区方式打开内容，全局搜索就会变得非常顺手。
内置终端¶
内置终端的意义，不只是少开一个窗口，而是把“编辑”和“执行”放在一个上下文里。你在改 Markdown、跑命令、看目录结构时，不需要不断切换环境，心智负担会小很多。
在这个仓库里，本地预览和校验本来就依赖命令，比如 uv run mkdocs serve、uv run mkdocs build --clean --strict --verbose。如果你习惯在 VS Code 里直接打开终端，很多操作会更连贯。
自动保存¶
这不是高阶功能，却很实用。对刚开始建立工作流的人来说，自动保存可以明显减少“忘记保存、结果没生效”的低级摩擦。你不需要因为每次小改动都担心自己是不是漏按了保存键。
3. 克制地配置，而不是把编辑器越装越重¶
VS Code 最大的诱惑，就是“好像什么都能装一点”。但对初学者来说，过早追求复杂主题、海量插件和各种高级配置，往往只会把环境变得更乱。
一个更稳的原则是：先把默认能力用到七成，再按真实痛点补配置。
比如：
- 如果你经常写 Markdown，再考虑补和 Markdown 直接相关的能力
- 如果你常常管理 Git 仓库，再针对版本控制补工具
- 如果你发现某类文件总是格式混乱，再加对应的格式化支持
而不是一上来安装十几个“别人说很好用”的插件。插件一多，不仅会拖慢启动、制造冲突，还会让你很难判断到底哪部分功能来自哪里。对多数学生来说，稳定和清楚，比“功能堆满”更重要。
立即可做：把 VS Code 调成可长期使用的基础状态¶
你现在就可以做这 4 步：
- 用文件夹而不是单文件方式打开你常用的一份资料或项目。
- 试一次全局搜索，找到一个关键词在整个目录中的位置。
- 打开内置终端，在当前目录执行一次你常用的命令。
- 打开自动保存，让基础编辑摩擦先降下来。
做完这几步，VS Code 就已经从“偶尔打开的编辑器”变成“可以稳定工作的环境”。
常见误区、边界与下一步¶
常见误区¶
- 误区一：先装很多插件才算会用。 真正重要的是先把工作区、搜索和终端用顺。
- 误区二：界面越花越专业。 对长期使用来说，清楚、稳定、低干扰更重要。
- 误区三：只把 VS Code 当代码编辑器。 它同样很适合 Markdown、文档、配置与轻量项目管理。
不适用范围¶
这页是 VS Code 的可发布 MVP 导览，不会覆盖调试器、远程开发、复杂语言配置或团队级工程实践。等你真的遇到对应场景，再按需补即可。