VS Code Agents 窗口会话布局控制器Layout Controller解析按会话捕获、恢复与持久化工作台布局的状态机规范【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode本规范解读基于本仓库src/vs/sessions模块下的布局控制器Layout Controller设计文档与实现。VS Code 的 Agents 窗口在同一个工作台中允许多个会话session之间切换每个会话都保留自己的一套布局记忆——底部面板开没开、辅助栏侧边栏显示 Files 还是 Changes、编辑器里打开了哪些文件。本文以 LAYOUT_CONTROLLER.md 为骨架对照 baseSessionLayoutController.md、desktopSessionLayoutController.md、mobileSessionLayoutController.md 三份文件级规范及对应实现系统说明按会话记忆布局的状态机规则、存储键与触发链。读完本文你将能理解B1–B6、D1–D11、M1–M2这些规则标签背后的行为契约、底层 Observable 驱动模型以及切换会话时辅助栏、面板、编辑器工作集各自如何被捕获和恢复。1. 文档定位一份规范而非实现流水账首先需要理解LAYOUT_CONTROLLER.md是一份行为规格说明书specification而不是实现笔记。它的开篇就声明了规范变更门禁Specification change gate如果一个 bug 修复只是在恢复一条已经存在的规则那么它应该属于回归测试而不是本文档。只有当你刻意改变布局状态机或持久化契约时才允许更新本规范。这意味着每一条用户可感知的行为都落成一条带稳定编号的场景规则scenario rule代码与测试通过规则标签互相引用而怎么实现则被隔离在每份文件级规范末尾的 Implementation notes 小节里。规则标签的编号不表示执行顺序只作为稳定的引用锚点。整份控制器规范分布在四层层次文件说明主规范LAYOUT_CONTROLLER.md会话布局控制器的总纲职责划分、状态清单、触发机制、持久化与关键不变量基础控制器baseSessionLayoutController.md对应BaseLayoutController实现见 baseSessionLayoutController.ts规则B1–B6桌面/Web 桌面控制器desktopSessionLayoutController.md对应LayoutController实现见 desktopSessionLayoutController.ts规则D1–D11移动端Web 手机版控制器mobileSessionLayoutController.md对应MobileLayoutController实现见 mobileSessionLayoutController.ts规则M1–M2在 LAYOUT.md 的 Layout-controller boundary 一节中定义了边界布局控制器只负责把会话被激活翻译成部件的捕获与恢复capture and restore不拥有会话身份、也不持有可见会话模型。LAYOUT_CONTROLLER.md正是这份边界说明的详细配套文档detailed companion。2. 模块地图谁管什么控制器体系被刻意拆成平台无关的公共机制 平台差异的扩展点抽象的BaseLayoutController拥有与平台无关的机制面板panel、编辑器工作集editor working set、持久化、多会话抑制multi-session suppression。LayoutController桌面 / Web 桌面在基类之上增加**辅助栏auxiliary bar / side pane**的管理MobileLayoutControllerWeb 手机版则故意省略辅助栏管理——窄视口下没有空间给自动展开的副栏。SinglePaneLayoutController是LayoutController的兄弟类它也继承BaseLayoutController但为 New / Existing / Quick Chat 三种会话组合出三条生命周期策略strategy。共享的 tab、detail 与可见性机制放在**协调器coordinator**里而不是做成独立的 contribution 控制器。单栏策略必须留在该控制器、它的策略或协调器中不允许注入到 editor-part 的构造流程里——尤其是 editor-part 构造不得获取ISessionsService因为 Sessions 服务的依赖图本身已经依赖了 editor parts。负责按平台贡献正确控制器的是 sessions.layout.contribution.ts桌面与 Web 桌面布局即!(isWeb isMobile)注册LayoutControllerWeb 手机布局注册MobileLayoutController。该文件还会注册实验性的响应式侧栏设置项。它被桌面入口 sessions.desktop.main.ts 与 Web 入口 sessions.web.main.ts 分别 import。2.1 每种布局各记住什么状态清单Agents 窗口始终只维持一个活动会话active session但允许用户在多个会话之间来回移动每个会话拥有自己的编辑器工作集。经典布局额外按会话记住底部面板可见性、辅助栏与编辑器部件的可见性单栏布局则把面板的可见性提升到工作台级别与侧栏一致持久化在workbench.ts里只按会话记住面板曾经显示的是哪个视图另外为 Existing Sessions 维护一份共享的 Editor/Details 配置档New Sessions 则使用一次性Editor 打开规则。LayoutController持有按会话资源sessionURI为键、持久化到 workspace 存储的状态。把原规范中的状态清单翻译成表状态存储映射作用域辅助栏次要侧栏_viewStateBySession仅经典布局可见性 活动视图容器面板可见性终端 / 调试输出_panelVisibilityBySession仅经典布局只有可见性。单栏布局改为在工作台级别治理面板可见性面板视图_panelViewBySession仅单栏布局面板最后显示的 pane composite默认回退 Terminal编辑器工作集_workingSetsgrid editor part 中打开的编辑器编辑器部件可见性_editorPartHiddenBySession仅经典布局编辑器部件是否曾被留在隐藏状态在源码 baseSessionLayoutController.ts 中可以确认这些持久化字段与存储键的真实命名——ISessionLayoutEntry携带panelViewContainerId?: string而顶层存储键是const SESSION_LAYOUT_STATE_KEY sessions.layoutState。3. 切换触发器一切状态都从 Observable 流出原规范最强调的一条架构纪律是所有状态都从activeSession这个 observable 流出绝不用事件驱动控制流。控制器由此派生derive出activeSessionResourceObs按资源相等去重activeSessionIsCreatedObsactiveSessionHasWorkspaceObsmultipleSessionsVisibleObs然后用autorun对这些派生量做反应。每次同步都是一次读取activeSessionResourceObs的autorun控制器内部维护局部变量previousSessionResource用来区分真正的切换previous ! active与初始加载 / 无关的重评估。3.1 多会话同时可见时的抑制当 Sessions Part 网格里同时显示多个会话视图时所有按会话的同步都会被抑制辅助栏 / 面板同步的 autorun 会因multipleSessionsVisibleObs提前退出一个专门的 autorun 会为每个可见会话清空_viewStateBySession与_panelVisibilityBySession。这样保证当用户收缩回单会话时默认可见性逻辑见下文 D3 恢复优先级会重新运行而不是恢复一套已经过期的单会话状态。编辑器工作集不会被清空——它们在多会话模式下存活。这条规则对应的正是B5多会话时面板恢复暂停、记忆状态被丢弃但已打开的编辑器仍被保留。4. 辅助栏Auxiliary Bar / Side PaneD1–D11 的状态机辅助栏管理是桌面控制器区别于移动控制器的地方在移动 WebisWeb isMobile上整段被跳过以避免在窄视口上出现破坏性的自动展开。以下把 D 系规则的完整语义逐条展开。4.1 离开会话时捕获D1_captureViewState(previousSession)为即将离开的会话记录auxiliaryBarVisible—— 辅助栏当前是否可见auxiliaryBarActiveViewContainerId—— 辅助栏当前活动视图容器Files 还是 Changes。4.2 切入会话时恢复——严格优先级D3_syncAuxiliaryBarVisibility(resource, hasWorkspace, isCreated)按严格优先级套用状态无资源 / 无工作区→ 什么都不做D3a。未创建会话新会话视图→ 所有未创建会话共享同一个状态对象_newSessionViewState持久化到 workspace 存储键sessions.newSessionViewState见第 7 节。如果用户曾在某个新会话上显式隐藏辅助栏那么它保持隐藏跨切换和重载都有效否则显示默认容器第 4 步。这是侧边栏自动打开的主要场景——新会话默认打开它让用户一开始就能看到 FilesD3b。已创建会话→ 侧边栏永远不会被自动打开唯一的例外是同一会话的 submit 转换D4已保存状态是隐藏、或根本没有保存状态→ 隐藏辅助栏并停止。一个没有显式可见选择的会话——包括刚从新会话视图转换成既有会话的——保持关闭直到用户手动打开。已保存状态是可见且活动容器仍被 pin 住 → 重新打开该容器。已保存状态是可见但其容器已不存在 → 回退到默认容器第 4 步D3c。默认容器_defaultAuxiliaryBarContainerId/_openDefaultAuxiliaryBarContainer仅在侧边栏确实要显示时使用新会话默认、或恢复用户显式留在可见状态的会话时会话在其任一 chat 中产生过至少一次文件变更sessionHasChanges→ 打开 Changes 视图CHANGES_VIEW_ID否则 → 打开 Files 容器若 Files 被隐藏则回退到 Changes。变更状态是untracked读取的因此只在侧边栏被打开的那一瞬间求值D3d。4.3 新会话提交D4当活动新会话变成 created同一会话的isCreated从 false 变 true或 provider 用新的 committed 资源替换掉草稿时侧边栏停在用户离开它时的状态可见就保持当前容器隐藏就不为它记录活动容器之后打开侧边栏时按当时会话的变更状态走默认容器D3d。在单栏模式下submit 转换同样保持编辑器内容关闭被管理的 Changes 标签在编辑器自动可见性抑制下打开而可见的侧边栏映射到 Changes detail。4.4 变更到达时绝不自动揭示D6当一轮 chat 产生新的文件变更时侧边栏不会被揭示活动容器也不会被切换。第一次变更确实会把 Changes 设为默认容器D3d但那只在下一次侧边栏被打开时才生效——一个已经可见的侧边栏永远不会在用户眼皮底下被换走。4.5 实时可见性跟踪D2辅助栏可见性不仅会在会话切换时被记录还会通过AUXILIARYBAR_PART的onDidChangePartVisibility监听器做实时跟踪移动 Web 与多会话可见时跳过对于有标题的活动会话重跑_captureViewState对于未创建的活动会话更新共享的_newSessionViewState当一个隐藏保存状态的已创建会话被打开时先恢复已保存 / 默认的活动容器再捕获可见状态——这样提交时隐藏的会话会打开到其变更状态对应的默认容器D3d。跟踪被挂起的场景包括多会话可见、编辑器最大化D5、_togglingSidePane置位整片侧边栏 toggleD9、以及_hidingAuxiliaryBarForRestore置位恢复驱动的隐藏经由_hideAuxiliaryBarForRestore走永远不会被当作一次新的用户选择记下来。4.6 会话切换时的编辑器揭示当一个会话的编辑器工作集在会话切换时被恢复编辑器部件会被程序化揭示_revealEditorPartForWorkingSet见第 5 节——除非该会话当时把编辑器部件留在了隐藏状态。每个会话的编辑器隐藏态由[B2]的onDidChangePartVisibility(EDITOR_PART)监听器在用户改变它的瞬间急切捕获写入_editorPartHiddenBySession——前提是单会话可见、且不在会话切换恢复流程_isRestoringSessionLayout中。规范特别解释了为什么必须在切换发生时同步捕获而不是到切换离开时才惰性捕获惰性捕获会与切换的 deriveactiveSessionForWorkingSet落后于原始的 active session竞争导致即将进入的会话的布局覆盖掉即将离开的会话的值。编辑器部件曾被隐藏例如关闭 Side Panel它会同时隐藏辅助栏和编辑器部件、但保留已打开的编辑器的会话恢复时保持编辑器隐藏在单栏模式下还会被主动重新隐藏_shouldHideEditorPartOnApply避免从编辑器开着的会话返回时留下可见编辑器。重载后的首次恢复见 §5.2不会揭示编辑器——保留工作台已恢复的编辑器部件可见性。其他情况下编辑器部件可见性跟随编辑器开/关事件以及用户对 chevron 的显式切换。单栏模式禁用这套按会话的编辑器可见性捕获/套用编辑器与 detail 可见性保持不变只恢复新进入会话的编辑器工作集。4.7 空的辅助栏自动隐藏D10只要辅助栏没有活动视图容器它的部件就会被隐藏。典型场景是没有工作区的 Quick Chat此时 Changes 与 Files 容器被各自的when子句挡掉辅助栏会变成一列空白。_hasActiveAuxViewContainers()基类通过IViewDescriptorService.getViewContainersByLocation(AuxiliaryBar)加IViewsService.isViewContainerActive来统计活动容器——这与工作台本身的判定规则一致!hideIfEmpty || activeViewDescriptors.length 0。_registerAuxiliaryBarPartVisibility桌面控制器对它做响应式重查容器新增/移除、位置迁移、每个容器模型的onDidChangeActiveViewDescriptorswhen门控信号、辅助栏onDidChangeViewContainerVisibility以及辅助栏部件本身变为可见onDidChangePartVisibility。部件可见这个触发源补上了一个缺口部件可能在不触发任何容器/描述符变更信号的情况下变可见——比如裸 detail toggle先显示列、容器随后才打开或一次恢复把列显示出来而其容器仍被门控。若不处理toggle / 上下文键就会在空面板上方显示开。空部件隐藏运行在suppressEditorPartAutoVisibility()之下确保协调掉一个空列不会作为副作用把编辑器弹开编辑器可见性仍由 D3/D8 治理。该逻辑只隐藏一旦容器再次变得活动正常恢复规则D3/D8就会揭示部件。对称地docked hostsetAuxiliaryBarHidden在辅助栏显示时永远不会强开一个没有活动视图的hideIfEmpty容器因此一次 show 绝不可能呈现空白 docked 面板。两条合起来保证了不变量在单栏 docked 模式下partVisibility.auxiliaryBar⇒AuxiliaryBarVisibleContext⇒ detail toggle为真当且仅当 docked detail 面板确实渲染着一个活动视图容器。另外Toggle Side Panel命令对 Quick Chat 是直接禁用的precondition: IsQuickChatSessionContext.negate()——因为 Quick Chat 根本没有侧边栏可切换。4.8 Toggle Side Panel 的完整生命周期Workbench.toggleSidePane()会先发出onWillToggleSidePane再发出一次完成的onDidToggleSidePane({ before, after })每次状态里都包含{ editor, auxiliaryBar }。该方法返回监听器运行后实际最终可见性。命令直接调用这个布局操作。BaseLayoutController从 will 事件置位_togglingSidePanedid 事件提供{ before, after }因此折叠/重开的记录只会在转换完成后进行、且仍持有 toggle 前的辅助栏可见性。在全关 → 可见的转换中共享的onDidRevealSidePane事件在两个部件都落定后只触发一次控制器隐藏任何被揭示但无内容的部件did-toggle 监听器随后记录过滤后的结果并清除标志位。工作台本身记住/恢复原始的编辑器与辅助栏可见性并通过_defaultSidePaneState持有每种布局的默认值。4.9 补充细节Sidebar 响应式折叠D7、编辑器最大化D5与单栏 Files-only 新会话D11D5 最大化编辑器最大化期间侧边栏一律显示 Changes无论会话记忆如何该强制状态不被记录D2 被挂起因此取消最大化会恢复会话真实状态、编辑器也回到之前的宽度。Sessions 工作台的setEditorMaximized会在最大化时对编辑器尺寸 周边部件可见性做快照、取消时还原。D7 响应式 Sessions 侧栏窗口小主容器宽度 ≤ 1800pxSMALL_WINDOW_MAX_WIDTH且编辑器与侧边栏同时打开时sessions 侧栏自动隐藏任一关闭或窗口变大后恢复。用户自己关过侧栏则不自动重开。整个行为由实验设置sessions.layout.autoCollapseSessionsSidebar门控非 stable 构建默认开、stable 默认关。单栏模式下该机制被替换成显式 details规则只有用户通过workbench.action.toggleAuxiliaryBarToggle Details打开详情面板时才自动隐藏侧栏。D11 单栏新会话视图是 Files-only在单栏 detail 模式下未创建的工作区会话视图处于活动状态时编辑器内容默认隐藏只保留编辑器 tab 栏与 Files detail 面板。隐藏是转换触发的编辑器刚变可见或刚进入该视图且编辑器已可见时隐藏且仅在活动编辑器不是真实内容时被管理的空 tab 或无编辑器。用户显式揭示优先打开文件会先揭示编辑器再让它成为活动编辑器切换 detail 关闭会揭示空编辑器以免侧边栏整个消失。5. 面板PanelB1 与 B6 是一对互斥的取舍面板管理的关键洞见是每种布局只能在按会话记忆可见性与按会话记忆视图中二选一_isPanelVisibilityPerSession一个布尔门控两个方向单栏通过 false一键翻转。5.1 经典布局——可见性按会话B1_syncPanelVisibility(resource)无活动会话 → 隐藏面板否则恢复_panelVisibilityBySession.get(resource)无记录时默认隐藏。每次用户 toggle 面板时PANEL_PART的onDidChangePartVisibility监听器都会为活动会话写入新可见性多会话可见时抑制。面板高度是全局工作台状态不属于按会话布局状态。当 Quick Chat 隐藏侧边栏后返回时先恢复面板、再揭示单栏 Editor那次 Editor 揭示必须保持面板当前高度否则 grid 重新分配会把面板压到最小。5.2 单栏布局——可见性归工作台视图按会话B6单栏把_isPanelVisibilityPerSession设为false这个单一门控就是 B1 的逆操作面板的可见性不再按会话——它归工作台所有和侧边栏一样持久化在workbench.ts中与其它部件并列_applyPersistedPartVisibility/_savePartVisibility在setPanelHidden时保存基类改为在_panelViewBySession里按会话记住面板最后显示的视图pane composite来源是IPaneCompositePartService.onDidPaneCompositeOpen_syncPanelView(resource)在会话切换时、以及面板被揭示时恢复它——但只在面板已经可见时因此恢复视图永远不会强开面板无记忆视图的会话回退到TERMINAL_VIEW_ID即终端该视图按会话持久化为panelViewContainerId在 draft → committed 的 submit 中draft 记住的视图会被复制给 committed 资源_onSessionReplaced。6. 编辑器工作集Editor Working SetsB2 的完整生命周期工作集机制始终激活与workbench.editor.useModal无关即使在useModal: all把所有编辑器都强制成 modal 的模式下browser 编辑器依然会停靠进共享的 grid editor part它们把自己排除在 modal part 之外所以这些 tab 仍然需要按会话的捕获/恢复。_useModalConfigObs只在_applyWorkingSet内部被读取用来决定切换时是否自动揭示编辑器部件modal 模式下跳过因为 modal 编辑器自己管理可见性。6.1 工作区文件夹的顺序问题activeSessionobservable 的更新先于工作台工作区文件夹的更新。为避免把编辑器恢复进错误的工作区activeSessionForWorkingSet一个derivedObservableWithCache会扣住新会话直到工作区文件夹反映它的工作目录为止。6.2 切换时的保存 / 套用借助runOnChange(activeSessionForWorkingSet, ...)离开的会话untitled 跳过_saveWorkingSet把当前打开的编辑器快照为命名工作集session-working-set:resource该字符串在 baseSessionLayoutController.ts 中可查证。没有任何可见编辑器的会话不保存任何东西。编辑器部件的隐藏状态不在这里捕获会与切换 derive 竞争——它由[B2]部件可见性监听器在用户改变它的瞬间急切捕获且仅在单会话可见时多会话模式下编辑器区域是共享的其可见性不是按会话选择。进入的会话_applyWorkingSet恢复其保存的工作集或empty。所有套用都经由一个Sequencer串行化。当不在 modal 模式、工作集非空、且该会话没有把编辑器部件留在隐藏态时通过_revealEditorPartForWorkingSet在套用前后揭示编辑器部件——该揭示会抑制编辑器→辅助栏不变量D6让会话保存的辅助栏可见性被尊重。_editorPartHiddenBySession为true的会话在切换时保持编辑器隐藏经_shouldHideEditorPartOnApply单栏还会主动重新隐藏_hideEditorPartForWorkingSet当它被上一活动会话留在可见态时。当 provider 用 committed 资源替换活动未创建 draft 时draft 的编辑器隐藏态会先复制到 committed 资源再执行套用——避免单栏 detail-only submit 落到首次访问 created 会话默认 Editor-only的分支上。初始加载无上一会话时控制器只在该会话已有保存工作集时才套用它绝不套用empty——避免关闭正在被恢复的编辑器。初始恢复在工作集套用上使用suppressEditorPartAutoVisibility()且不揭示编辑器部件因此工作台恢复的任何可见性用户关过 Side Panel 则可能是隐藏在重载后都被保留。在单栏模式下由布局驱动的被管理 Changes/Files tab 打开被排除在自动编辑器揭示之外。会话头部的Changespill 属于显式用户打开它的 action 会先揭示编辑器部件、再打开被管理的 Changes 编辑器。Add Tab 这类被管理 tab 的添加动作也是显式 tab 添加手势它们传入活动组的末端 index让重新添加的 Changes/Files tab 落在已有 tab 之后而不是落在自动 Changes 的默认位置。6.3 清理CleanuponDidChangeSessions会为归档archived或删除deleted的会话移除工作集、按会话视图状态以及编辑器隐藏态。规范特别强调视图状态与编辑器部件可见性的移除必须在那个 handler 里显式做——_deleteWorkingSet只丢弃编辑器工作集。它绝不能顺带丢弃视图状态因为_deleteWorkingSet还会在每次切换离开 / 关停时从_saveWorkingSet被调用两者耦合会在某会话有编辑器但之后不再有时抹掉其保存的辅助栏可见性导致下次重载时辅助栏回落到默认可见逻辑D3d。7. 持久化存储键、迁移与写入时机会话布局的持久化严格遵守一套明确的存储键与时机契约经典布局按会话状态→ workspace 作用域键sessions.layoutState经IStorageService.onWillSaveState_saveState序列化目标为StorageTarget.MACHINE。实现文件 baseSessionLayoutController.ts 中以const SESSION_LAYOUT_STATE_KEY sessions.layoutState定义。_saveState捕获活动会话当前的视图状态、工作集与编辑器隐藏态跳过 untitled / 多会话情形为每个已知会话资源写一条ISessionLayoutEntry。经典布局的共享新会话视图状态D3b单独持久化在 workspace 键sessions.newSessionViewState下对象类型为INewSessionViewState在用户 toggle 新会话视图上的辅助栏时立即写入而不是关停时。_loadState读取sessions.newSessionViewState与sessions.layoutState若后者缺失执行一次性迁移从旧版键sessions.workingSets读入后移除它。损坏数据被防御性丢弃。单栏布局的编辑器工作集与按会话面板视图panelViewContainerId使用sessions.singlePane.layoutStateExisting Session 的 Editor/detail 配置档立即写入sessions.singlePane.sidePaneVisibility。单栏底部面板的可见性不是按会话状态——它与其它工作台部件一起持久化在工作台部件可见性键workbench.ts之下。8. 关键不变量把整套规范收敛成五句话无论是修改代码还是补回归测试规范期望以下不变量始终成立Observables不是 events驱动全部会话切换逻辑。多会话可见时禁用按会话的视图/面板同步并清空该状态工作集保留。工作集保存/套用要等待工作区文件夹跟上活动会话。经典桌面行为由 desktopSessionLayoutController.md 的规则D1–D11拥有移动行为由 mobileSessionLayoutController.md 的M1–M2拥有。单栏的可见性与 detail 选择由 SINGLE_PANE_SCENARIOS.md 以及各策略测试拥有——SinglePaneLayoutController与其 New / Existing / Quick Chat 策略、以及 singlePane 目录下的协调器如SinglePaneDetailPanelCoordinator、SinglePaneVisibilityProfileStore共同实现单栏特有的Editor 与详情面板共用一侧窗格的语义。9. 给工程师的实践建议如何用这份规范遇到行为回归先补测试而非改文档规范把每条规则都打上了B*/D*/M*标签代码与测试都按标签引用。修复某条既有规则的 bug 时正确落点是回归测试改文档LAYOUT_CONTROLLER.md及各文件级 spec只在状态机或持久化契约意图变更时才被允许。判断行为归属先查这条行为属于哪个控制器——平台无关机制看B*桌面辅助栏看D*手机版没有辅助栏逻辑MobileLayoutController故意不覆盖_registerViewStateManagement单栏策略则去 singlePane 目录看策略与协调器。排查状态没有按会话还原按本文第 4–6 节的恢复优先级逐层核对——辅助栏看 D3 的四级优先级、面板看 B1/B6 的互斥门控、编辑器看工作集是否在等待工作区文件夹、再确认是否处于多会话模式或编辑器最大化这两者都会挂起同步。排查关闭应用后布局丢失对照第 7 节的存储键逐一验证——经典布局查sessions.layoutState新会话共享状态查sessions.newSessionViewState单栏查sessions.singlePane.layoutState与sessions.singlePane.sidePaneVisibility并注意旧版sessions.workingSets的一次性迁移逻辑。若要进一步了解上游的布局拓扑哪些 part 归 Agents 窗口所有、单栏如何把辅助栏放进编辑器的 grid 节点可继续阅读 LAYOUT.md单栏状态机与迁移目录的完整说明见 SINGLE_PANE_SCENARIOS.md。【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考