在实际开发中，决定效率的往往不是某个框架，而是每天打开时间最长的编辑器。Popular editing 并不是某一个特定软件的名字，而是指那些使用者多、社区活跃、教程丰富、插件生态完整、能够长期沉淀为个人工作流的编辑方案集合。很多新手容易陷入两个极端：要么只会在编辑器里打开文件，快捷键和扩展几乎不碰；要么一开始就安装大量插件，导致配置混乱、启动卡顿，最后反而影响效率。
这篇文章会从编辑器选型开始，以 VS Code 为主线搭建一套可复现的编辑环境，覆盖配置、快捷键、代码片段、调试、Git 集成和常见问题排查，最后给出团队协作和生产环境下的建议。无论你是 Web 前端、Python 脚本开发，还是刚接触命令行编辑器的运维同学，都可以按自己的场景裁剪这套方案。
1. 先看清主流编辑方案的定位，再决定投入时间
1.1 判断一个编辑器是否值得投入，先看三个维度
学习编辑器最忌讳的是“盲目追热门”。某个编辑器讨论度高，不一定适合你的日常工作。判断一个编辑方案是否值得长期投入，可以从三个维度看：
第一是使用频率。如果这个编辑器只用来改一两行配置，不值得花大量时间研究；如果是每天写代码的主战场，就值得认真打磨配置、快捷键和扩展选型。
第二是扩展生态。编辑器自身解决的问题有限，真正决定能力上限的是第三方扩展。以 VS Code 为例，内置功能只包含基本的代码编辑、调试、Git 面板和终端，而语言支持、代码规范、主题、远程开发等能力都来自扩展。扩展生态越完整，越不容易被单一语言或场景限制。
第三是可迁移性。你学到的快捷键、配置文件、编辑习惯，能不能迁移到其他环境。比如 VS Code 的命令面板和 Emmet 快捷键，在部分 Web IDE 中也类似；Vim 和 Neovim 的键盘操作逻辑，在任何 Linux 服务器上都能复用。可迁移性越高，学习成本摊得越薄。
1.2 当前常用的几类热门编辑方案差异
不同编辑方案解决的是不同问题。这里列出一组常见选择，方便定位自己适合哪种。
| 方案 | 类别 | 主要优势 | 主要成本 | 适合场景 |
|---|---|---|---|---|
| VS Code | 轻量编辑器 + 扩展生态 | 启动快、跨平台、扩展全、内置终端和调试 | 大型项目需要按工作区调优 | 前端、Python、Go 等大多数日常开发 |
| JetBrains 系列 IDE | 完整 IDE | 开箱即用、重构能力强、项目感知准确 | 内存占用高、启动比轻量编辑器慢 | Java、Kotlin、PHP 等重型框架开发 |
| Neovim | 终端编辑器 | 启动极快、可用 Lua 脚本定制、资源占用低 | 学习曲线陡、配置需要投入时间 | 远程终端环境、习惯了键盘流的开发者 |
| Sublime Text | 轻量编辑器 | 性能好、大文件打开流畅、界面简洁 | 高级功能依赖插件，部分授权策略需关注 | 快速改文本、查看超大日志文件 |
这四种方案不是互相排斥的关系。实际工作中常见的情况是：本地开发用 VS Code，远程排查问题用命令行下的 Vim 或 Neovim，遇到大型 Java 项目再用 IDEA。编辑器是工具组合，不是站队题。
1.3 给不同开发者的选型建议
如果目标是“花最少的时间获得完整的编码体验”，推荐以 VS Code 为第一选择。它的官方市场扩展数量大，遇到问题很容易搜到解决方案，而且快捷键默认值对从其他 IDE 转过来的用户相对友好。
如果日常主力语言是 Java 或 Kotlin，并且经常写 Spring 这类框架，IDEA 的智能提示和重构能力确实比 VS Code 加 Java 扩展更省心。这种情况下不需要为了“统一”而强行使用 VS Code。
如果经常需要 SSH 到服务器修改配置、排查日志，至少要掌握 Vim 或 Neovim 的基础模式切换和编辑命令。这和“常用编辑器”不冲突，是运维和开发必备的兜底能力。
2. 用 VS Code 搭建一套统一、可迁移的编辑环境
2.1 安装时选择稳定版，不同平台使用对应安装命令
VS Code 有 Stable（稳定版）和 Insiders（内测版）两条更新通道。日常开发使用稳定版即可，Insiders 主要用于提前体验新功能，可能引入不稳定行为，不建议在主工作环境安装。
常见安装方式如下。
Ubuntu / Debian 系列可以使用官方源：
sudo apt update sudo apt install codemacOS 使用 Homebrew Cask：
brew install --cask visual-studio-codeWindows 可以使用 winget：
winget install Microsoft.VisualStudioCode安装完成后，打开命令面板可以验证基础环境是否正常。在编辑器中按下Ctrl+Shift+P（macOS 为Cmd+Shift+P），输入About，能正常弹出版本信息说明安装成功。
2.2 用 settings.json 管理配置，而不是每次都点界面
VS Code 的设置最终都落到 JSON 文件里。相比在设置界面逐个搜索，直接维护 JSON 有三个好处：可以注释配置意图、便于复制迁移、可以纳入版本管理。
从命令面板执行Preferences: Open User Settings (JSON)可以打开用户级配置文件。下面是一份适合日常开发的基础配置。
{ "editor.fontSize": 14, "editor.fontFamily": "JetBrains Mono, Consolas, 'Courier New', monospace", "editor.tabSize": 2, "editor.renderWhitespace": "boundary", "editor.minimap.enabled": false, "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.eslint": true }, "files.autoSave": "afterDelay", "files.trimTrailingWhitespace": true, "files.insertFinalNewline": true, "workbench.colorTheme": "One Dark Pro", "workbench.iconTheme": "material-icon-theme", "terminal.integrated.defaultProfile.windows": "Git Bash", "git.confirmSync": false }这份配置解决了几类日常问题：
editor.fontFamily定义了等宽字体优先级，JetBrains Mono 缺失时回退到 Consolas，再退到系统等宽字体。editor.formatOnSave让保存动作自动完成格式化，避免每次手动记忆快捷键。files.trimTrailingWhitespace和files.insertFinalNewline会自动清理行尾空格和补文件末尾换行，减少 Git diff 中的无意义变更。workbench.iconTheme依赖 Material Icon Theme 扩展，如果没有安装，该配置会被忽略。
注意：
settings.json中如果写入了未知键或未安装的主题名称，VS Code 大概率不会报错，只会忽略或者画黄色波浪线。收到别人配置时，先确认对应扩展是否已安装。
2.3 字体、缩进和保存格式化的常见配置解释
字体设置要区分“编辑器字体”和“终端字体”。编辑器字体作用于代码区域，终端字体作用于集成终端里的命令行输出。两套字体建议保持一致，否则切换终端时会觉得字符宽度不一致。
缩进设置最容易被团队环境覆盖。如果项目根目录存在.editorconfig，该文件会优先于用户配置。推荐团队项目在.editorconfig中固定缩进风格：
root = true [*] charset = utf-8 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true indent_style = space indent_size = 2这里的indent_size要与项目预期一致。前端项目普遍使用 2 空格，Python 项目按 PEP 8 使用 4 空格。如果同一台机器同时维护两类项目，不要只靠用户配置，要依靠.editorconfig或工作区配置区分。
2.4 用户级配置、工作区配置和团队配置的边界
用户级配置是个人习惯，比如字体大小和主题；工作区配置是项目级规则，比如格式化工具和语言服务参数；团队配置应该放在项目仓库的.vscode目录中，随代码一起提交。
打开项目根目录的.vscode/settings.json，可以添加只对当前项目生效的设置：
{ "editor.tabSize": 4, "python.linting.enabled": true, "python.defaultInterpreterPath": "./.venv/bin/python" }这条配置对个人其他项目没有影响。一个典型的边界原则是：凡是会影响代码产物、格式化结果、语言服务规则的内容，都应该放在工作区或团队配置中；凡是纯粹的个人视觉偏好，留在用户配置中。
3. 高频编辑能力：快捷键、多光标、代码片段
3.1 先掌握一组高频快捷键，而不是背完整手册
VS Code 快捷键非常多，实际高频使用的只有十几个。先记下面这组，足以覆盖大多数场景。
| 操作 | 默认快捷键 | 使用场景 |
|---|---|---|
| 命令面板 | Ctrl+Shift+P | 快速执行任意命令 |
| 快速打开文件 | Ctrl+P | 输入文件名直接跳转 |
| 多光标添加 | Alt+Click | 同时在多个位置编辑 |
| 选中下一个相同词 | Ctrl+D | 批量修改同名变量 |
| 当前行向下复制 | Shift+Alt+Down | 快速复制一行或多行 |
| 移动当前行 | Alt+Down | 调整代码位置 |
| 格式化文档 | Shift+Alt+F | 对整个文件格式化 |
| 重命名符号 | F2 | 同步修改所有引用 |
| 跳转定义 | F12 | 查看函数和变量定义 |
| 查找所有引用 | Shift+F12 | 查看方法被谁调用 |
| 全局搜索 | Ctrl+Shift+F | 搜索整个项目内容 |
| 切换集成终端 | `Ctrl+`` | 打开或聚焦终端 |
不要试图一次性记住所有快捷键。建议先强制自己使用命令面板，命令面板会显示每个命令对应的快捷键，使用过程中会逐步形成条件反射。
3.2 用多光标完成批量修改
多光标是日常编辑中提升效率最明显的功能。例如有一段重复赋值代码：
const a = 1; const b = 2; const c = 3;想把每个变量名改成带后缀的形式，可以先将光标放到第一个a前面，按两次Ctrl+D依次选中b和c，然后直接输入新内容。所有选中的位置会同时修改。对于分散在不同行的相同文本，Ctrl+D比手动一个一个改更可靠。
更精细的做法是使用Alt+Click在指定位置手工添加光标。如果同一行需要修改多处，也可以按Shift+Alt+下方向键在当前列下方批量增加光标。
3.3 自定义代码片段，把重复模板固化成命令
日常开发里的重复代码可以用 snippet 简化。命令面板执行Preferences: Configure User Snippets，选择语言后写入 JSON 文件。
下面是一份包含 JavaScript 和 TypeScript 场景的示例片段：
{ "Log to console": { "scope": "javascript,typescript", "prefix": "log", "body": [ "console.log('$1', $1);", "$2" ], "description": "把变量输出到控制台" }, "React Function Component": { "scope": "javascript,typescript,jsx,tsx", "prefix": "rfc", "body": [ "import React from 'react';", "", "export default function ${1:ComponentName}() {", " return <div>$0</div>;", "}" ], "description": "创建 React 函数组件" } }$1、$2是 Tab 跳转位，$0是最终光标位置，${1:ComponentName}表示默认文本。使用 snippet 时，先输入prefix，再按Tab展开。
3.4 命令面板是 VS Code 的核心入口
命令面板不只是搜索命令，它还可以快速执行扩展功能、打开设置、切换主题、安装扩展。很多时候不需要记菜单路径，只需要按Ctrl+Shift+P再输入关键词。
例如输入Format Document、Toggle Terminal、Preferences: Open Keyboard Shortcuts，都能直接跳到对应功能。这个入口值得优先养成习惯，因为在不同操作系统上菜单位置不同，而命令面板行为一致。
4. 把重复工作交给编辑器：格式化、Git、任务和调试
4.1 保存时自动格式化和代码检查
只配置editor.formatOnSave还不够，还需要明确指定格式化工具。项目里如果同时安装了 ESLint、Prettier 等多个格式化相关扩展，VS Code 可能会弹窗询问使用哪一个，或者什么都不做。
推荐做法是在工作区配置中显式指定默认格式化器：
{ "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.eslint": true } }esbenp.prettier-vscode是 Prettier 扩展的 ID。source.fixAll.eslint表示保存时自动执行 ESLint 的自动修复能力。两者配合后，保存文件会先跑代码风格修复，再进行格式化。
这里要注意：Prettier 负责代码风格，ESLint 负责代码规则检查。两者职责不同，不能互相替代。团队项目中，如果格式化后 Git diff 仍然混乱，通常是双方规则不一致，需要在.prettierrc和 ESLint 配置里统一。
4.2 Git 集成与冲突处理
VS Code 自带源码管理面板，左侧菜单中的“源代码管理”图标可以看到当前变更文件、暂存和提交入口。日常提交流程可以完全在编辑器内完成，但建议同时保留命令行能力。
合并冲突时，编辑器会高亮冲突区域，并提供“接受当前更改”“接受传入的更改”“接受两者更改”等操作。如果冲突较多，建议回到命令行处理：
git mergetool或者直接查看冲突标记：
grep -n '<<<<<<<' src/example.js处理完冲突后，需要重新执行git add，否则后续提交仍然会提示未解决冲突。
GitLens 扩展可以增强 Git 体验，比如在代码行尾显示最近一次提交信息、查看文件的提交历史、比较不同分支差异。注意 GitLens 的免费版和付费功能边界在不同时期有调整，安装前先到扩展详情页确认当前版本的能力范围。
4.3 用 Tasks 串联脚本命令
VS Code 的 Task 可以将重复命令内置到项目中。在项目根目录的.vscode/tasks.json中定义任务后，可以通过命令面板执行。
{ "version": "2.0.0", "tasks": [ { "label": "eslint: fix", "type": "npm", "script": "lint:fix", "problemMatcher": ["$eslint-stylish"], "presentation": { "reveal": "always", "panel": "shared" } } ] }label是任务在命令面板中显示的名字，script对应当前项目package.json中的脚本名，problemMatcher把命令输出解析成编辑器中的问题列表，便于直接点击跳转到报错位置。
npm run lint:fix任务适合放在项目内，而不是用户全局配置中。新人克隆仓库后，打开命令面板输入Tasks: Run Task，就能看到同样的任务，不需要额外知道项目的构建命令。
4.4 用 launch.json 配置调试
调试器是编辑器从“文本编辑工具”变成“开发环境”的关键能力。以 Node.js 项目为例，在.vscode/launch.json中创建调试配置：
{ "version": "0.2.0", "configurations": [ { "type": "node", "request": "launch", "name": "启动当前文件", "program": "${file}", "console": "integratedTerminal", "skipFiles": ["<node_internals>/**"] } ] }program使用${file}变量，表示调试当前打开的文件；skipFiles跳过 Node.js 内部模块，避免单步调试时进入框架源码。
Python 项目的调试配置使用 debugpy：
{ "version": "0.2.0", "configurations": [ { "name": "Python Debugger: Current File", "type": "debugpy", "request": "launch", "program": "${file}", "console": "integratedTerminal" } ] }调试配置的核心是设置断点、启动程序、查看变量栈和调用栈。如果断点没有生效，通常需要检查当前打开的入口文件是否与program配置一致，以及语言扩展是否正常启动。
5. 按语言扩展：以前端和 Python 为例
5.1 Web 前端常用扩展
前端项目的核心需求是语法识别、代码格式化、路径提示和调试。下面是一组常用的扩展和用途。
| 扩展 ID | 用途 |
|---|---|
dbaeumer.vscode-eslint | ESLint 规则检查和保存时自动修复 |
esbenp.prettier-vscode | Prettier 代码格式化 |
formulahendry.auto-rename-tag | 同步修改 HTML/JSX 成对标签 |
christian-kohler.path-intellisense | 文件路径自动补全 |
streetsidesoftware.code-spell-checker | 英文拼写检查，减少命名错误 |
ritwickdey.liveserver | 静态页面开发时快速启动本地服务器 |
rangav.vscode-thunder-client | 在编辑器内调试 HTTP 接口 |
安装扩展不是越多越好。以 ESLint 为例，要先在项目中安装对应的 npm 依赖，编辑器扩展才会读取项目配置。如果项目还没有 ESLint 配置文件，即使装了扩展，也不会有任何提示。
5.2 Python 常用扩展
Python 开发建议安装官方 Python 扩展、Pylance、Python Debugger 和 Ruff。
| 扩展 ID | 用途 |
|---|---|
ms-python.python | Python 语言基础支持，解释器管理 |
ms-python.vscode-pylance | 类型检查、智能提示 |
ms-python.debugpy | Python 调试支持 |
charliermarsh.ruff | Ruff 代码规范和快速修复 |
这里特别推荐 Ruff。Ruff 的检查速度比传统工具快，而且很多格式化规则可以直接修复。配合保存时自动执行：
{ "[python]": { "editor.defaultFormatter": "charliermarsh.ruff", "editor.formatOnSave": true } }需要注意 Python 解释器路径。命令面板执行Python: Select Interpreter，尽量选择项目虚拟环境中的 Python，而不是全局环境。如果选择了系统 Python，安装的依赖包和项目依赖不一致，编辑器会频繁报导入错误。
5.3 扩展使用守则
安装扩展之前，先在扩展详情页看三个信息：扩展 ID、最近更新时间、是否被 VSCode 官方市场验证。长期不更新的扩展容易在编辑器升级后失效。
建议遵守两个原则：
第一，遇到明确需求再安装扩展。不要在刚开始配置环境时一次性装几十个插件，后续维护成本很高。
第二，定期查看运行中的扩展。命令面板执行Developer: Show Running Extensions，可以看到每个扩展占用的 CPU 和内存。长时间不用的扩展直接卸载，而不是只禁用。
6. 常见问题排查：从现象到解决
6.1 配置修改后不生效
有时修改了用户设置，但编辑器没有反应。最常见的场景是“改了字体大小，界面毫无变化”。
可能原因包括：修改到了默认设置而不是用户设置；工作区设置覆盖了用户设置；配置文件中的键名拼写错误。
检查方式：
# 打开设置面板 Preferences: Open Settings (UI)在设置界面搜索对应配置，如果看到“工作区”标签下有不同的值，说明是工作区覆盖了用户配置。此时需要判断是个人习惯被覆盖，还是项目规范要求如此。
处理建议：个人显示类偏好放到用户设置，项目规则类配置放到工作区设置。如果不想让某个项目设置影响自己，可以在用户设置中使用ignoredSettings忽略指定项。
6.2 保存时格式化不工作
editor.formatOnSave已经打开，但保存文件后代码没有变化。
常见原因有三个：
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| 保存后没有格式化 | 没有安装 formatter 扩展 | 右键选择“格式化文档”，看是否有可选工具 | 安装 Prettier 或语言对应的 formatter |
| 弹窗提示有多个 formatter | 安装了多个格式化扩展 | 打开任意代码文件，右键“格式化文档方式” | 在 settings.json 中配置editor.defaultFormatter |
| 格式化结果和预期不一致 | 项目缺少.prettierrc | 查看项目根目录配置文件 | 统一 prettier 配置后重新格式化 |
格式化问题要按“工具是否存在、默认格式化器是否指定、项目配置是否一致”的顺序排查。
6.3 快捷键冲突或失效
安装了扩展之后，经常出现快捷键被占用的情况。比如某些扩展会占用Ctrl+Alt+Down，导致编辑器原本的复制行功能失效。
检查方式：命令面板执行Preferences: Open Keyboard Shortcuts，在上方搜索框输入失效的功能名，例如Copy Line Down。如果列表中有多个命令绑定了同一个按键，说明发生冲突。
处理建议：找到不需要保留的扩展快捷键，右键选择“Remove Keybinding”。不要直接删除编辑器的核心快捷键，优先调整扩展快捷键。
6.4 编辑器启动慢或卡顿
启动慢通常不是因为编辑器本身，而是扩展加载过多。卡顿多发生在打开大文件、搜索整个项目目录或某个扩展内存泄漏时。
检查方式：
# 查看运行中扩展的资源占用 Developer: Show Running Extensions # 查看大文件是否被识别为纯文本 Ctrl+Shift+P处理建议：
- 禁止不常用的扩展在启动时自动加载。
- 大文件场景关闭
editor.minimap.enabled，并设置"files.exclude"排除node_modules和构建产物目录。 - 搜索时设置
search.exclude，避免搜索范围扫过依赖包和打包目录。
{ "search.exclude": { "**/node_modules": true, "**/dist": true, "**/.git": true }, "files.exclude": { "**/.git": true, "**/node_modules": false } }search.exclude只是让搜索跳过这些目录，不会删除文件，也不会影响编译工具读取依赖。
6.5 团队中格式化结果不一致
项目成员各自安装了不同的格式化扩展，或者用了不同的版本，导致格式化结果不一致。这个问题的本质是“编辑配置没有被固定下来”。
解决方式是把格式化配置纳入项目仓库：
// .vscode/extensions.json { "recommendations": [ "dbaeumer.vscode-eslint", "esbenp.prettier-vscode" ], "unwantedRecommendations": [] }同时把.prettierrc和.editorconfig提交到仓库。这样成员打开项目时，VS Code 会提示安装推荐扩展，配置也能随代码一起统一。
注意：不要只依赖编辑器扩展保证代码风格。生产项目中还需要在 CI 阶段加入格式检查和 lint 检查，否则仍然可能有人绕过编辑器提交未格式化代码。
7. 学习环境与生产环境下的编辑规范
7.1 个人学习环境怎么快速跑通
个人学习环境的目标是“能写、能跑、能调试”，不需要一开始就追求完美配置。
新建一个测试项目时，只需要做三件事：选择解释器或运行时、安装语言对应扩展、打开终端运行命令。
Python 示例：
python -m venv .venv source .venv/bin/activate pip install flask code .Node 示例：
npm init -y npm install express code .7.2 团队项目把编辑配置纳入版本管理
团队项目建议把.vscode/settings.json和.vscode/extensions.json提交到仓库，但不要把所有个人偏好都放进去。发布到仓库的配置只应该包含与项目规范相关的内容，比如默认格式化器、代码检查规则、调试配置、推荐扩展和统一缩进。
示例.vscode/settings.json：
{ "editor.formatOnSave": true, "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.codeActionsOnSave": { "source.fixAll.eslint": true }, "typescript.tsdk": "node_modules/typescript/lib" }这个文件不包含字体大小、主题颜色、是否显示迷你地图等内容，因为这些属于个人偏好，不应由仓库统一强制。
7.3 远程开发与容器开发
当开发环境位于远程服务器、容器或 WSL 中时，VS Code 的 Remote 扩展可以让本地编辑器和远端文件系统打通。安装 Remote-SSH、Dev Containers 或 WSL 扩展后，左下角会出现远程连接入口。
远程开发的配置要区分两端：本地的用户配置主要控制编辑器外观，远端的工作区配置控制项目规则。需要注意，部分扩展在远程环境下可能不工作，因为扩展需要运行在代码所在的那一端。
容器开发时，Dev Containers 扩展会根据.devcontainer/devcontainer.json创建可复现的环境。这是一个典型的“生产一致性”解决方案，比每个人手动安装依赖更可靠。
7.4 从编辑器到命令行：保持基础能力
编辑器能完成很多操作，但不要把编辑器变成唯一的依赖。Git 冲突处理、包管理、服务器排查这些场景，最终还是要回到命令行。
建议至少要掌握以下命令：
# Git 基础 git status git diff git log --oneline git add -p # 文本处理 grep -rn "keyword" src/ sed -i 's/old/new/g' config.txt使用编辑器是为了提高效率，而不是替代这些基础能力。编辑器与命令行配合使用时，工作流才是最完整的。
8. 把这套编辑环境持续打磨成个人工作流
8.1 按“遇到问题再优化”的节奏迭代
不要追求一次性把配置做到完美。编辑环境是持续演进的，今天用的语言、参与的项目、团队规范都会变化。
推荐节奏是：遇到一个重复操作，先记录，再找自动化方法；遇到一次报错，先记日志，再补充配置；每周或者每两周花少量时间检查一次扩展列表和快捷键。长期下来，配置会越来越贴近实际需求。
8.2 定期检查扩展和配置
项目切换频繁的人，最容易堆积一批“可能以后用得上”的扩展。这些扩展会拖慢启动速度，也可能引发快捷键冲突。
每次切换技术栈时，可以顺手做一次清理：
- 卸载当前语言场景下不用的扩展。
- 删除早就失效的 snippet 和 keybinding。
- 更新所有扩展版本时，关注 major 版本变更说明，因为推荐配置可能不兼容。
配置文件的维护同样重要。如果发现某个设置已经没有作用，建议立即删除，避免日后排查时误判。
8.3 把高频操作练成肌肉记忆
编辑器能力提升的关键不是看教程，而是持续练习。建议每次只练习一组快捷键，并在实际编码任务中有意识地不用鼠标完成那一个操作。最值得优先练习的是命令面板、快速打开文件、多光标、跳转定义和重命名符号。
编辑环境的收益是复利式的。每天在编辑器里停留的时间越长，越值得把它打造成符合自己习惯的工作台。把热门编辑器当作起点，把配置、快捷键和排错能力沉淀到一起，最终会形成一套别人拿不走的工作方法。
