服务端6月18日 23:40
LSP 是什么？VS Code 为什么靠它实现代码智能提示？很多人第一次听到 LSP，会以为它是 VS Code 的某个插件接口。其实它更像一份编辑器和语言工具之间的“通信约定”：编辑器负责打开文件、显示提示、接收用户操作；语言服务器负责理解代码、分析类型、找定义、给诊断结果。
这件事的价值在于，语言能力不用再为每个编辑器重复写一遍。一个 Rust 的语言服务器可以服务 VS Code，也可以服务 Neovim、Emacs、Zed 等编辑器。VS Code 推动并普及了 Language Server Protocol，但 LSP 本身已经是一个跨编辑器的通用协议。
## LSP 解决了什么问题
没有 LSP 之前，编辑器想支持一门语言，通常要在编辑器内部实现一套语言分析能力。代码补全、跳转定义、查找引用、错误检查、重命名，每个功能都要和具体语言绑定。
问题很快就来了：
- TypeScript、Python、Go、Rust 等语言的语法和类型系统差异很大；
- 同一门语言如果要支持多个编辑器，维护成本会成倍增加；
- 编辑器团队不一定最懂语言本身，语言团队也不一定想研究每个编辑器的插件机制。
LSP 的做法很直接：把编辑器通用能力和语言专属能力拆开。编辑器只要会发标准请求，语言服务器只要按标准响应，双方就能配合工作。
## LSP 的基本架构：客户端和语言服务器
LSP 采用客户端-服务器架构。
- **客户端**：通常是 VS Code 扩展或其他编辑器插件，负责 UI、文件事件、用户交互，以及把请求转成 LSP 消息。
- **语言服务器**：独立进程，负责语法分析、类型推断、符号索引、诊断、重构等语言相关逻辑。
- **通信协议**：双方通过 JSON-RPC 2.0 交换消息，常见传输方式包括 stdio、socket、named pipe。
在 VS Code 里，用户按下补全快捷键时，真正发生的大致是：VS Code 客户端把当前文件 URI 和光标位置发给语言服务器；服务器分析上下文后返回候选项；VS Code 再把这些候选项渲染成补全列表。
## 一次典型的 LSP 会话会发生什么
LSP 不是只在用户触发功能时才工作。一个项目打开后，客户端和语言服务器会先建立能力协商，然后不断同步文档状态。
常见流程如下：
1. 客户端发送 `initialize`，告诉服务器自己支持哪些能力，比如补全、诊断、语义高亮。
2. 服务器返回能力声明，比如是否支持跳转定义、重命名、增量同步。
3. 用户打开文件时，客户端发送 `textDocument/didOpen`。
4. 文件内容变化时，客户端发送 `textDocument/didChange`，可以是全文同步，也可以是增量同步。
5. 用户触发补全、悬停、跳转定义时，客户端发送对应请求。
6. 服务器可以主动推送诊断信息，例如 `textDocument/publishDiagnostics`。
7. 项目关闭或扩展停用时，客户端发送 `shutdown` 和 `exit`。
这里有个容易忽略的点：LSP 里的 `line` 和 `character` 通常从 0 开始，位置计算还涉及 UTF-16 code unit。处理中文、emoji 或复合字符时，如果服务器用字节偏移直接换算，很容易出现跳转位置偏一格的问题。
## 核心功能是怎么通过协议表达的
LSP 的接口名称通常很直白，看到方法名基本就能猜到用途。
### 代码补全：textDocument/completion
客户端把当前文档和光标位置发给服务器，服务器返回补全项。
```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "textDocument/completion",
"params": {
"textDocument": { "uri": "file:///path/to/file.ts" },
"position": { "line": 5, "character": 10 }
}
}
```
服务器响应时会返回 `CompletionItem` 列表。每一项可以包含 label、kind、detail、documentation，也可以带上插入文本、排序规则和额外编辑。
```json
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"isIncomplete": false,
"items": [
{
"label": "console",
"kind": 3,
"detail": "Console",
"documentation": "Provides access to the debugging console."
}
]
}
}
```
`isIncomplete` 也很实用。比如补全项依赖用户继续输入，服务器可以先返回一部分候选，并提示客户端后续继续请求。
### 跳转定义：textDocument/definition
跳转定义请求同样依赖文档 URI 和光标位置。
```json
{
"method": "textDocument/definition",
"params": {
"textDocument": { "uri": "file:///path/to/file.ts" },
"position": { "line": 0, "character": 12 }
}
}
```
服务器返回的位置可能是一个 `Location`，也可能是多个位置。比如接口有多个实现、符号来自声明文件和源码文件时，就不一定只有一个答案。
### 悬停提示：textDocument/hover
悬停提示通常用来展示类型、文档注释、函数签名等信息。
```json
{
"method": "textDocument/hover",
"params": {
"textDocument": { "uri": "file:///path/to/file.ts" },
"position": { "line": 2, "character": 8 }
}
}
```
好的 Hover 不是把所有文档都塞进去，而是优先给当前位置最有用的信息。过长的悬停内容会遮住代码，体验反而差。
### 诊断信息：textDocument/publishDiagnostics
诊断和补全、跳转不太一样。它通常是服务器主动推送给客户端，用来显示错误、警告和提示。
```json
{
"method": "textDocument/publishDiagnostics",
"params": {
"uri": "file:///path/to/file.ts",
"diagnostics": [
{
"range": {
"start": { "line": 0, "character": 0 },
"end": { "line": 0, "character": 5 }
},
"severity": 1,
"message": "Cannot find name 'foo'."
}
]
}
}
```
诊断要注意时机。保存时才检查，反馈会慢；每次输入都全量检查，大项目会卡。成熟的语言服务器通常会做增量分析、缓存索引和请求取消。
## 在 VS Code 扩展里接入 LSP
VS Code 扩展通常不直接手写 JSON-RPC，而是使用 `vscode-languageclient` 封装客户端逻辑。服务器端可以用 Node.js、Go、Rust、Java 等语言实现，只要遵守 LSP 即可。
### package.json 注册语言
先告诉 VS Code 哪些文件属于你的语言，以及什么时候激活扩展。
```json
{
"contributes": {
"languages": [
{
"id": "mylang",
"aliases": ["My Language", "mylang"],
"extensions": [".mylang"]
}
],
"grammars": [
{
"language": "mylang",
"scopeName": "source.mylang",
"path": "./syntaxes/mylang.tmLanguage.json"
}
]
},
"activationEvents": ["onLanguage:mylang"]
}
```
语法高亮和 LSP 是两件事。TextMate grammar 负责把代码染色，LSP 负责理解代码语义。很多新扩展看起来“有高亮”，但没有补全和跳转，通常就是只做了 grammar，没有接语言服务器。
### 客户端启动语言服务器
一个简化版 VS Code 客户端大概长这样：
```typescript
import * as vscode from 'vscode';
import { LanguageClient, LanguageClientOptions, ServerOptions } from 'vscode-languageclient/node';
let client: LanguageClient;
export function activate(context: vscode.ExtensionContext) {
const serverModule = context.asAbsolutePath('server/out/server.js');
const serverOptions: ServerOptions = {
run: { command: 'node', args: [serverModule] },
debug: { command: 'node', args: ['--inspect=6009', serverModule] }
};
const clientOptions: LanguageClientOptions = {
documentSelector: [{ scheme: 'file', language: 'mylang' }],
synchronize: {
configurationSection: 'mylang'
}
};
client = new LanguageClient('mylang', 'My Language Server', serverOptions, clientOptions);
context.subscriptions.push(client.start());
}
export function deactivate() {
return client?.stop();
}
```
这里最关键的是 `documentSelector`。如果 language id、文件扩展名或 scheme 对不上，服务器可能已经启动了，但请求根本不会发过去。
## 常见语言服务器有哪些
| 语言 | 常见语言服务器 | 说明 |
|---|---|---|
| TypeScript / JavaScript | tsserver | VS Code 内置 TypeScript 支持主要依赖它，严格说它不是标准 LSP 服务器，但生态里常被一起讨论 |
| Python | Pylance / Pyright | Pylance 基于 Pyright，替代了较早的 python-language-server 方案 |
| Go | gopls | Go 官方维护的语言服务器 |
| Rust | rust-analyzer | Rust 生态主流语言服务器 |
| Java | Eclipse JDT Language Server（jdt.ls） | VS Code Java 扩展常用 |
| C / C++ | clangd | 基于 Clang，支持补全、诊断、跳转等能力 |
如果你只是使用 VS Code，通常不需要手动理解这些服务器。但当补全很慢、跳转失败、诊断不更新时，知道背后是哪一个语言服务器在工作，排查会快很多。
## LSP 的优势和边界
LSP 最大的优势是复用。一套语言分析能力可以被多个编辑器使用，语言团队可以把精力放在语言本身，编辑器团队也不用为每门语言重复造轮子。
它还有几个实际好处：
- **解耦清晰**：编辑器管展示和交互，语言服务器管分析和语义。
- **跨编辑器**：同一语言服务器可以接入不同编辑器。
- **独立优化**：语言服务器可以单独做索引、缓存、多进程和性能分析。
- **扩展能力强**：补全、诊断、Code Action、重命名、格式化、语义高亮都能按协议扩展。
但 LSP 不是万能的。它适合表达编辑器里的语言能力，不负责构建系统、运行时调试、包管理的全部细节。很多复杂能力仍然需要语言服务器读取项目配置，比如 `tsconfig.json`、`go.mod`、`Cargo.toml` 或 Maven/Gradle 配置。配置读错了，协议再标准，结果也会错。
## 性能优化时最该关注什么
语言服务器性能问题通常不是某一个请求慢，而是项目变大后，索引、诊断和文件监听一起把资源吃满。
实用的优化方向有几个：
- **增量同步**：优先处理变化片段，而不是每次重新分析整个文件。
- **缓存符号索引**：项目级符号、依赖包信息、类型结果都应尽量复用。
- **支持取消请求**：用户连续输入时，旧的补全或诊断请求可能已经没有意义，应及时取消。
- **分清前台和后台任务**：补全、悬停要快；全项目索引可以放后台慢慢做。
- **控制诊断频率**：输入中频繁全量诊断会拖慢编辑器，适当 debounce 很重要。
- **尊重工作区配置**：不同项目可能有不同编译参数、依赖路径和语言版本。
有些扩展会尝试“延迟初始化”，但 LSP 标准流程里更常见的做法是通过能力协商、懒加载索引和后台任务减少启动压力，而不是让服务器完全不初始化。
## 调试 LSP 问题的几个切入点
遇到 VS Code 里补全不出来、跳转失败，可以按这个顺序看：
1. **确认文件语言模式是否正确**：右下角 language id 是否是扩展注册的语言。
2. **检查语言服务器是否启动**：看 VS Code Output 面板里对应扩展的日志。
3. **确认 documentSelector 是否匹配**：scheme 是 `file`、`untitled` 还是远程工作区，都会影响匹配。
4. **检查项目配置**：例如 TypeScript 看 `tsconfig.json`，Go 看 `go.mod`，Rust 看工作区和 crate 配置。
5. **查看请求和响应日志**：很多 language client 支持 trace，可以看到 JSON-RPC 消息。
6. **注意路径和 URI**：Windows 路径、符号链接、大小写差异，都可能让服务器找不到文件。
LSP 的核心并不复杂：编辑器问问题，语言服务器回答问题；编辑器同步文件状态，语言服务器返回语义结果。真正决定体验的，是语言服务器对项目的理解是否准确、响应是否足够快、错误信息是否能帮开发者定位问题。标签
VSCode
VSCode是一款强大的代码编辑器，支持多种编程语言。它有着易于使用的用户界面和丰富的插件生态系统，可以提高您的开发效率和优化开发流程。探索VSCode，提高您的代码编写和调试体验
服务端6月18日 23:40
VS Code snippets 代码片段如何创建并高效使用？## 为什么要用 VS Code snippets
如果你经常重复写 `console.log`、React 组件、文件头注释、Python 类或者 HTML 模板，VS Code snippets 就很值得配置。它的作用很直接：输入一个短前缀，按下 Tab 或 Enter，就把一段常用代码插入到当前位置，并且让光标按顺序跳到需要修改的地方。
它适合解决两类问题：一类是减少重复输入，另一类是统一团队写法。比如每个人创建 React 组件时都按同一套 props、导出方式和文件头格式来写，后续维护会少很多无意义差异。
## VS Code 代码片段存放在哪里
VS Code 的代码片段主要有三种范围，选择哪一种取决于你希望它给谁用、在哪些文件里生效。
| 类型 | 存放位置 | 适合场景 |
|---|---|---|
| 用户代码片段 | VS Code 用户配置目录 | 只给自己用，跨项目生效 |
| 语言代码片段 | 针对 JavaScript、Python、HTML 等语言配置 | 只在某一种语言文件里提示 |
| 项目代码片段 | 项目下的 `.vscode/*.code-snippets` | 团队共享，随仓库提交 |
个人习惯类片段放用户配置里就够了；团队约定类片段更建议放在项目的 `.vscode` 目录中，这样新人拉下仓库后也能直接使用。
## 如何创建 VS Code snippets
最常用的创建方式是通过 VS Code 菜单进入：
1. 打开命令面板或菜单：`File > Preferences > Configure User Snippets`
2. 选择一种语言，例如 `javascript.json`、`typescriptreact.json`、`python.json`
3. 如果要创建全局片段，选择 `New Global Snippets file...`
4. 如果要给当前项目共享，创建 `.vscode/xxx.code-snippets`
5. 按 JSON 格式写入片段并保存
一个最小可用的代码片段长这样：
```json
{
"Print Console Log": {
"prefix": "log",
"body": ["console.log($1);"],
"description": "Insert console.log"
}
}
```
保存后，在支持的文件里输入 `log`，选择提示项，按 Tab 或 Enter 即可展开。
## 代码片段的基本结构
一个 snippet 通常包含三个字段：
```json
{
"Snippet Name": {
"prefix": "trigger",
"body": [
"code line 1",
"code line 2"
],
"description": "Snippet description"
}
}
```
- `Snippet Name`：片段名称，主要给自己识别用。
- `prefix`：触发前缀，可以是字符串，也可以是数组。
- `body`：真正插入的代码，多行时用数组更清晰。
- `description`：提示列表里展示的说明，建议写得具体一点。
如果一个片段有多个触发词，可以这样写：
```json
{
"Console Log": {
"prefix": ["log", "clg"],
"body": "console.log($1);",
"description": "Insert console.log"
}
}
```
前缀不宜太长，也不宜和语言关键字冲突。比如 `class` 虽然好记，但在 Python 或 JavaScript 里很容易和正常输入打架，团队项目里可以用 `pyclass`、`rfc`、`useeffect` 这类更明确的前缀。
## 占位符和光标跳转怎么写
占位符是 snippets 最有用的部分。`$1`、`$2` 表示光标跳转顺序，`$0` 表示最后停留的位置。
```json
{
"Function Template": {
"prefix": "func",
"body": [
"function ${1:functionName}(${2:parameters}) {",
"\t$0",
"}"
],
"description": "Create a function"
}
}
```
展开后，光标会先选中 `functionName`，按 Tab 跳到 `parameters`，最后停在函数体内。`${1:functionName}` 里的 `functionName` 是默认文本，可以直接覆盖。
相同编号的占位符会同步修改，适合组件名、类名这类需要出现多次的内容：
```json
{
"Named Export Function": {
"prefix": "nef",
"body": [
"export function ${1:handler}(${2:params}) {",
"\treturn ${1:handler}Result;",
"}"
],
"description": "Create named exported function"
}
}
```
这里两处 `${1:handler}` 会一起变化，少一次手动改名，也少一次拼写错误。
## Choice 选项适合写固定分支
如果某个位置只允许几种固定值，可以用 choice 占位符：
```json
{
"Console Statement": {
"prefix": "console",
"body": [
"console.${1|log,warn,error,info|}($2);"
],
"description": "Insert console statement"
}
}
```
展开后，第一个位置会出现 `log`、`warn`、`error`、`info` 选项。它很适合日志级别、HTTP 方法、组件状态、CSS display 值这类内容。
## 常用变量怎么用
VS Code snippets 支持预定义变量，可以读取当前文件名、路径、日期、剪贴板等信息。
```json
{
"File Header": {
"prefix": "header",
"body": [
"// File: ${TM_FILENAME}",
"// Author: ${TM_USERNAME}",
"// Date: ${CURRENT_YEAR}-${CURRENT_MONTH}-${CURRENT_DATE}",
"",
"$0"
],
"description": "Insert file header comment"
}
}
```
常用变量包括：
| 变量 | 含义 |
|---|---|
| `TM_FILENAME` | 当前文件名，包含扩展名 |
| `TM_FILENAME_BASE` | 当前文件名，不包含扩展名 |
| `TM_DIRECTORY` | 当前文件目录 |
| `TM_FILEPATH` | 当前文件完整路径 |
| `CLIPBOARD` | 剪贴板内容 |
| `CURRENT_YEAR` | 当前年份 |
| `CURRENT_MONTH` | 当前月份 |
| `CURRENT_DATE` | 当前日期 |
有些变量取不到值时，VS Code 会把它当作普通占位符处理，所以写完后最好在真实文件里展开一次，确认效果符合预期。
## JavaScript 和 TypeScript 片段示例
React 项目里，组件模板是最常见的 snippet。下面这个例子保留了组件名复用、props 类型和默认导出：
```json
{
"React TypeScript Component": {
"prefix": "rfc",
"body": [
"import React from 'react';",
"",
"interface ${1:ComponentName}Props {",
"\t${2:prop}: ${3:type};",
"}",
"",
"const ${1:ComponentName}: React.FC<${1:ComponentName}Props> = ({ ${2:prop} }) => {",
"\treturn (",
"\t\t<div>",
"\t\t\t${4:content}",
"\t\t</div>",
"\t);",
"};",
"",
"export default ${1:ComponentName};",
"$0"
],
"description": "Create React functional component with TypeScript"
}
}
```
实际项目里可以按团队规范调整，比如是否使用 `React.FC`、是否默认导出、是否引入样式文件。不要把模板写成唯一正确答案，snippet 应该服务于项目习惯。
## Python 片段示例
Python 类模板可以把类名、文档字符串和初始化参数都做成占位符：
```json
{
"Python Class": {
"prefix": "pyclass",
"body": [
"class ${1:ClassName}:",
"\t\"\"\"${2:Class description}\"\"\"",
"",
"\tdef __init__(self${3:, args}):",
"\t\t${4:pass}",
"\t\t$0"
],
"description": "Create Python class template"
}
}
```
注意缩进建议用 `\t`，VS Code 会按当前文件的缩进配置转换。团队如果强制空格缩进，也可以直接写空格，但不同编辑器设置下更容易不一致。
## HTML 片段示例
HTML5 模板适合放在 HTML 语言片段里：
```json
{
"HTML5 Boilerplate": {
"prefix": "html5",
"body": [
"<!DOCTYPE html>",
"<html lang=\"zh-CN\">",
"<head>",
"\t<meta charset=\"UTF-8\">",
"\t<meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">",
"\t<title>${1:Page Title}</title>",
"</head>",
"<body>",
"\t${2:content}",
"</body>",
"</html>"
],
"description": "Create HTML5 boilerplate"
}
}
```
如果你经常写中文页面，把 `lang` 默认成 `zh-CN` 会比复制英文模板后再改更省心。
## Transform 转换能处理文件名
Transform 可以对变量或占位符做正则转换。它不适合写太复杂的逻辑，但用来处理文件名大小写很方便。
```json
{
"Import Current File Name": {
"prefix": "impfile",
"body": [
"import { ${TM_FILENAME_BASE/(.*)/${1:/capitalize}/} } from './${TM_FILENAME_BASE}';"
],
"description": "Import with transformed file name"
}
}
```
如果文件名是 `button.ts`，展开后会得到类似：
```ts
import { Button } from './button';
```
Transform 的语法可读性一般，建议只在收益明显时使用。复杂到需要反复解释的转换，不如写一个更直白的片段，维护成本更低。
## 全局代码片段怎么共享
全局片段文件通常命名为 `global.code-snippets`，可以在所有语言里生效。适合放 TODO、版权注释、通用注释块这类不依赖具体语言的模板。
```json
{
"TODO Comment": {
"prefix": "todo",
"body": [
"// TODO: ${1:description} - ${CURRENT_YEAR}-${CURRENT_MONTH}-${CURRENT_DATE}"
],
"description": "Insert TODO comment with date"
}
}
```
但要注意，通用片段不一定适合所有语言。上面的 `//` 注释在 JavaScript、TypeScript、Go 里没问题，在 HTML 或 CSS 中就不合适。如果要跨语言使用，最好把前缀和描述写清楚，避免误触。
## 项目代码片段更适合团队规范
如果片段和某个仓库强相关，建议放到项目里：
```text
.vscode/
project.code-snippets
```
示例：
```json
{
"Project API Handler": {
"prefix": "api-handler",
"body": [
"export async function ${1:handlerName}(req: Request) {",
"\ttry {",
"\t\t${2:// handle request}",
"\t} catch (error) {",
"\t\t${3:// handle error}",
"\t}",
"}"
],
"description": "Create project API handler"
}
}
```
这类片段可以和代码审查规则配合起来：模板里提前放好错误处理、日志字段、命名约定，少靠口头提醒。
## 使用时容易踩的坑
### JSON 转义写错
片段文件是 JSON。双引号要转义，反斜杠也要转义。比如 HTML 属性里的引号要写成 `\"`，换行不要直接写在字符串中，多行内容用数组更稳。
### 前缀和已有补全冲突
如果 `prefix` 太短，可能被变量名、关键字、Emmet 或语言服务补全淹没。团队片段最好用有辨识度的前缀，例如 `rfc`、`api-handler`、`pyclass`。
### 片段没有出现
可以按顺序检查：
1. 当前文件语言模式是否正确，比如 `.tsx` 是否识别为 TypeScript React。
2. snippet 是否写在对应语言文件或全局文件中。
3. JSON 是否有语法错误。
4. `editor.snippetSuggestions` 是否被关闭或排序靠后。
5. 当前输入位置是否允许代码补全。
### 项目片段和用户片段重复
当项目片段和用户片段前缀相同，提示列表里可能出现多个相似项。团队项目中最好约定前缀命名，个人片段避免覆盖团队片段。
### 不要期待片段自动调用另一个片段
VS Code snippets 本身不是宏系统，不能可靠地在一个 snippet 里自动展开另一个 snippet。可以把公共部分复制进模板，或者通过扩展、任务脚本解决更复杂的生成需求。
## 什么时候不该用 snippets
代码片段适合静态模板，不适合复杂生成逻辑。如果你需要根据接口定义生成类型、批量创建文件、读取项目配置再输出代码，脚手架或代码生成器更合适。
一个简单判断是：只替换几个名称、参数、路径，用 snippets；需要计算、读取文件或跨目录生成，用脚本工具。
## 写好 VS Code snippets 的几个原则
- 把最常改的内容做成 `$1`、`$2`，不要让光标在模板里来回找。
- 重复出现的名称使用同一个占位符编号，减少手动同步。
- `description` 写清楚用途，尤其是团队共享片段。
- 片段要短而准，不要把一整套业务逻辑塞进去。
- 保存后在真实文件里试一次，确认缩进、引号、Tab 跳转都正常。
VS Code snippets 的价值不在于写出多花哨的语法，而是把每天重复输入、容易写错、团队需要统一的代码固定下来。配置几条真正高频的片段，通常比收藏一大堆用不上的模板更有效。服务端6月18日 23:40
VS Code 远程开发如何配置 SSH、容器和 WSL？如果你经常遇到“本地能跑，服务器上跑不了”“Windows 路径和 Linux 权限打架”“团队每个人 Node、Python、Docker 版本都不一样”，VS Code 远程开发能省掉不少环境折腾。
它的工作方式很直接：VS Code 界面仍在本地，代码、终端、语言服务、调试器可以运行在 SSH 服务器、Docker 容器或 WSL 里。也就是说，你看到的是本地编辑器体验，实际执行环境却贴近生产或项目约定的开发环境。
## 先判断该用哪种远程开发模式
VS Code 远程开发常见有三种入口，不建议一上来全装全配，先按场景选。
| 模式 | 适合场景 | 主要依赖 | 典型优势 |
| --- | --- | --- | --- |
| Remote SSH | 代码和服务在远程 Linux 服务器上 | SSH 服务、远程账号 | 接近线上环境，适合后端、算法、运维开发 |
| Dev Containers | 项目希望用容器固定依赖版本 | Docker、`.devcontainer` 配置 | 团队环境一致，换电脑也容易恢复 |
| WSL | Windows 用户需要 Linux 开发环境 | WSL 2、Linux 发行版 | 比虚拟机轻，适合前端、Node、Python、Go 等项目 |
一句话选择：已有远程服务器就用 Remote SSH；想把项目依赖锁进容器就用 Dev Containers；Windows 本机开发 Linux 项目优先用 WSL。
## Remote SSH 如何配置
Remote SSH 的重点不是“远程同步文件”，而是 VS Code 会在远程机器上安装一个 VS Code Server。你打开的文件、运行的终端、语言服务都在远程机器上执行，本地只负责显示界面。
### 远程机器需要先满足这些条件
连接前先确认几件事，比反复重装扩展更省时间：
- 远程服务器开启了 SSH 服务，端口能从本机访问。
- 远程账号有可写的 home 目录，VS Code Server 默认会装到 `~/.vscode-server`。
- 磁盘空间不能太紧张，语言服务、扩展和缓存会占用一定空间。
- Shell 环境正常，登录后能执行基础命令，如 `sh`、`tar`、`uname`。
- 如果服务器在公司内网或云厂商安全组后面，要先放通对应端口。
### 本地安装扩展并配置 SSH 主机
在 VS Code 扩展市场安装 **Remote - SSH**。如果你安装的是 Remote Development 扩展包，也会包含它。
然后编辑本机 SSH 配置文件：
```sshconfig
Host dev-linux
HostName 192.168.1.100
User username
Port 22
IdentityFile ~/.ssh/id_rsa
ServerAliveInterval 30
ServerAliveCountMax 3
```
几个字段的含义：
- `Host` 是你在 VS Code 里看到的别名，可以随便取。
- `HostName` 写服务器 IP 或域名。
- `User` 是远程登录用户。
- `IdentityFile` 指向私钥路径，建议用密钥登录，不要长期依赖密码。
- `ServerAliveInterval` 和 `ServerAliveCountMax` 可以减少空闲连接被断开的概率。
如果还没有 SSH 密钥，可以先生成一对，再把公钥放到服务器的 `~/.ssh/authorized_keys`。私钥权限过宽会导致 SSH 拒绝使用，常见修复是：
```bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/config
```
### 在 VS Code 中连接远程主机
按 `F1` 或 `Ctrl+Shift+P` 打开命令面板，执行：
```text
Remote-SSH: Connect to Host
```
选择刚才配置的 `dev-linux`。首次连接时，VS Code 会在远程机器下载并安装 VS Code Server。成功后左下角会显示远程主机名，这时再选择远程目录作为工作区。
连接后要注意一个细节：集成终端已经在远程服务器上运行。你执行 `npm install`、`pip install`、`go test`，消耗的是远程机器资源，不是本机资源。
## 远程开发时文件、扩展和终端怎么工作
很多人第一次用 Remote SSH 会误以为 VS Code 在同步本地文件，其实不是。
### 文件操作发生在远程机器
你打开 `/home/username/project` 后，保存、搜索、Git 操作默认都针对远程目录。这样做的好处是不会出现“本地改了但服务器忘记同步”的问题。
如果你需要把本地文件传到远程，建议用 Git、SCP、rsync 或直接在远程仓库拉代码，不要把 VS Code 当作文件同步工具。
### 扩展分本地和远程两类
VS Code 会把扩展大致分成两类：
- 主题、图标、快捷键这类界面扩展留在本地运行。
- ESLint、TypeScript、Python、Go、调试器这类依赖项目环境的扩展会安装到远程。
如果某个语言提示突然失效，先看扩展面板里它是不是装在远程侧。有些扩展旁边会出现 “Install in SSH: xxx” 的按钮，需要手动点一下。
### 终端环境和远程登录环境不一定完全相同
VS Code 集成终端通常会读取远程用户的 shell 配置，但它和你直接用系统终端 SSH 登录仍可能有差异。比如 Node 版本管理器、conda、nvm 的初始化脚本没有加载，就会出现命令找不到。
遇到这种情况，先在 VS Code 终端里执行：
```bash
which node
node -v
echo $SHELL
```
确认路径和版本，再检查 `.bashrc`、`.zshrc` 或 profile 配置。
## Dev Containers 如何配置
Dev Containers 适合“项目依赖比较重、团队环境容易不一致”的情况。它会把开发环境放进 Docker 容器，VS Code 连接到容器内部工作。
先安装 **Dev Containers** 扩展。旧教程里常写 “Remote - Containers”，现在扩展名称已经改为 Dev Containers。
项目根目录创建 `.devcontainer/devcontainer.json`：
```json
{
"name": "node-dev",
"image": "mcr.microsoft.com/devcontainers/javascript-node:18",
"customizations": {
"vscode": {
"extensions": ["dbaeumer.vscode-eslint"]
}
},
"postCreateCommand": "npm install",
"remoteUser": "node"
}
```
配置含义如下：
- `image` 指定基础镜像，Node、Python、Go、Java 都有官方 devcontainer 镜像可选。
- `customizations.vscode.extensions` 指定容器内建议安装的 VS Code 扩展。
- `postCreateCommand` 在容器首次创建后执行，常用于安装依赖。
- `remoteUser` 避免容器内文件全由 root 创建，减少权限问题。
配置好后，打开命令面板执行：
```text
Dev Containers: Reopen in Container
```
VS Code 会构建或拉取镜像，把项目挂载进容器，再重新打开窗口。
### Dev Containers 常见坑
容器开发最常见的慢，往往不是 VS Code 慢，而是构建上下文太大。把 `node_modules`、`dist`、日志文件、缓存目录写进 `.dockerignore`，能明显减少构建时间。
如果每次重建容器都要重新安装依赖，可以考虑用 Docker volume 缓存依赖目录。Node 项目尤其要注意，不要把宿主机的 `node_modules` 直接带进 Linux 容器，平台差异会让二进制依赖出问题。
端口方面，VS Code 通常会自动提示转发。比如容器里启动了 `localhost:3000`，本机浏览器可以通过转发端口访问。没有提示时，可以在 Ports 面板手动添加。
## WSL 远程开发如何配置
WSL 适合 Windows 用户。它比传统虚拟机轻，也比把项目放在 Windows 文件系统里硬跑 Linux 工具顺手。
基本步骤：
1. 安装 WSL 2 和一个 Linux 发行版，如 Ubuntu。
2. 在 VS Code 安装 **WSL** 扩展。
3. 打开 WSL 终端，进入项目目录后执行 `code .`。
推荐把项目放在 WSL 的 Linux 文件系统里，例如：
```bash
~/projects/my-app
```
不建议长期放在 `/mnt/c/Users/...` 下开发。跨 Windows 文件系统访问会更慢，文件权限、大小写、监听变更也更容易出问题。前端项目的 `node_modules` 很多时，这个差异会被放大。
如果你同时用 Docker Desktop，记得开启对应发行版的 WSL integration。否则 VS Code 在 WSL 里可能找不到 Docker，或者连接到了和预期不同的 Docker daemon。
## 如何减少卡顿和连接中断
远程开发是否顺手，很大程度取决于网络、文件监听和扩展数量。
### 减少不必要的文件监听
大型项目可以在工作区设置里排除构建产物和依赖目录：
```json
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/.git/objects/**": true,
"**/dist/**": true,
"**/build/**": true
},
"search.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/build": true
}
}
```
这不会删除文件，只是减少 VS Code 的监听和搜索负担。
### 只在远程安装必要扩展
语言服务、调试器、Lint 工具需要远程运行；主题、图标、Markdown 预览这类通常留在本地就够了。远程服务器配置不高时，少装几个后台常驻扩展，比改很多小参数更有效。
### SSH 连接优先用密钥和保持活跃配置
密码登录不仅麻烦，也更容易受安全策略影响。推荐使用密钥加 ssh-agent。连接经常断开时，优先检查网络和安全组，再补充 keep alive 配置：
```sshconfig
Host *
ServerAliveInterval 30
ServerAliveCountMax 3
```
如果公司网络需要跳板机，可以在 SSH config 里配置 `ProxyJump`，这样 VS Code 也能复用同一套连接方式。
## 常见问题怎么排查
| 问题 | 优先检查 | 处理思路 |
| --- | --- | --- |
| 连接失败 | SSH 配置、端口、安全组、用户名 | 先用系统终端执行 `ssh dev-linux`，确认普通 SSH 能连通 |
| 一直卡在 Installing VS Code Server | 远程磁盘、home 权限、下载网络 | 清理 `~/.vscode-server` 后重连，或检查服务器是否能访问下载源 |
| 终端命令找不到 | shell 初始化脚本、PATH、nvm/conda | 在 VS Code 终端和普通 SSH 终端分别对比 `echo $PATH` |
| 保存文件提示权限不足 | 项目目录所有者、容器用户、sudo 创建文件 | 修正目录 owner，Dev Containers 中设置 `remoteUser` |
| TypeScript、Python 提示失效 | 扩展是否安装在远程、解释器路径 | 在远程扩展区安装语言扩展，并选择正确解释器 |
| WSL 项目很慢 | 项目是否在 `/mnt/c` 下 | 把项目移动到 WSL Linux 文件系统内 |
| 容器反复重装依赖 | 镜像缓存、volume、postCreateCommand | 使用 `.dockerignore` 和依赖缓存，避免把无关文件放进构建上下文 |
排查顺序建议从“普通 SSH 或普通终端是否正常”开始。VS Code 远程开发建立在这些基础能力之上，底层连接或环境本身不稳定，编辑器层面很难单独修好。
## 安全和备份别忽略
远程开发会让本地编辑器直接操作服务器文件，权限边界要想清楚。
- 私钥不要提交到仓库，也不要放进项目目录。
- 谨慎使用 SSH Agent Forwarding，只在确实需要远程服务器继续访问 Git 仓库时开启。
- 生产服务器不建议直接当开发机，至少要使用低权限账号和独立目录。
- 远程环境变量、密钥、数据库配置应放在服务器或密钥管理系统中，不要写进代码。
- 远程代码也要走 Git，不要只依赖服务器上的一份工作区。
## 最后怎么选
Remote SSH 适合直接在远程 Linux 机器上开发和调试；Dev Containers 适合把依赖、工具链和扩展配置一起固化到项目里；WSL 适合 Windows 用户获得更自然的 Linux 开发体验。
如果是个人项目，WSL 或 Remote SSH 通常最快上手。如果是团队项目，Dev Containers 的前期配置成本更高，但能减少“我这里跑不起来”的沟通成本。真正影响体验的不是装了多少远程扩展，而是环境边界是否清楚：文件在哪里，命令在哪里执行，依赖装在哪个系统里。服务端6月18日 23:35
VS Code 多光标编辑技巧怎么用，新手该记哪些快捷键才不误改？## 先确认：多光标适合改什么
VS Code 的多光标很适合处理“文本长得一样、修改规则也一样”的小批量编辑，比如给多行末尾加逗号、把几个相同前缀改成新前缀、同时补齐对象属性名。
它不适合替代语义级重命名。比如 TypeScript 里的变量、函数、类名重命名，更稳的做法通常是按 `F2` 使用 Rename Symbol，因为它会理解作用域和引用关系。多光标只看文本，选错一个位置就会把不该改的地方一起改掉。
## 常用多光标快捷键怎么记
不同系统的默认快捷键略有差异，尤其 Linux 和 macOS 容易被系统快捷键占用。下面按 VS Code 常见默认配置整理，实际以 `Keyboard Shortcuts` 面板为准。
| 操作 | Windows / Linux | macOS | 适合场景 |
|---|---|---|---|
| 鼠标添加一个光标 | `Alt + 点击` | `Option + 点击` | 少量不连续位置 |
| 向上/下添加光标 | `Ctrl + Alt + ↑/↓` | `Option + Command + ↑/↓` | 连续多行同一列 |
| 撤销上一次光标操作 | `Ctrl + U` | `Command + U` 常见 | 多选错一个位置时回退 |
| 选中下一个相同词 | `Ctrl + D` | `Command + D` | 逐个确认是否要改 |
| 选中所有相同内容 | `Ctrl + Shift + L` | `Command + Shift + L` | 当前文件内全部都要改 |
| 选中当前词所有出现位置 | `Ctrl + F2` | `Command + F2` | 快速改同一个词 |
| 在已选多行行尾加光标 | `Shift + Alt + I` | `Shift + Option + I` | 给多行补后缀、逗号、分号 |
如果 `Ctrl + Alt + ↑/↓` 没反应，先别怀疑 VS Code。很多桌面环境会把它当成切换工作区或屏幕方向快捷键，改系统快捷键或在 VS Code 里重新绑定即可。
## Ctrl+D、Ctrl+Shift+L、Ctrl+F2 有什么区别
### Ctrl+D：边看边选，更安全
先选中一个词，按一次 `Ctrl + D` 选中下一个相同内容，再按一次继续往后选。它适合“有些要改、有些不要改”的情况。
例如代码里同时有 `user` 变量和 `user` 字符串文案，你不确定能不能全改，就用 `Ctrl + D` 一个个确认。
### Ctrl+Shift+L：一次全选，适合确定无误的文本
`Ctrl + Shift + L` 会把当前选中的内容在文件里的所有匹配项都变成光标。它速度快，但风险也高。适合所有 `console.log` 都要改成 `console.info`、所有相同占位符都要替换这类场景。
### Ctrl+F2：按当前单词批量选中
`Ctrl + F2` 会选中当前单词的所有实例，通常比手动框选再 `Ctrl + Shift + L` 更快。需要注意的是，它按“单词”匹配，不适合处理带符号、空格或复杂表达式的内容。
## 几个最常见的批量编辑场景
### 给多行末尾同时加内容
假设要把几行字段都补上逗号：
```javascript
const fields = [
'name'
'age'
'email'
]
```
操作方式：选中 `name`、`age`、`email` 三行，按 `Shift + Alt + I`，每行末尾都会出现一个光标，再输入 `,`。
```javascript
const fields = [
'name',
'age',
'email',
]
```
这种做法比正则替换更直观，也比一行行移动光标快。
### 批量改相同前缀
```javascript
const userName = 'John';
const userAge = 25;
const userEmail = 'john@example.com';
```
如果只是想把这三个变量的前缀从 `user` 改成 `customer`，可以选中第一个 `user`，连续按 `Ctrl + D` 选中另外两个，再输入 `customer`。
```javascript
const customerName = 'John';
const customerAge = 25;
const customerEmail = 'john@example.com';
```
这里不要直接选中 `userName` 再全改，因为 `userAge`、`userEmail` 并不完全相同。多光标的关键不是“多”，而是先选准那段共同变化的文本。
### 给对象属性名批量加引号
```javascript
const obj = {
name: 'John',
age: 25,
email: 'john@example.com'
};
```
如果只有几行，可以用列选择或多光标分别放在属性名前后，手动输入引号。行数多时，正则替换更稳：
- 查找：`^(\s*)([a-zA-Z_$][\w$]*):`
- 替换：`$1'$2':`
```javascript
const obj = {
'name': 'John',
'age': 25,
'email': 'john@example.com'
};
```
替换前先看预览，尤其对象里如果混有注释、展开运算符或已经带引号的属性，正则可能匹配到不该改的行。
### 同时注释多行代码
选中多行后按 `Ctrl + /`，VS Code 会按当前语言切换行注释：
```javascript
// const line1 = 'code';
// const line2 = 'code';
// const line3 = 'code';
```
这不算典型多光标操作，但经常和多光标一起用：先批量选中位置，再统一注释、移动或删除。
## 列选择什么时候更好用
列选择适合处理“每一行的目标位置在同一列”的文本，比如日志、CSV、对齐过的配置片段。
- `Shift + Alt + 拖动`：拖出一个矩形选择区域。
- `Ctrl + Shift + Alt + ↑/↓`：向上或向下扩展列选择。
- macOS 通常使用 `Shift + Option + 拖动` 或对应的 Option/Command 组合。
```text
name string
age number
email string
```
想在每行类型前加上 `: `，列选择比逐行移动光标更舒服。它的限制也明显：只适合列对齐的文本，如果每行长度差很多，还是用搜索选择或正则更稳。
## 智能选择能减少手动框选
多光标之前经常要先选中一段代码。VS Code 的智能选择可以按语法单元扩展选择范围：
- `Shift + Alt + →`：扩大选择范围。
- `Shift + Alt + ←`：缩小选择范围。
- `Ctrl + Shift + →/←`：按单词扩展或收缩选择。
比如光标在函数参数里，连续扩大选择可能依次选中变量名、参数表达式、整个参数列表。它比鼠标拖选更不容易少选一个括号或多选一个空格。
## 多光标和查找替换怎么配合
多光标适合“我想边看边改”，正则替换适合“规则非常确定”。两者可以组合使用：先用查找定位，再用多光标处理少量需要人工判断的匹配项。
### 把 console.log 改成 console.info
- 查找：`console\.log\((.*)\)`
- 替换：`console.info($1)`
```javascript
console.log(user);
console.log(order);
```
替换后：
```javascript
console.info(user);
console.info(order);
```
如果项目里有些 `console.log` 是临时调试，有些是刻意保留，别直接全部替换。用查找结果逐个确认，或者先选中当前文件里的目标区域再替换。
### 用捕获组调整调用形式
- 查找：`(\w+)\.(\w+)\((.*)\)`
- 替换：`$2($1, $3)`
它可以把 `obj.method(args)` 改成 `method(obj, args)`。这个例子只适合非常简单的调用形式。真实代码里如果有嵌套括号、链式调用、字符串参数，正则很容易失手。复杂结构改写要考虑 AST 工具或编辑器重构能力，不要硬用一条正则扫全项目。
## 快速跳转和行操作也能提速
| 操作 | Windows / Linux | macOS 常见 |
|---|---|---|
| 跳转到指定行 | `Ctrl + G` | `Control + G` |
| 快速打开文件 | `Ctrl + P` | `Command + P` |
| 跳转到工作区符号 | `Ctrl + T` | `Command + T` |
| 跳转到当前文件符号 | `Ctrl + Shift + O` | `Command + Shift + O` |
| 向下插入新行 | `Ctrl + Enter` | `Command + Enter` |
| 向上插入新行 | `Ctrl + Shift + Enter` | `Command + Shift + Enter` |
| 删除当前行 | `Ctrl + Shift + K` | `Command + Shift + K` |
| 上下移动当前行 | `Alt + ↑/↓` | `Option + ↑/↓` |
| 复制当前行 | `Shift + Alt + ↑/↓` | `Shift + Option + ↑/↓` |
| 格式化文档 | `Shift + Alt + F` | `Shift + Option + F` |
| 格式化选中部分 | `Ctrl + K, Ctrl + F` | `Command + K, Command + F` |
批量编辑后的一个好习惯是立刻看 Git diff。多光标最大的风险不是改得慢，而是改得太快，直到提交前才发现多改了一处字符串或注释。
## 代码折叠适合先缩小编辑范围
文件很长时，可以先用折叠把无关区域收起来：
- `Ctrl + K, Ctrl + 0`：折叠所有区域。
- `Ctrl + K, Ctrl + J`：展开所有区域。
- `Ctrl + K, Ctrl + [`：折叠当前区域。
- `Ctrl + K, Ctrl + ]`：展开当前区域。
折叠不是为了好看，而是减少误选。尤其在处理大文件里的重复字段时，先把无关函数折起来，再用 `Ctrl + D` 或查找结果选择，出错概率会低很多。
## 可以把常用多光标动作改成自己的快捷键
如果你经常对选中多行的行尾插入光标，可以在 `keybindings.json` 里绑定一个更顺手的组合：
```json
[
{
"key": "ctrl+shift+;",
"command": "editor.action.insertCursorAtEndOfEachLineSelected",
"when": "editorTextFocus"
}
]
```
也可以在快捷键面板里搜索这些命令名：`Add Cursor Above`、`Add Cursor Below`、`Add Selection To Next Find Match`、`Select All Occurrences of Find Match`、`Insert Cursor at End of Each Line Selected`、`Cursor Undo`。
## 多光标最容易踩的坑
### 误把文本替换当成语义重命名
同名文本不一定是同一个变量。同一个变量也可能在不同文件里有引用。涉及函数名、类名、导出符号时，优先用 `F2`，不要靠 `Ctrl + Shift + L` 硬改。
### 选中内容带了多余空格
多光标输入会替换每个选区。选区如果多带一个空格、逗号或换行，结果可能变得很奇怪。按键前看一眼高亮范围，特别是使用鼠标拖选时。
### 粘贴行数和光标数不一致
VS Code 支持把多行剪贴板内容分别粘到多个光标位置。比如 3 行内容粘到 3 个光标，会一一对应；如果行数和光标数对不上，结果就可能不是你以为的那样。批量粘贴前可以先在临时文件里试一下。
### 大量光标会拖慢编辑器
几百个光标同时编辑，语法高亮、补全和插件都可能变慢。数量很大时，查找替换、脚本或 codemod 往往更稳。
### 正则替换没限制范围
全文件替换前先选中目标区域，或者至少打开替换预览。很多事故不是正则写错，而是范围太大。
## 什么时候别用多光标
下面几种情况，多光标不是最优解：
- 改变量、函数、类名：优先用 `F2` 重命名符号。
- 改整个项目的 API 调用形式：优先考虑 AST 工具、codemod 或语言服务重构。
- 只为统一格式：交给 formatter 或 linter。
- 匹配规则复杂、有嵌套结构：不要用一条正则赌运气。
多光标最舒服的用法，是处理那些规则简单、范围可控、肉眼能快速确认的小批量修改。语义重命名交给编辑器重构，格式统一交给工具，文本级重复劳动再交给多光标，这样分工更稳。服务端6月18日 23:35
VS Code 扩展如何用 vsce 发布到 Marketplace？## 发布前先确认这几件事
把 VS Code 扩展发布到 Marketplace，本质上有三件事：扩展本身能正常运行，`package.json` 信息能被市场识别，发布者账号和访问令牌配置正确。很多发布失败并不是代码问题，而是 README、图标、publisher、PAT 权限这些细节没准备好。
正式发布前，建议先在本地安装一次 `.vsix` 文件试用。如果本地都装不上，直接 publish 只会把问题推到 Marketplace 的校验阶段。
## 发布前检查清单
发布前至少检查这些内容：
1. 扩展功能已经跑通过，包括激活事件、命令、配置项和异常场景。
2. `README.md` 能说明扩展解决什么问题、怎么安装、怎么使用。
3. 图标准备为 128x128 像素的 PNG，路径要和 `package.json` 中的 `icon` 一致。
4. `package.json` 中的 `name`、`displayName`、`description`、`publisher`、`version` 都填写正确。
5. 仓库地址、许可证、分类和关键词不要空着。
6. 需要排除的源码、测试文件、截图源文件已写入 `.vscodeignore`，避免包体过大。
7. 如果扩展包含原生依赖，要确认是否需要按平台发布不同 target。
一个常见判断标准是：别人只看 Marketplace 页面和 README，就能知道这个扩展值不值得安装。
## package.json 里哪些字段最容易出错
`package.json` 是 Marketplace 读取扩展信息的核心文件。下面是一个较完整的示例：
```json
{
"name": "my-extension",
"displayName": "My Extension",
"description": "A useful VS Code extension",
"version": "1.0.0",
"publisher": "your-publisher-name",
"engines": {
"vscode": "^1.80.0"
},
"categories": ["Other"],
"keywords": ["utility", "productivity", "vscode-extension"],
"icon": "icon.png",
"repository": {
"type": "git",
"url": "https://github.com/username/my-extension"
},
"license": "MIT"
}
```
几个字段要特别留意：
- `name`：扩展包名，发布后频繁改名会影响识别。
- `displayName`：展示给用户看的名称，可以比 `name` 更自然。
- `publisher`：必须和 Marketplace 发布者名称完全一致，不是 Azure DevOps 组织名随便填一个就行。
- `version`：每次正式发布都必须递增，否则会被拒绝。
- `engines.vscode`：表示扩展支持的 VS Code 版本范围，别写得过低，也别为了追新写得太高。
- `categories`：尽量选择贴近功能的分类，分类乱填会影响用户理解。
- `keywords`：写用户可能搜索的词，不要堆无关关键词。
如果扩展有命令、配置项或菜单入口，还要确认 `contributes` 字段里的命令 ID、标题和实际代码一致。命令能注册成功，但标题写得模糊，也会影响用户第一次使用的体验。
## 如何创建 Marketplace 发布者
发布 VS Code 扩展需要先有发布者，也就是 `publisher`。通常流程是：
1. 打开 Visual Studio Marketplace 的管理页面：`https://marketplace.visualstudio.com/manage`
2. 使用 Microsoft 账号登录。
3. 创建一个新的 publisher，填写唯一的发布者名称、显示名称和联系邮箱。
4. 把创建好的 publisher 名称写入扩展的 `package.json`。
这里最容易混淆的是发布者名称和显示名称。发布者名称是扩展唯一标识的一部分，例如 `publisher.extension-name`；显示名称只是市场页面上给人看的名字。真正发布时，`package.json` 里的 `publisher` 要填发布者名称。
## 如何创建 Azure DevOps PAT
`vsce publish` 需要访问令牌，也就是 Azure DevOps 的 Personal Access Token。它不是 Microsoft 账号密码，也不建议使用权限过大的令牌。
创建步骤大致如下：
1. 打开 `https://dev.azure.com/` 并登录同一个 Microsoft 账号。
2. 进入用户设置中的 Personal access tokens。
3. 创建新 token。
4. Organization 建议选择可访问的组织范围。
5. Scope 选择 Marketplace 的 Manage 权限。
6. 生成后立刻复制保存，页面关闭后通常无法再次查看明文。
令牌拿到后，不要写进仓库，也不要放到 README、CI 日志或截图里。最稳妥的做法是只在本机 `vsce login` 时粘贴，CI 发布则放到平台的 Secret 变量中。
## 安装并登录 vsce
`vsce` 是发布 VS Code 扩展最常用的命令行工具，现在包名是 `@vscode/vsce`。
```bash
npm install -g @vscode/vsce
vsce --version
vsce login your-publisher-name
```
命令会要求输入 PAT。登录成功后，本机会保存认证信息。后续执行 `vsce publish` 时就不必每次重复输入。
如果登录失败，优先检查三点：publisher 名称是否拼错、PAT 是否过期、PAT 是否包含 Marketplace Manage 权限。
## 先打包成本地 VSIX 文件
不要第一次就直接发布。先打包成本地 `.vsix` 文件，再安装验证，能省掉很多尴尬。
```bash
vsce package
vsce package --out my-extension-1.0.0.vsix
```
在 VS Code 中可以通过命令面板选择 “Extensions: Install from VSIX...” 安装本地包。重点测试这些内容：
- 扩展是否能被激活。
- 命令是否能执行。
- 配置项是否显示正常。
- README、图标、仓库链接是否正确。
- 打包后是否缺少运行时文件。
如果发现包里混进了测试文件、源码草稿或大体积资源，可以通过 `.vscodeignore` 排除。例如：
```gitignore
.vscode/**
src/**
test/**
*.map
*.vsix
node_modules/.cache/**
```
注意不要误删运行时需要的编译产物。如果扩展运行依赖 `dist`，就不能把 `dist/**` 排除掉。
## 如何首次发布扩展
确认本地 VSIX 没问题后，可以执行：
```bash
vsce publish
```
这个命令会读取 `package.json`，打包并上传到 Marketplace。首次发布成功后，市场页面不一定立刻完全可见，搜索索引和统计数据可能有延迟。
如果希望发布时自动递增版本，可以使用：
```bash
vsce publish patch
vsce publish minor
vsce publish major
vsce publish 1.1.0
```
团队协作时要注意把版本变更提交到 Git，否则下一位同事可能基于旧版本继续发布，导致版本号冲突。
## 预发布版本怎么发
如果新功能还不想推给所有用户，可以发布预发布版本：
```bash
vsce publish --pre-release
```
预发布适合测试较大的功能改动，例如重构语言服务、改动配置格式、引入新 UI。它能让愿意尝鲜的用户提前安装，但不应该拿来替代正常测试。
## 需要按平台发布时怎么处理
纯 TypeScript 扩展通常不需要区分平台。但如果扩展包含原生依赖、平台二进制文件，或者对不同系统有不同产物，就要考虑 target。
```bash
vsce package --target win32-x64
vsce package --target linux-x64
vsce package --target darwin-arm64
vsce publish --target win32-x64
```
是否需要多平台发布，取决于扩展是否真的包含平台相关文件。不要为了看起来专业而拆平台包，纯 JS 扩展拆了反而增加维护成本。
## 版本管理应该怎么做
VS Code 扩展一般使用语义化版本：
- `major`：有不兼容变更，例如配置字段改名、命令行为明显变化。
- `minor`：增加新功能，但不破坏现有用户使用方式。
- `patch`：修复 bug、优化文档、处理兼容性小问题。
版本号不是装饰。用户看到频繁的 major 版本，会担心扩展不稳定；长期不更新 patch，又会怀疑项目没人维护。
## 更新、下架和删除版本
更新扩展的流程很简单：修改代码，更新版本，重新发布。
```bash
vsce publish patch
```
如果确实需要下架扩展，可以使用 unpublish。实际命令通常需要带上发布者和扩展名，格式类似：
```bash
vsce unpublish your-publisher-name.my-extension
```
下架是高风险操作。已经安装的用户、文档链接、依赖说明都会受到影响。除非扩展有严重安全问题、侵权问题或完全废弃，不建议轻易下架。
## Marketplace 页面怎么写更容易被安装
用户通常会先看三样东西：扩展能解决什么问题、怎么用、是否可信。
- **描述开头直接说用途**：不要用“一个强大的插件”这类空话。
- **README 放最短可用路径**：安装后第一步点哪里、执行什么命令、预期看到什么结果。
- **截图只放必要内容**：截图要能解释功能，不要放大段无关 UI。
- **关键词贴近搜索意图**：例如 `formatter`、`snippet`、`theme`、`debugger`、`productivity`。
- **仓库和许可证清楚**：开发者工具类扩展尤其需要可信度。
## 常见发布失败原因
### publisher 不匹配
`package.json` 里的 `publisher` 和 Marketplace 创建的 publisher 不一致，会导致发布失败。大小写、短横线、拼写都要对齐。
### PAT 权限不够
只创建了普通 Azure DevOps token，但没有 Marketplace Manage 权限，`vsce login` 或 `vsce publish` 会失败。重新生成 PAT 比反复改命令更快。
### version 没有递增
同一个版本不能重复发布。修复一个错别字也要递增 patch 版本。
### .vscodeignore 排除了运行文件
为了减小体积把 `dist`、`out` 或资源文件排除了，结果本地源码能跑，安装 VSIX 后不能跑。发布前安装本地包就是为了抓这类问题。
### 包体里包含敏感信息
不要把 `.env`、测试 token、私钥、内部接口文档打进扩展包。发布前可以解压 `.vsix` 看一眼内容，尤其是公司项目转开源时更要小心。
## 一个更稳妥的发布流程
实际项目里可以按这个顺序走：
1. 本地跑测试和 lint。
2. 检查 `package.json`、README、LICENSE、icon。
3. 更新 changelog 和版本号。
4. 执行 `vsce package`。
5. 在 VS Code 里安装生成的 VSIX。
6. 用真实场景试一遍核心功能。
7. 确认 `.vsix` 中没有敏感文件和无关大文件。
8. 执行 `vsce publish`。
9. 打开 Marketplace 页面检查展示效果。
发布 VS Code 扩展不难，难的是把账号、令牌、版本、包内容这些细节处理稳定。流程固定下来后，每次发布只需要关注两个问题：这次改动是否值得发一个新版本，以及用户安装后能不能马上用起来。服务端6月4日 12:49
VS Code 搜索有哪些高级技巧？正则、符号搜索和排除配置详解VS Code 搜索分为三层：**文件内搜索**（Ctrl+F）、**跨文件搜索**（Ctrl+Shift+F）、**符号搜索**（Ctrl+T）。多数人只会前两个，第三个才是效率杀手。
## 文件内搜索：Ctrl+F 的隐藏技巧
三个按钮决定搜索行为：**Aa**（大小写敏感）、**Ab**（全字匹配）、**.\*** （正则表达式）。最常用的组合是开着正则 + 关闭大小写——比如搜 `console\.(log|warn|error)` 一键找到所有 console 调用。
`Alt+Enter` 一键选中所有匹配项，进入多光标模式——批量修改变量名的最快方式，比重构命令还快。
## 跨文件搜索：排除比搜索更重要
`Ctrl+Shift+F` 搜整个项目，但大项目搜 node_modules 或 dist 会卡死。必须配置排除规则：
```json
{
"search.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/.git": true,
"**/*.min.js": true,
"**/build": true
}
}
```
搜索框下方的 include 和 exclude 输入框可以临时覆盖——比如只在 src 目录搜，exclude 填 *，include 填 src/**。
**替换前一定要预览**：`Ctrl+Shift+H` 打开全局替换，每个替换结果旁边有 diff 预览，逐条确认后再批量替换。直接全局替换改出 bug 是血泪教训。
## 正则搜索：最实用的几个模式
| 场景 | 搜索正则 | 说明 |
|------|----------|------|
| 找所有 TODO | TODO|FIXME|HACK | 多关键词 OR |
| 找函数定义 | function\s+\w+ | 匹配 function 关键字 |
| 找中文注释 | [一-鿿]+ | Unicode 中文范围 |
| 找空行 | ^\s*$ | 配合全字匹配找空行 |
| 替换引号风格 | 查找 "(\w+)" 替换 '$1' | 捕获组替换 |
正则替换中 $1、$2 引用捕获组——比手动一个个改快 100 倍。
## 符号搜索：Ctrl+T 是效率秘密
`Ctrl+T` 搜索工作区里的函数、类、变量名——不搜文件内容，搜代码结构。输入 handleSubmit 直接跳到函数定义，不需要知道在哪个文件。支持模糊匹配：hse 就能匹配 handleSubmit。
`Ctrl+Shift+O` 搜索当前文件的符号，按类型分组（函数、类、变量）。输入 @: 前缀按类别分组显示——@:f 只看函数，@:c 只看类。
## 快速打开：Ctrl+P 不只是开文件
`Ctrl+P` 模糊搜索文件名，但输入 : 跳到指定行号（如 app.js:42），输入 @ 跳到文件内符号（如 app.js@handleSubmit），输入 # 搜索工作区符号。一行搞定打开某文件的某个函数。
## 追问
### 搜索太慢怎么办？
三个优化：(1) 检查 search.exclude 是否排除了 node_modules/dist/build；(2) 大文件搜索关掉正则模式，纯文本搜索快 10 倍；(3) 超大仓库考虑用 ripgrep（VS Code 内置，但确认 search.useRipgrep 没被关掉）。
### 怎么搜索 Git 某次提交引入的变更？
VS Code 内置 Git 搜索不支持这个。用命令行更快：`git log -S "keyword"` 找到引入某关键字的提交，`git show <hash>` 看具体变更。或者在 VS Code 的 Git 面板里搜索历史记录。
### 怎么在搜索结果中排除某个目录但不修改全局配置？
搜索面板的 exclude 输入框支持临时规则，只对当前搜索生效。比如填 **/test/** 临时排除测试文件，不影响全局设置。搜索完后清空即可。服务端6月4日 12:47
VS Code 调试适配器协议 DAP 是什么？架构原理和使用详解调试适配器协议（DAP）是 VS Code 定义的一套标准通信协议，让编辑器和调试器解耦：编辑器只管发 DAP 请求，调试器只管响应——中间的适配器负责翻译。这样 VS Code 不需要内置每个调试器，只要有人写了对应的适配器，就能调试任何语言。
## 三层架构
VS Code (客户端) <--DAP协议--> 调试适配器 <--私有协议--> 调试器
UI/交互 JSON-RPC 适配器翻译 GDB/LLDB/Node...
没有 DAP 之前，每个编辑器要为每个调试器写一套集成代码（M*N 问题）。有了 DAP，编辑器只实现 DAP 客户端，调试器只实现 DAP 适配器（M+N 问题）。VS Code、JetBrains、Vim 都能复用同一个适配器。
## 核心工作流
一次调试会话的典型流程：
1. initialize — 客户端告诉适配器自己的能力，适配器返回支持的功能
2. launch 或 attach — 启动新程序或附加到已有进程
3. setBreakpoints — 设置断点
4. configurationDone — 配置完成，开始执行
5. 适配器发 stopped 事件 — 程序在断点处暂停
6. 客户端发 stackTrace / scopes / variables — 查看调用栈和变量
7. continue / next / stepIn / stepOut — 控制执行
8. terminated 事件 — 调试结束
所有请求和事件都是 JSON 格式，通过 stdin/stdout 传输。这意味着适配器可以是任何语言写的——Node.js、Python、Rust 都行。
## 用户视角：怎么用 DAP
普通开发者不需要直接写 DAP 请求。你在 VS Code 里按 F5 调试，背后就是 DAP 在工作。你只需要在 launch.json 里配置好调试器类型：
```json
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug Node",
"program": "${workspaceFolder}/app.js"
}
]
}
```
type 字段决定了用哪个适配器。常见类型：node（内置）、python（ms-python 扩展）、cppdbg（C/C++ 扩展）、chrome（浏览器调试）。
## 开发者视角：怎么写适配器
如果你要为自己的语言或运行时写调试支持，用 @vscode/debugadapter 包：
```typescript
import { DebugSession, InitializedEvent, StoppedEvent } from '@vscode/debugadapter';
class MyDebugSession extends DebugSession {
protected initializeRequest(response): void {
response.body = {
supportsConfigurationDoneRequest: true,
supportsEvaluateForHovers: true
};
this.sendResponse(response);
this.sendEvent(new InitializedEvent());
}
protected launchRequest(response, args): void {
// 启动你的调试器，连接目标进程
this.sendResponse(response);
}
protected setBreakPointsRequest(response, args): void {
// 把断点信息翻译成你的调试器能理解的格式
response.body = { breakpoints: args.breakpoints.map(bp => ({ verified: true, line: bp.line })) };
this.sendResponse(response);
}
}
```
关键在于：launchRequest 和 setBreakPointsRequest 里你需要把 DAP 请求翻译成你的调试器的私有命令。适配器就是翻译层。
## 追问
### DAP 和 LSP 是什么关系？
LSP（Language Server Protocol）管编辑：代码补全、跳转定义、诊断。DAP 管调试：断点、单步、变量查看。两者互补，都是微软提出的解耦协议。一个语言扩展通常同时实现 LSP（编辑体验）和 DAP（调试体验）。
### launch 和 attach 有什么区别？
launch 是 VS Code 启动目标程序并开始调试——适合开发阶段。attach 是连接到一个已经运行的进程——适合调试线上问题或容器内的服务。attach 模式需要指定进程 ID 或端口（如 9229 用于 Node.js 的 inspector）。
### 为什么有时候调试器启动很慢？
适配器启动时要初始化调试器、加载符号表、设置断点——符号表特别大的时候（如 C++ 大项目）这一步可能要几秒到几十秒。可以在 launch.json 里设 preLaunchTask: null 跳过不必要的预构建任务，或用 skipFiles 过滤掉不想单步进入的库代码。服务端6月4日 12:46
VS Code 代码格式化怎么配置？Prettier + ESLint 集成指南VS Code 格式化的核心配置就三个问题：**用什么格式化器、什么时候格式化、团队怎么统一**。搞清楚这三件事，剩下的都是细节。
## 最推荐的搭配：Prettier + ESLint
**Prettier** 只管格式（缩进、换行、引号），不管逻辑。**ESLint** 管代码质量（未使用变量、潜在 bug），也管部分格式。两者配合的关键是：让 Prettier 管所有格式规则，ESLint 只管逻辑规则，不要打架。
装 "eslint-config-prettier" 这个包，它会关掉 ESLint 里和 Prettier 冲突的所有规则：
```bash
npm install --save-dev prettier eslint-config-prettier
```
```js
// .eslintrc.js
module.exports = {
extends: ["eslint:recommended", "prettier"], // prettier 放最后，覆盖冲突规则
}
```
```json
// .prettierrc
{
"semi": true,
"singleQuote": true,
"printWidth": 80,
"tabWidth": 2,
"trailingComma": "es5"
}
```
## 保存时自动格式化
这是最省心的配置——每次 Ctrl+S 自动格式化 + 修复 lint 错误，不需要手动触发：
```json
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
}
}
```
`formatOnSave` 触发 Prettier 格式化，`source.fixAll.eslint` 触发 ESLint 自动修复——两者顺序是先格式化再 lint 修复，不会冲突。
不想全局开？可以按语言开关：
```json
{
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"[python]": {
"editor.defaultFormatter": "ms-python.black-formatter",
"editor.formatOnSave": true
}
}
```
## 手动格式化快捷键
- Shift+Alt+F：格式化整个文档
- Ctrl+K Ctrl+F：只格式化选中部分
- Ctrl+.：快速修复当前行的 lint 错误
- F8 / Shift+F8：跳到下一个/上一个错误
## 团队统一：配置文件提交到 Git
格式化配置只有在团队成员的编辑器表现一致时才有意义。必须提交到仓库的文件：
- .prettierrc — Prettier 规则
- .eslintrc.js — ESLint 规则
- .editorconfig — 编辑器基础配置（缩进风格、换行符）
再加一个 VS Code 工作区推荐扩展，确保所有人装了 Prettier 插件：
```json
// .vscode/extensions.json
{
"recommendations": ["esbenp.prettier-vscode", "dbaeumer.vscode-eslint"]
}
```
```json
// .vscode/settings.json
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
```
这样 clone 项目后 VS Code 会自动提示安装推荐扩展，打开文件就生效——不需要每个新人手动配置。
## 追问
### Prettier 和 ESLint 冲突了怎么办？
症状是保存后文件在两种格式间反复跳。解法：(1) 确保 "eslint-config-prettier" 已安装且放在 extends 最后；(2) 检查 .eslintrc 里有没有手动写缩进/引号规则——这些应该全部交给 Prettier，ESLint 的 rules 里不要有 indent、quotes、semi 之类的格式规则。
### formatOnSave 导致保存变慢怎么办？
大文件格式化可能要几百毫秒。解决方案：(1) 设 formatOnSaveMode: "modifications" 只格式化修改的行而非整个文件；(2) 确认 Prettier 没有配 rangeIgnore 之外的大段忽略区域（每次都要扫描）；(3) 实在慢就关掉 formatOnSave，改用快捷键手动触发。
### 不同语言怎么用不同格式化器？
用 [语言] 块指定。Python 用 Black，Go 用 gofmt（内置），Rust 用 rustfmt（内置），C/C++ 用 Clang-Format。每个语言配一个 editor.defaultFormatter 和 editor.formatOnSave: true，互不干扰。服务端6月4日 12:44
VS Code 工作区信任怎么用？安全机制和配置详解工作区信任是 VS Code 的安全机制：打开一个你不信任的项目（比如从 GitHub 随便 clone 的仓库）时，限制某些功能执行，防止恶意代码通过自动任务、扩展或调试配置在你电脑上搞事情。
## 怎么工作
打开一个新项目时，VS Code 会弹出提示："你信任这个文件夹里的代码作者吗？"选信任 → 所有功能正常；选不信任 → 部分功能被禁用，状态栏显示黄色盾牌图标。
**不信任时被禁用的功能**：任务自动执行（防止 `.vscode/tasks.json` 里的恶意命令自动跑）、部分扩展不激活（防止扩展读取工作区文件）、调试配置不加载（防止 `launch.json` 执行危险命令）、终端工作目录不自动切换、工作区设置不生效。
说白了：**你不信任的工作区，VS Code 不允许任何"自动执行"行为**——必须你手动触发才行。
## 实际场景
**该信任的**：自己写的项目、公司内部仓库、长期维护的代码库。信任后开发体验不受任何限制。
**不该信任的**：从网上随便下载的代码、别人发来的压缩包、来路不明的 GitHub 仓库。这些项目可能在 `.vscode/tasks.json` 里藏了 `rm -rf /`，或在 `launch.json` 里配了执行恶意脚本的 preLaunchTask。
## 配置速查
```json
{
// 开启工作区信任（默认已开启）
"security.workspace.trust.enabled": true,
// 打开不受信任文件时的行为："open" 直接开 / "newWindow" 新窗口开 / "prompt" 每次问
"security.workspace.trust.untrustedFiles": "open",
// 启动时是否弹出信任提示："always" 每次问 / "once" 只问一次
"security.workspace.trust.startupPrompt": "once"
}
```
觉得弹窗烦？设 `startupPrompt: "once"` 就只问一次，之后记住你的选择。彻底关掉信任功能设 `enabled: false`——但不推荐，等于卸了保险。
## 追问
### 不信任的工作区里怎么手动执行任务？
`Ctrl+Shift+P` → `Tasks: Run Task`，手动选择要运行的任务。不信任只是禁止**自动**执行，手动触发始终可以——VS Code 认为你手动操作代表你知道自己在干什么。
### 信任了一个项目后怎么撤销？
点击状态栏的盾牌图标 → "Manage Workspace Trust" → 切换为不信任。或者 `Ctrl+Shift+P` → "Workspace: Manage Workspace Trust"。撤销后受限功能立即生效，不需要重启。
### 团队协作时信任策略怎么统一？
项目根目录放 `.vscode/settings.json`，但工作区信任设置不在里面——它是用户级别的偏好。团队里能统一的是：确保 `.vscode/` 下的配置文件不包含危险操作（如 `preLaunchTask` 执行 shell 脚本），这样即使新成员信任了工作区也不会触发意外行为。好的实践是把构建命令放在 npm scripts 里而非 tasks.json。服务端6月4日 12:43
VS Code 多编辑器分屏怎么用？高效管理技巧和快捷键详解VS Code 多编辑器管理的核心就三件事：**分屏看多个文件、快速切换焦点、管好标签页别乱**。掌握这几个高频操作比背 50 个快捷键管用。
## 分屏：最常用的三种布局
**左右分屏**（`Ctrl+\`）：最常见的搭配——左边 HTML 右边 CSS，左边接口定义右边实现代码。把当前编辑器一分为二，两边内容一样，之后各自打开不同文件。
**上下分屏**：`Ctrl+K Ctrl+\`，适合日志文件上下对照、或代码+终端同屏。
**拖拽分屏**：直接把标签页拖到编辑区边缘，想放哪放哪——比快捷键更直观，特别适合临时对比两个文件。
布局太多想还原？`View → Editor Layout → Single` 一键回到单栏。
## 焦点切换：键盘不离手
分屏后最烦的就是手离开键盘去点另一边。记住这三个就够：
- `Ctrl+1` / `Ctrl+2` / `Ctrl+3`：跳到第 1/2/3 个编辑器组
- `Ctrl+K Ctrl+←` / `Ctrl+K Ctrl+→`：焦点在编辑器组之间移动
- `Ctrl+Tab`：在最近访问的文件间快速切换（按住 Ctrl 连续按 Tab 选择）
一个高效的工作流：左手 `Ctrl+1/2` 切焦点，右手 `Ctrl+P` 开文件，全程不碰鼠标。
## 标签页管理：别让标签栏变成垃圾场
开 20 个标签找不到文件是常态。几个治本的方法：
**Pin Tab**（右键标签 → Pin）：常驻文件钉住，不会被误关，始终在最左侧。项目入口文件、配置文件钉上，其余随用随关。
**关闭策略**：`Ctrl+W` 关当前标签，`Ctrl+K W` 关除当前外的所有标签。定期清理——不需要的文件立刻关，别攒着。
**限制标签数量**：`workbench.editor.limit.enabled: true` + `workbench.editor.limit.value: 10`，超过 10 个自动关最早的，强制你保持清爽。
## 预览模式：双击 vs 单击的秘密
单击文件资源管理器里的文件，它以"预览"模式打开（标签名斜体）——再单击另一个文件，上一个就被替换了。双击才是"正式打开"，不会被替换。很多人不知道这个机制，觉得"文件莫名其妙消失了"。
如果你希望单击也正式打开，设置 `workbench.editor.enablePreview: false`。但推荐保留预览——它防止你浏览文件时产生大量标签。
## 追问
### 怎么把同一个文件在两个分屏里同时看？
拖标签页到另一侧就能创建同一文件的两个视图。或者用 `View → Editor Layout → Split Right` 后两边打开同一文件。适合看文件头部定义 + 底部实现，或者函数声明 + 调用点对比。滚动是独立的，互不影响。
### 多窗口（多个 VS Code 窗口）和多编辑器组怎么选？
一个项目内的文件对比用编辑器组分屏，跨项目协作用多窗口（`Ctrl+Shift+N` 新窗口 + `Ctrl+R` 切项目）。两个窗口可以分别拖到不同显示器——这才是真正的双屏效率。同一窗口内的分屏再多也只有一个终端面板。
### 怎么快速恢复上次关闭的标签？
`Ctrl+Shift+T` 撤销关闭，和浏览器一样。连续按可以依次恢复最近关闭的多个标签。但注意：VS Code 重启后标签虽然会恢复，未保存的文件如果不小心丢弃了就找不回来了——重要修改随时 `Ctrl+S`。服务端6月2日 01:16
VSCode 扩展怎么开发？从脚手架到发布完整流程开发 VSCode 扩展就是写一个 Node.js 程序，通过 VSCode 提供的 API 注册命令、视图、语言服务等功能。从零到发布，核心步骤：脚手架生成 → 实现功能 → 调试 → 打包发布。
## 环境准备
```bash
npm install -g yo generator-code vsce
```
- `yo` + `generator-code`：官方脚手架，生成扩展项目模板
- `vsce`：打包和发布工具
## 创建扩展
```bash
yo code
```
按提示选择：
- 扩展类型：New Extension (TypeScript) 推荐
- 扩展名、显示名、描述
- 是否初始化 Git 仓库
- 是否用 webpack 打包（推荐选 Yes，打包后体积小很多）
生成的项目结构：
```
my-extension/
├── src/
│ └── extension.ts # 扩展入口
├── package.json # 扩展配置（命令、菜单、激活事件）
├── tsconfig.json
└── .vscode/
├── launch.json # 调试配置（自动生成）
└── tasks.json # 编译任务
```
## 核心概念
**激活事件**：扩展不是启动时就加载，而是按需激活。在 package.json 的 `activationEvents` 里声明何时激活：
```json
"activationEvents": [
"onCommand:myExtension.hello",
"onLanguage:python"
]
```
`onCommand` 在用户执行指定命令时激活，`onLanguage` 在打开特定语言文件时激活。
**入口函数**：extension.ts 导出 `activate` 和 `deactivate` 两个函数：
```typescript
import * as vscode from 'vscode';
export function activate(context: vscode.ExtensionContext) {
let disposable = vscode.commands.registerCommand(
'myExtension.hello', () => {
vscode.window.showInformationMessage('Hello World!');
}
);
context.subscriptions.push(disposable);
}
export function deactivate() {}
```
`registerCommand` 注册命令，命令名必须和 package.json 里声明的对应。`context.subscriptions.push` 确保扩展停用时自动清理资源。
## 注册命令和菜单
package.json 声明命令和快捷键：
```json
"contributes": {
"commands": [
{
"command": "myExtension.hello",
"title": "Say Hello"
}
],
"keybindings": [
{
"command": "myExtension.hello",
"key": "ctrl+shift+h",
"mac": "cmd+shift+h"
}
]
}
```
命令会出现在 Ctrl+Shift+P 命令面板里。
## 调试扩展
按 F5 启动调试——VSCode 会打开一个新的 VSCode 窗口（Extension Development Host），加载你的扩展。在源码里设断点，调试方式和普通 Node.js 程序一样。
修改代码后，在 Extension Development Host 里 Ctrl+R 重载窗口即可生效，不需要重启调试。
## 发布到扩展市场
```bash
# 创建 Publisher（首次）
vsce create-publisher your-publisher-name
# 登录
vsce login your-publisher-name
# 打包发布
vsce publish
```
需要先在 Azure DevOps 创建 Personal Access Token 作为认证凭据。发布后几分钟内就能在 VSCode 扩展市场搜到。
只打包不发布：`vsce package` 生成 .vsix 文件，可以手动安装（`code --install-extension my-extension.vsix`）供内部使用。服务端6月2日 01:16
VSCode 工作区是什么？单文件夹和多根工作区怎么选？VSCode 的"工作区"就是当前打开的项目。最简单的情况——打开一个文件夹就是工作区。多根工作区是同时打开多个文件夹，适合 monorepo 或前后端分离的项目。
## 单文件夹工作区
File > Open Folder 打开一个文件夹，这就是最基本的工作区。VSCode 在这个文件夹下创建 `.vscode/` 目录存放配置（settings.json、launch.json、tasks.json）。
大部分时候用单文件夹就够了。一个项目一个窗口，清爽明了。
## 多根工作区
File > Add Folder to Workspace 可以把另一个文件夹加进来。两个文件夹在侧边栏并列显示，共享同一个窗口。
保存工作区配置：File > Save Workspace As，生成一个 `.code-workspace` 文件：
```json
// project.code-workspace
{
"folders": [
{
"path": "frontend"
},
{
"path": "backend"
},
{
"path": "../shared-lib"
}
],
"settings": {
"editor.formatOnSave": true
}
}
```
`path` 支持相对路径和绝对路径。`../shared-lib` 可以引用上级目录的其他项目。
## 多根工作区的设置继承
多根工作区有三层设置：
1. 全局设置（User）— 所有项目共享
2. 文件夹设置（各 .vscode/settings.json）— 只对各自文件夹生效
3. 工作区设置（.code-workspace 里的 settings）— 对整个工作区生效
优先级：文件夹 > 工作区 > 全局。
关键点：**各文件夹的设置互不影响**。frontend 的 .vscode/settings.json 不会覆盖 backend 的。如果想让两个项目共享设置，写在 .code-workspace 的 settings 里。
## 什么时候需要多根工作区
**需要**：前后端分仓库（frontend/ + backend/），需要同时看两边代码；monorepo 的子项目需要独立配置。
**不需要**：monorepo 根目录已经包含所有子项目（直接打开根目录就行）；偶尔需要看另一个仓库的代码（用 Ctrl+Click 打开新窗口更简单）。
多根工作区的缺点：搜索范围更大（可以限制到特定文件夹）；终端需要切换到对应文件夹才能执行命令；Git 操作需要选择仓库。
## 多根工作区的终端
多根工作区里，终端面板的下拉菜单会显示各文件夹名。选择哪个文件夹就在哪个目录下启动 Shell。也可以在终端里用 `cd` 切换。
## 共享工作区配置
`.code-workspace` 文件可以提交到 Git，团队成员打开就能获得相同的文件夹结构和设置。但注意 path 必须是团队成员都能访问的——如果路径是绝对路径或依赖特定目录结构，别人打开会报错。服务端6月2日 01:15
VSCode 调试怎么配？launch.json 配置和断点调试实战VSCode 的调试器支持 Node.js、Python、C++、Java 等主流语言。核心配置文件是 `.vscode/launch.json`，定义调试的启动方式和参数。
## 最快上手：不用写配置
很多语言不需要手写 launch.json：
- **Node.js**：打开 JS 文件，按 F5，VSCode 自动以当前文件启动调试
- **Python**：装 Python 扩展后，打开 .py 文件按 F5 自动调试
- **HTML**：装 Live Server 扩展，右键 "Open with Live Server" 在浏览器调试
如果自动检测不对，按 F5 后从弹出的环境列表中选择。
## 手动配置 launch.json
需要精细控制时，创建 `.vscode/launch.json`：
```json
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug Server",
"program": "${workspaceFolder}/src/index.ts",
"runtimeArgs": ["--nolazy", "-r", "ts-node/register"],
"env": {
"NODE_ENV": "development"
},
"console": "integratedTerminal"
},
{
"type": "node",
"request": "attach",
"name": "Attach to Process",
"port": 9229,
"restart": true
}
]
}
```
两种 request 模式：
- **launch**：VSCode 启动程序并附加调试器
- **attach**：程序已经在运行，VSCode 附加到进程上调试（适合调试 Docker 容器或远程进程）
## 常用调试操作
| 操作 | 快捷键 | 说明 |
|------|--------|------|
| 开始/继续 | F5 | 启动调试或继续运行到下一个断点 |
| 单步跳过 | F10 | 执行当前行，不进入函数内部 |
| 单步进入 | F11 | 进入函数内部 |
| 单步跳出 | Shift+F11 | 跳出当前函数 |
| 停止 | Shift+F5 | 终止调试 |
| 重启 | Ctrl+Shift+F5 | 重启调试会话 |
## 断点类型
**普通断点**：点击行号左侧的空白区域设置。
**条件断点**：右键行号选 "Add Conditional Breakpoint"，输入条件表达式（如 `i === 50`）。只有条件为 true 时才暂停，调试循环时很有用。
**日志断点**：右键选 "Add Logpoint"，输入日志文本（如 `Current value: {variable}`）。不暂停程序，只在控制台打印——比 console.log 干净，不改代码。
**命中计数断点**：条件断点里设置 hit count（如 `5`），第 5 次执行到才暂停。适合循环中某次迭代出问题的场景。
## 调试面板
暂停时左侧出现三个面板：
- **Variables**：当前作用域的局部变量和全局变量，可以展开对象查看属性
- **Watch**：自定义监视表达式，实时计算值
- **Call Stack**：调用栈，点击任意帧跳转到对应代码位置
Variables 面板可以直接修改变量值——双击数值输入新值，继续运行时会用新值。调试算法逻辑时非常有用。
## 调试远程/容器程序
**Docker 容器**：在 launch.json 里配 attach 模式，指向容器暴露的调试端口：
```json
{
"type": "node",
"request": "attach",
"name": "Docker Attach",
"port": 9229,
"address": "localhost",
"localRoot": "${workspaceFolder}/src",
"remoteRoot": "/app/src",
"restart": true
}
```
`localRoot` 和 `remoteRoot` 做路径映射——VSCode 用本地路径显示代码，但调试器用容器内的路径。`restart: true` 在容器重启后自动重新连接。
## 常见问题
**断点不生效（灰色圆圈）**：代码和编译产物不一致。确保构建后再调试，或配 `preLaunchTask` 自动构建。
**无法 attach 到进程**：目标进程必须以调试模式启动。Node.js 加 `--inspect` 参数，Python 加 `-m debugpy --listen 5678`。
**调试时跳进了 node_modules**：在 launch.json 里加 `"skipFiles": ["<node_internals>/**", "node_modules/**"]`，调试时自动跳过这些文件。服务端6月2日 01:14
VSCode 设置优先级怎么算？全局、工作区和文件夹级别配置覆盖规则VSCode 的设置分三个层级：全局 > 工作区 > 文件夹。优先级从低到高，后者的设置覆盖前者。理解这个层级关系才能避免"明明改了设置为什么不生效"的困惑。
## 三层优先级
| 层级 | 存储位置 | 作用范围 | 优先级 |
|------|----------|----------|--------|
| 全局（User） | ~/.config/Code/User/settings.json | 所有项目 | 最低 |
| 工作区（Workspace） | .vscode/settings.json | 当前工作区 | 中 |
| 文件夹（Folder） | .vscode/settings.json（子目录） | 子目录内的文件 | 最高 |
打开设置面板（Ctrl+,）时，右上角有个标签页切换：User 是全局设置，Workspace 是项目级设置。同一个设置项在两层都有值时，Workspace 的生效。
## 什么时候用哪一层
**全局设置**：和项目无关的个人偏好——字体大小、主题、终端 Shell、编辑器行为。这些你在任何项目里都希望保持一致。
```json
// 全局 settings.json
{
"editor.fontSize": 14,
"editor.tabSize": 4,
"workbench.colorTheme": "One Dark Pro",
"terminal.integrated.defaultProfile.osx": "zsh"
}
```
**工作区设置**：项目特定配置——格式化工具、lint 规则、排除了哪些目录。这些设置应该提交到 Git，让团队所有人一致。
```json
// .vscode/settings.json（项目级）
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"files.watcherExclude": {
"**/node_modules": true,
"**/dist": true
},
"python.defaultInterpreterPath": "./venv/bin/python"
}
```
**文件夹设置**：多根工作区里不同项目需要不同配置时用。比如一个 monorepo 里前端和后端用不同的格式化配置。
## 远程设置的坑
VSCode Remote（SSH/WSL/Container）的设置是独立的两套——本地和远程各自有全局设置。在远程环境打开设置面板改的是远程的全局设置，不是本地的。
如果发现远程环境设置不生效，检查是不是改错了位置：Ctrl+Shift+P 输入 `Preferences: Open Settings`，看标签页是 [Local] 还是 [Remote]。
## 扩展设置的优先级
扩展也可以注册设置项，优先级规则相同。但扩展可以设置 `scope` 限制设置项在哪些层级可用：
- `machine`：只能在全局级别设置（如 Python 解释器路径）
- `window`：工作区级别
- `resource`：文件级别（可以按文件夹覆盖）
如果某个设置项在工作区级别改不了，大概率是扩展把它设成了 `machine` scope。
## 设置冲突排查
"改了设置不生效"的排查步骤：
1. Ctrl+Shift+P 输入 `Developer: Inspect Editor Tokens and Scopes`，看某个设置最终生效的值和来源
2. 在设置面板搜索该设置项，右侧会显示 "Modified in Workspace" 或 "Modified in User"
3. 如果两个地方都改了，点齿轮图标选 "Reset Setting" 清掉不需要的那层服务端6月2日 01:13
VSCode 任务系统怎么用？tasks.json 配置和自动化构建实战VSCode 的任务系统让你把常用命令（构建、测试、部署）绑定为任务，按 Ctrl+Shift+B 直接运行，不用每次手敲终端命令。
## 最简单的任务
```json
// .vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "npm run build"
}
]
}
```
运行：Ctrl+Shift+P 输入 `Tasks: Run Task`，选择 "build"。或者 `Tasks: Run Build Task`（Ctrl+Shift+B）直接运行标记为 build group 的任务。
## 常用任务配置
```json
{
"version": "2.0.0",
"tasks": [
{
"label": "dev",
"type": "shell",
"command": "npm run dev",
"isBackground": true,
"problemMatcher": []
},
{
"label": "build",
"type": "shell",
"command": "npm run build",
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": ["$tsc"]
},
{
"label": "test",
"type": "shell",
"command": "npm test",
"group": {
"kind": "test",
"isDefault": true
}
}
]
}
```
关键配置项：
- `group: "build"`：标记为构建任务，Ctrl+Shift+B 直接触发
- `group: "test"`：标记为测试任务，可以在菜单里一键跑
- `isBackground: true`：后台运行（dev server 这种不会自动退出的命令必须加）
- `problemMatcher`：解析终端输出中的错误，映射到编辑器的 Problems 面板
## problemMatcher：自动捕获错误
`$tsc` 是内置的 TypeScript 编译器匹配器，自动把 `src/main.ts(10,5): error TS2304` 这种输出映射到编辑器的问题面板。
自定义匹配器（捕获 ESLint 错误）：
```json
{
"label": "lint",
"type": "shell",
"command": "npx eslint src/",
"problemMatcher": {
"owner": "eslint",
"fileLocation": "relative",
"pattern": {
"regexp": "^(.+):(\d+):(\d+)\s+-\s+(.+)$",
"file": 1,
"line": 2,
"column": 3,
"message": 4
}
}
}
```
正则捕获的文件名、行号、列号映射到编辑器，点击错误直接跳转。
## 任务间依赖
多个任务按顺序执行：
```json
{
"label": "deploy",
"dependsOn": ["build", "test"],
"dependsOrder": "sequence"
}
```
`dependsOrder: "sequence"` 串行执行（先 build 再 test），不加则是并行。
## 输入变量
任务支持变量替换，不用硬编码路径：
```json
{
"label": "run current file",
"type": "shell",
"command": "python ${file}"
}
```
常用变量：`${file}`（当前文件）、`${workspaceFolder}`（项目根目录）、`${fileBasenameNoExtension}`（文件名不含后缀）。
## preLaunchTask：调试前自动跑任务
在 launch.json 里配 `preLaunchTask`，按 F5 调试时自动先跑构建任务：
```json
// .vscode/launch.json
{
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/dist/index.js",
"preLaunchTask": "build"
}
]
}
```
这样调试时不会遇到"代码改了但跑的是旧构建"的问题。服务端6月2日 00:06
VSCode 怎么用 Git？内置 Git 功能和常见操作图文指南VSCode 内置了 Git 支持，日常的 commit、diff、branch、merge、resolve conflict 都不用离开编辑器。不装任何扩展就能用，大部分情况下不需要命令行。
## 基本操作
### 查看变更
左侧栏的 Source Control 图标（分支形状）显示当前仓库状态。点击后能看到所有已修改文件，点击文件名查看 diff（左右对照显示新增/删除的行）。
### 暂存和提交
- 点击文件旁的 + 号暂存（相当于 git add）
- 点击 - 号取消暂存（相当于 git reset HEAD）
- 在输入框写 commit message，按 Ctrl+Enter 提交
比命令行快的地方：可以部分暂存——在 diff 视图里选中几行右键 "Stage Selected Ranges"，只提交某几行改动而不是整个文件。
### 撤销修改
文件旁的回退箭头图标撤销所有未暂存的修改（git checkout）。如果已经暂存了，先取消暂存再撤销。
## 分支管理
左下角状态栏显示当前分支名。点击分支名弹出分支列表：
- 切换到已有分支
- 创建新分支（从当前分支或指定分支创建）
- 删除分支
合并分支：Ctrl+Shift+P 输入 `Git: Merge Branch`，选择要合并进来的分支。如果有冲突，VSCode 会标记冲突文件。
## 解决冲突
冲突文件会在编辑器里显示三段内容：
- `Current Change`（当前分支的版本）
- `Incoming Change`（要合并进来的版本）
- 上方有四个按钮：Accept Current / Accept Incoming / Accept Both / Compare
点击按钮选择保留哪个版本，或者手动编辑合并后的内容。解决所有冲突后保存文件，暂存并提交。
VSCode 的冲突解决界面比 git mergetool 直观很多——两个版本左右对照，选中哪边一目了然。
## 查看历史
内置功能比较有限：只能看文件的行级别 blame（鼠标悬停在某行显示最后修改的 commit）。要看完整历史，装 GitLens 扩展——显示每一行的修改者、时间、commit 信息，还能看文件的历史版本和 diff。
## .gitignore 支持
创建 .gitignore 文件后，VSCode 自动忽略匹配的文件。已跟踪的文件如果加入 .gitignore 不会自动取消跟踪，需要先 `git rm --cached`。
忽略文件但不想提交 .gitignore：用全局 gitignore（`git config --global core.excludesFile ~/.gitignore_global`）。
## 常见问题
**Source Control 面板不显示**：打开的文件夹不是 Git 仓库。Ctrl+Shift+P 输入 `Git: Initialize Repository` 初始化，或者 `Git: Clone` 克隆远程仓库。
**文件修改后没有变化标记**：可能是文件编码问题或 .gitignore 规则意外匹配。检查 `git status` 在终端里是否正常。
**提交时 husky/pre-commit hook 报错**：VSCode 的 Git 集成调用的是系统 git，hook 正常运行。但如果 hook 依赖环境变量（如 PATH 中的 node），VSCode 可能找不到。从终端启动 VSCode（`code .`）可以继承终端的环境变量。服务端6月2日 00:05
VSCode 太卡怎么办？5 个有效的性能优化方法VSCode 变卡通常是因为扩展太多、大文件处理、或 TypeScript 语言服务过载。按优先级排查：禁用扩展 → 排除大文件夹 → 调整 TypeScript 配置。
## 1. 禁用不需要的扩展
扩展是 VSCode 卡顿的头号原因。每个扩展都会在后台运行，有些还监听所有文件变化。
**快速定位问题扩展**：按 Ctrl+Shift+P 输入 `Developer: Show Running Extensions`，看哪些扩展占用 CPU 高。
**按工作区禁用**：不需要全局禁用。在扩展面板右键选 "Disable (Workspace)"，只对当前项目禁用。比如前端项目不需要 C++ 扩展，Python 项目不需要 Java 扩展。
**高危扩展**：这些类型的扩展特别吃性能：
- 实时 lint/formatter（ESLint、Prettier 在每次保存时运行）
- 代码分析工具（SonarLint 扫描整个项目）
- 主题/图标包（某些实现不好的会拖慢渲染）
## 2. 大项目排除不需要的文件夹
打开大项目（node_modules 几百 MB、dist 目录几万文件）时，VSCode 的文件监控会卡住。
```json
// settings.json
{
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/**": true,
"**/dist/**": true,
"**/.next/**": true,
"**/build/**": true
},
"files.exclude": {
"**/.git": true,
"**/node_modules": true,
"**/dist": true
}
}
```
`watcherExclude` 停止文件监控（省 CPU），`exclude` 从文件树隐藏（省渲染）。两者配合效果最好。改完之后可能需要 `Developer: Reload Window` 重新加载。
## 3. TypeScript/JavaScript 语言服务优化
TypeScript 语言服务是 VSCode CPU 占用的大户——它要分析整个项目的类型关系。
```json
// settings.json
{
"typescript.tsserver.maxTsServerMemory": 4096,
"js/ts.implicitProjectConfig.checkJs": false,
"typescript.preferences.importModuleSpecifier": "relative"
}
```
`maxTsServerMemory: 4096` 给 TS 服务器更多内存，避免大项目 OOM 崩溃重启（反复重启本身就是卡顿原因）。如果不做 JS/TS 开发，可以直接禁用内置 TypeScript 扩展。
## 4. 关闭不必要的功能
```json
// settings.json
{
"editor.minimap.enabled": false,
"editor.renderWhitespace": "none",
"editor.quickSuggestionsDelay": 200,
"workbench.editor.enablePreview": true,
"telemetry.telemetryLevel": "off"
}
```
- **minimap**：大文件时 minimap 渲染开销不小，关掉立竿见影
- **renderWhitespace**：显示空白字符需要额外渲染
- **enablePreview**：单击文件只预览不打开新标签页，减少标签页数量
## 5. 大文件用其他编辑器
VSCode 对超过 10MB 的文件力不从心——语法高亮变慢、滚动卡顿、内存飙升。这是架构决定的（VSCode 用 TextBuffer 而非传统的行数组）。
处理大文件的建议：
- 日志文件：用 `less` 命令或 Dedicated Log Viewer
- 大 JSON/CSV：用专项工具（jq、bat）
- 超大代码文件：拆分文件才是根本解
```json
// settings.json
{
"files.maxMemoryForLargeFilesMB": 4096
}
```
提高大文件内存上限，但不治本——文件太大时该卡还是卡。
## 检查当前性能
按 Ctrl+Shift+P 输入 `Developer: Open Process Explorer`，看每个进程的 CPU 和内存占用。如果某个扩展进程持续占用 CPU，就是问题根源。服务端6月2日 00:05
VSCode 主题怎么换？配色方案、图标主题和自定义颜色 token 详解VSCode 主题分两种：颜色主题（编辑器配色）和文件图标主题（资源管理器图标）。想更深入，还可以通过 color customization 精细控制每个 UI 元素的颜色。
## 安装主题
扩展市场里有上千个主题。Ctrl+Shift+X 打开扩展面板，搜索 "theme" 就能找到。几个口碑好的：
- **One Dark Pro**：Atom 风格暗色主题，下载量最高之一
- **Dracula**：经典暗色，跨编辑器统一风格
- **GitHub Theme**：GitHub 官方亮色/暗色主题
- **Catppuccin**：柔和的暖色调暗色主题，2024-2025 年热度上升很快
- **Tokyo Night**：偏蓝调暗色主题，和 One Dark Pro 风格接近但更素
装完主题后切换：Ctrl+K Ctrl+T，从列表中选择。
## 文件图标主题
图标主题控制侧边栏文件树里的图标样式：
- **Material Icon Theme**：Google Material 风格，覆盖文件类型最全
- **vscode-icons**：VSCode 官方团队出品，辨识度高
切换图标主题：Ctrl+Shift+P 输入 `File Icon Theme`，从列表中选择。图标主题和颜色主题独立，可以混搭。
## 精细自定义：覆盖特定颜色
装了主题但想改几个颜色？不用从零写主题，用 `workbench.colorCustomizations` 覆盖：
```json
// settings.json
{
"workbench.colorCustomizations": {
"editor.background": "#1a1b26",
"editor.foreground": "#a9b1d6",
"editorCursor.foreground": "#c0caf5",
"editor.selectionBackground": "#33467c",
"editor.lineHighlightBackground": "#1f2335",
"sideBar.background": "#16161e",
"activityBar.background": "#16161e"
}
}
```
这样只改你关心的几个颜色，主题的其他部分保持不变。比从零写主题简单得多。
## 自定义语法高亮颜色
语法高亮的颜色由 TextMate token 控制，可以通过 `editor.tokenColorCustomizations` 覆盖：
```json
// settings.json
{
"editor.tokenColorCustomizations": {
"textMateRules": [
{
"scope": "keyword",
"settings": {
"foreground": "#bb9af7",
"fontStyle": "bold"
}
},
{
"scope": ["comment", "punctuation.definition.comment"],
"settings": {
"foreground": "#565f89",
"fontStyle": "italic"
}
},
{
"scope": "string",
"settings": {
"foreground": "#9ece6a"
}
}
]
}
}
```
常见 scope：`keyword`（关键字）、`string`（字符串）、`comment`（注释）、`function`（函数名）、`variable`（变量名）、`number`（数字）。
## 按项目设置不同主题
每个项目可以用不同的主题——工作项目用暗色，个人项目用亮色：
```json
// .vscode/settings.json（项目级别）
{
"workbench.colorCustomizations": {
"[One Dark Pro]": {
"editor.background": "#1e1e2e"
},
"[GitHub Dark]": {
"editor.background": "#0d1117"
}
}
}
```
`[主题名]` 语法让定制只在特定主题下生效。
## 创建自己的主题扩展
如果改动太多，不如直接打包成主题扩展分享。用 Yoeman 脚手架生成：
```bash
npm install -g yo generator-code
yo code
# 选择 "New Color Theme"
```
生成的项目里有一个 JSON 文件定义所有颜色。改完后 `vsce publish` 发布到扩展市场。服务端6月2日 00:04
VSCode 快捷键怎么改？自定义键绑定和多快捷键方案切换VSCode 的快捷键可以完全自定义，还能装不同平台的键位方案（Vim、Sublime、IntelliJ）让肌肉记忆无缝迁移。
## 查看和搜索快捷键
Ctrl+K Ctrl+S 打开快捷键设置面板。在这里可以：
- 搜索命令名或快捷键组合
- 修改任意命令的绑定
- 查看冲突（同一个快捷键绑定了多个命令）
搜索框里输入命令名（如 "format"）或快捷键组合（先按 Ctrl+K 再按要搜索的键），快速定位。
## 修改快捷键
两种方式：
**方式一：面板里直接改**。在快捷键面板里找到命令，双击或右键选 "Change Keybinding"，按下新快捷键组合。
**方式二：编辑 keybindings.json**。点击快捷键面板右上角的文件图标，打开 JSON 配置：
```json
// keybindings.json
[
{
"key": "ctrl+shift+f",
"command": "editor.action.formatDocument",
"when": "editorHasDocumentFormattingProvider && editorTextFocus"
},
{
"key": "ctrl+d",
"command": "editor.action.copyLinesDownAction",
"when": "editorTextFocus"
},
{
"key": "ctrl+shift+d",
"command": "workbench.view.debug"
}
]
```
`when` 条件控制快捷键在什么上下文生效——`editorTextFocus` 只在编辑器有焦点时生效，避免全局快捷键和终端冲突。
## 常用快捷键调整建议
**格式化代码**：默认 Shift+Alt+F，很多人改成 Ctrl+Shift+F 或 Ctrl+S 时自动格式化（配合 `editor.formatOnSave: true`）。
**复制当前行**：默认 Shift+Alt+Down，改成 Ctrl+D 更顺手（但 Ctrl+D 默认是"添加下一个选中"，改之前想清楚）。
**删除当前行**：默认 Ctrl+Shift+K，可以改成 Ctrl+Shift+D 或其他顺手的组合。
**切换终端**：Ctrl+` 比较远，可以加一组 Ctrl+J。
## 装其他编辑器的键位方案
不想一个个改？装键位扩展一键迁移：
- **Vim**：装 "VSCode Vim" 扩展，完整的 Vim 键位模拟
- **Sublime Text**：装 "Sublime Text Keymap" 扩展
- **IntelliJ IDEA**：装 "IntelliJ IDEA Keybindings" 扩展
- **Emacs**：装 "Emacs Friendly Keymap" 扩展
装完扩展后，Ctrl+K Ctrl+S 面板里会显示对应编辑器的键位方案，可以和默认方案混用。
## when 条件常用值
`when` 是快捷键自定义的关键——它决定快捷键在什么场景下生效：
| when 值 | 含义 |
|---------|------|
| `editorTextFocus` | 编辑器有焦点 |
| `terminalFocus` | 终端有焦点 |
| `resourceLangId == 'python'` | 当前文件是 Python |
| `editorHasSelection` | 有选中文本 |
| `inDebugMode` | 调试模式中 |
组合条件用 `&&` 连接：`editorTextFocus && resourceLangId == 'python'` 表示只在编辑 Python 文件时生效。
## 导出和同步快捷键
VSCode Settings Sync（登录 GitHub 或 Microsoft 账号）自动同步快捷键配置到云端，换电脑不用重新配置。如果不想用云同步，手动复制 keybindings.json 文件也行。服务端6月2日 00:04
VSCode 内置终端怎么用？分屏、多终端和配置技巧VSCode 内置终端省去了在编辑器和终端窗口之间来回切换的麻烦。Ctrl+` 一键打开，和编辑器共享同一个窗口，代码和命令行并排操作。
## 基本操作
- **打开/关闭终端**：Ctrl+`（反引号）或 View > Terminal
- **新建终端**：终端面板右上角的 + 号，或 Ctrl+Shift+`
- **拆分终端**：终端面板右上角的拆分图标，或 Ctrl+Shift+5，在同一个终端面板里左右分屏
- **切换终端**：终端面板右上角的下拉菜单选择，或 Ctrl+PageUp/PageDown
拆分终端比新建标签页更实用——可以同时看着两个终端的输出，比如左边跑服务、右边看日志。
## 终端类型选择
VSCode 会自动检测系统上安装的 Shell：
- **macOS**：默认 zsh（Catalina 及以后），也可以选 bash
- **Linux**：默认 bash，也可以选 zsh/fish
- **Windows**：默认 PowerShell，也可以选 CMD 或 Git Bash
手动选择默认终端：Ctrl+Shift+P 输入 `Terminal: Select Default Profile`，从列表中选择。
指定特定终端：`terminal.integrated.defaultProfile.osx/linux/windows` 按平台设置。
## 终端配置技巧
```json
// settings.json
{
"terminal.integrated.fontSize": 14,
"terminal.integrated.cursorStyle": "line",
"terminal.integrated.scrollback": 5000,
"terminal.integrated.copyOnSelection": true
}
```
`scrollback: 5000` 把回滚缓冲区从默认 1000 行增加到 5000 行，跑大量日志时不会丢失前面的输出。`copyOnSelection` 选中即复制，不用再 Ctrl+C。
## 终端里的代码操作
**右键在终端中打开文件**：如果终端输出了文件路径（比如编译错误 `src/main.js:10:5`），按住 Ctrl/Cmd 点击路径可以直接跳转到对应文件的对应行。
**选中终端文本**：和普通终端不同，VSCode 终端选中文字不需要进入复制模式——直接鼠标拖选就行。
**运行选中代码**：选中一段代码后，按 Shift+Enter 或右键选择 `Run Selection in Python Terminal`（需要 Python 扩展），代码直接在终端里执行。调试小段代码非常方便。
## 任务运行器
把常用命令绑定到任务里，不用每次手敲：
```json
// .vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "npm run build",
"group": "build",
"problemMatcher": ["$tsc"]
},
{
"label": "dev",
"type": "shell",
"command": "npm run dev",
"isBackground": true,
"group": "none"
}
]
}
```
Ctrl+Shift+P 输入 `Tasks: Run Task` 选择运行。`problemMatcher` 自动解析终端输出中的错误，标记到编辑器的 Problems 面板。
## 常见问题
**终端字体乱码**：Powerline 主题的特殊符号需要安装 Nerd Font。在设置里指定 `terminal.integrated.fontFamily` 为已安装的 Nerd Font 名称。
**终端启动慢**：可能是 Shell 配置文件（.zshrc/.bashrc）加载太多东西。在终端里跑 `time zsh -i -c exit` 看启动耗时，超过 1 秒就该优化了。
**终端里 vim/nano 不能用**：VSCode 终端不支持交互式程序的鼠标事件。如果需要在编辑器里用 vim，装 VSCode Vim 扩展而不是在终端里跑 vim。