1. 项目概述
1.1 为什么我会盯上 t3code
先说个背景。我平时的工作流基本是编辑器重度依赖，每天开 VS Code 的时间比睡觉还长，各种插件、主题、快捷键肌肉记忆都长在编辑器里。前阵子翻开发者社区的时候偶然看到 t3code 这个项目名，第一反应是它跟 The T3 Stack（一款知名的全栈 TypeScript 技术栈）是不是有什么关系。仔细查了一圈之后发现，它其实是一款开源、无遥测、高度可扩展的代码编辑器，可以理解为 VS Code 的一个干净分支，又加入了针对现在前端/全栈开发痛点的原生优化。
t3code 的定位很直接：给不想被厂商生态绑定、又对性能敏感和隐私敏感的开发者，提供一个能直接用、能深度改、能长期养的编辑器底座。它解决的痛点也很具体——VS Code 本体携带了微软的遥测模块和账号体系，虽然能关，但总有点"底子不干净"的感觉；而大量衍生编辑器要么闭源，要么定制太浅，只换了个皮肤。t3code 直接把代码底座拿过来，去掉了遥测和账户依赖，然后内置了与 AI 辅助、跨设备同步、多语言调试相关的基础能力。
这篇文章适合谁看？首先是前端/全栈开发者，尤其是用 TypeScript 和 React 生态比较深的人；其次是有自己配置流派、想从零搭建个人编辑器体系的折腾型玩家；最后是想在受限网络环境或私有化环境里用开源编辑器的朋友。整篇文章不会只讲"它很好用"这种废话，而是把下载安装、配置结构、关键文件解析、常见坑排查都走一遍，尽量给到可以直接照抄的操作路径。
1.2 我对 t3code 的核心判断
一句话概括：它就是"去遥测 + 增强内建工具链"的 VS Code 深度分支。同类项目还有 VSCodium，但 t3code 在 VSCodium 的基础思路上往前多走了几步，主要区别体现在三点。
第一，默认内置了贴近 T3 生态的插件集，包括 Prisma 语法高亮、Tailwind CSS 智能提示、Next.js 相关工具链支持，理论上你克隆一个新项目之后不用额外花十分钟装插件，t3code 已经帮你预置好了。
第二，配置文件的结构更清晰，把用户设置、工作区设置、任务配置和调试配置分成独立模块，并且提供了命令面板的图形化配置入口，对新手来说比直接手写 JSON 友好一些。
第三，在同步和扩展管理上做了取舍。它默认把扩展安装目录和配置目录纳入同一套目录体系，方便你整体搬迁，也方便用 Git 做配置版本管理，这一点对多设备同步特别实用。
2. 安装与初始配置的完整链路
2.1 下载前需要知道的版本选择
先别急着下载。t3code 目前提供的主版本对应你常用的稳定系版本线，同时也有 Insiders 版本（类似 VS Code 的 Insider 版）供尝鲜使用。如果你是生产环境主力开发，老老实实选 Stable 版；如果你纯粹是想尝鲜、或者需要提前验证某个新特性，再考虑每天会更新好几版的 Insiders。
安装包方面，Windows 下有用户级安装和系统级安装两种模式，macOS 有 Intel（x64）和 Apple Silicon（arm64）两个包，别下错了。Linux 则提供 deb、rpm，也支持 tar.xz 绿色包的方式，方便在任意发行版上直接解压运行。我之前在 Ubuntu 22.04 上试过 tar.xz 方式，解压到 /opt 目录后做个软链到 /usr/local/bin，用起来跟官方安装一气呵成，没有任何依赖问题。
下载完之后，第一次启动时 t3code 会问你要不要导入现有 VS Code 的配置和扩展。这里给一个我当时的操作建议：如果你是想彻底干净地建立一套新体系，就选"不导入"，从零开始塑造自己的配置；如果你只是把它当作 VS Code 的换皮替代品，希望平迁无感，就选"导入"。这个选择决定了你后续配置文件的走向，两者没有对错，但中途反悔会比较麻烦。
2.2 核心设置项逐条说明
t3code 的设置入口在快捷键上跟 VS Code 保持一致：Windows/Linux 是 Ctrl+逗号，macOS 是 Cmd+逗号。它设置 JSON 的基座也是配置项文件，但默认多了一部分 t3code 自定义的项目专属配置头。
我建议你直接打开设置 JSON 面板（右上角图标按钮），然后人工往里面加以下几组通用配置。首先是最关键的字体渲染和行高：
"editor.fontFamily": "'JetBrains Mono', 'Cascadia Code', Consolas, monospace", "editor.fontSize": 14, "editor.lineHeight": 1.7, "editor.fontLigatures": true,这里的逻辑很简单：先给一个带连字的等宽字体优先级，实在找不到字体就回退到系统等宽字体。行高 1.7 是我个人比较适应的高度，如果你觉得行间距太松散，改成 1.5 也完全可以。然后是保存和格式化相关的习惯配置：
"editor.formatOnSave": true, "editor.formatOnPaste": false, "editor.tabSize": 2, "editor.insertSpaces": true, "editor.renderWhitespace": "selection",注意formatOnSave建议设为 true，前提是你已经装好了对应语言的格式化插件，否则每次保存都会弹错误提示，反而添乱。renderWhitespace我故意设成 selection，意思是只有选中的区域才显示空白字符，平时界面更干净，但排查缩进问题的时候一选中就能看到 Tab 还是空格。
还有一组是搜索和文件相关的行为配置：
"files.exclude": { "**/.git": true, "**/node_modules": true, "**/dist": true, "**/.next": true }, "search.exclude": { "**/node_modules": true, "**/dist": true }, "editor.minimap.enabled": false, "workbench.startupEditor": "none",我这里把 minimap 关掉了，因为对这个功能我一直无感，它占据的右侧空间在很多场景下就是纯视觉噪音。startupEditor设为 none 是让每次打开项目直接进入工作区，而不是先显示欢迎页。如果你喜欢欢迎页，可以留默认。
这些配置的意义不只是"调着好看"，而是把 t3code 的整套行为拉回到你真正高频使用的路径上。很多刚从 VS Code 迁移过来的用户，就是因为细节设置没同步，老觉得"哪哪都别扭"，其实只是没把骨子里的配置带走而已。
2.3 安装后的第一件事：验证扩展目录
装完 t3code 之后，我做的第一件事不是配主题，而是确认扩展根目录的位置。因为 t3code 的扩展安装目录默认跟 VS Code 分开，也就是说你原来在 VS Code 里装的一堆扩展，在这里不会自动出现。你可以通过命令面板（Ctrl+Shift+P）输入 "Extensions: Show Installed Extensions" 来看现有扩展列表，或者直接执行code --list-extensions的命令来输出所有已安装的扩展标识。
这个细节特别容易踩坑。很多人第一次打开 t3code，发现侧边栏扩展区空空荡荡，以为项目坏了，其实只是没搞清楚它用的是一套全新的扩展目录。解决办法也很简单，你把原来 VS Code 的扩展目录（Windows 下是%USERPROFILE%/.vscode/extensions，macOS/Linux 下是~/.vscode/extensions）里你真正常用的那十几二十个目录名复制出来，然后在 t3code 的扩展店搜名字一个个装就行。不建议直接软链整个目录，因为不同版本的 API 可能存在细微兼容问题，按需安装最稳。
3. 项目结构解析与定制方法
3.1 配置目录到底存了些什么
当你开始真正使用 t3code 后，它的配置目录会逐渐积累起一系列文件。以我当前的 Linux 工作机为例，整个配置路径是~/.config/t3code/User/，里面主要包含这些文件：
settings.json：用户级全局配置，也就是我们上面说的字体、缩进、主题等一切编辑器行为的配置；keybindings.json：快捷键自定义文件，你可以在这里覆盖默认快捷键；extensions.json：已安装扩展的识别清单，记录扩展标识和版本；globalStorage/：存放某些扩展的全局数据，比如数据库连接的会话缓存、登录态等；workspaceStorage/：不同工作区的独立存储，按工作区哈希拆分，每个文件夹对应一份子目录；snippets/：如果你创建过自定义代码片段，它们会集中存在这个目录下的.code-snippets文件里。
理解这个目录结构不是为了单纯看个热闹，它直接关系到两件事：备份和跨设备同步。我目前是把User/目录完全纳入 Git 仓库管理的，每调整一处配置就会 commit 一次，历史记录里能看到每一次变更。这样做的好处是，哪天把配置改崩了，直接git diff看变化，或者git revert回退到上一个能用的版本。这个习惯帮我挽回过不止一次因为误删配置导致编辑器行为异常的情况。
3.2 快捷键配置的实战套路
快捷键系统是编辑器的灵魂，t3code 继承了 VS Code 的 keybindings.json 结构，我们可以在里面用 JSON 格式覆写默认行为。这里分享一套我个人用得非常顺手的组合，你可以直接抄走，然后按自己的习惯做增删。
需求场景一：快速切换最近打开的项目。默认的Ctrl+R是切换工作区文件，而项目切换在 File > Open Recent 的菜单深处，太慢。我会在 keybindings.json 里写成：
{ "key": "ctrl+shift+t", "command": "workbench.action.openRecent" }把 Ctrl+Shift+T 从"重新打开已关闭的编辑器"改成最近项目列表。如果你觉得重开关闭的编辑器也是高頻操作，可以给它换个键，比如Alt+Shift+T，不然别动。
需求场景二：高频的移动光标到行首行尾。默认Home和End是行内跳转，但在某些键盘布局下不好按。我习惯用Ctrl+A和Ctrl+E（macOS 上也可以用）来映射到：
{ "key": "ctrl+a", "command": "cursorLineStart" }, { "key": "ctrl+e", "command": "cursorLineEnd" }这个映射方式很多从终端编辑器转过来的用户都会喜欢，因为它跟 shell 默认快捷键完全一致，手指不用重新学习。
需求场景三：格式化和快速保存绑定到同一个顺手的位置。我喜欢在键盘上顺手的位置完成保存，所以把Ctrl+S本身挪到了Ctrl+Alt+S（因为很多扩展会拦截 Ctrl+S 做特殊操作），同时让Ctrl+Shift+S触发格式化文档。
{ "key": "ctrl+alt+s", "command": "workbench.action.files.save" }, { "key": "ctrl+shift+s", "command": "editor.action.formatDocument" }自定义快捷键不是越古怪越好，核心原则是：把你每天重复最多的操作放到手不离键区的位置。我见到太多人配快捷键时贪多，结果配了 50 组键位，自己记不全，最后什么都得去看菜单。建议只配 5 到 10 个真正高频的动作，其余保持默认。
3.3 代码片段：让重复代码从指尖消失
除了修改编辑器行为，t3code 的代码片段（Snippets）能力也非常值得花时间打磨。它的语法与 VS Code 完全一致，支持$1、$2这种光标跳转占位符，还支持默认值、选择列表等。
对我写前端组件特别有用的一个例子是快速生成一个带注释的 React 函数组件骨架。我在snippets/react.code-snippets里写了这样一段：
{ "React Function Component": { "prefix": "rfc", "body": [ "import React from 'react';", "", "interface ${1:Props} {", " ${2}", "}", "", "export default function ${3:ComponentName}({ ${2} }: ${1:Props}) {", " return (", " <div>", " $0", " </div>", " );", "}", "" ], "description": "Create a typed React function component boilerplate" } }使用方式是输入rfc四个字符，编辑器联想出片段，回车后光标自动落在Props的位置，填完接口名按 Tab 跳到字段定义，再按 Tab 跳到组件名，然后把业务代码写到$0这个最后落点。整个过程不超过五秒，比从头敲一个组件框架快得多。
代码片段的价值在于把你的常用代码模式沉淀为可复用的手稿，尤其是团队协作时，统一的片段前缀意味着统一的代码骨架，间接减少了很多代码风格和结构的分歧。
4. 核心实操：构建一套可复制的开发工作流
4.1 用 t3code 初始化全栈项目
假设我们要用 t3code 从零搭一个基于 Next.js + Prisma + Tailwind CSS 的全栈项目。直接用自带终端（Ctrl+`）逐行执行命令：
npx create-next-app@latest my-app --typescript --tailwind --eslint cd my-app npm install prisma @prisma/client npx prisma init --datasource-provider sqlite npm install -D tailwindcss postcss autoprefixer npx tailwindcss init -p这里有个细节：create-next-app 在初始化的时候会询问是否启用 App Router、Src 目录等选项，建议生产环境项目直接选 App Router 和 Src 目录模式。App Router 是 Next.js 现在的推荐模式，服务端组件与客户端组件分离更清晰；Src 目录则让项目的根目录不堆太多配置文件。
接下来打开项目目录。这里推荐直接在 t3code 的命令面板执行File: Open Folder，选择 my-app 所在路径。t3code 会自动检测 package.json，并推荐安装它内置任务识别的相关工具。
然后写一个最基本的 Prisma 模型。在prisma/schema.prisma里定义数据模型：
model User { id String @id @default(cuid()) name String email String @unique createdAt DateTime @default(now()) }保存后，在 t3code 终端执行：
npx prisma migrate dev --name init这个命令除了生成迁移文件，还会触发@prisma/client重新生成，让 TypeScript 类型同步更新。t3code 对 Prisma schema 有原生高亮支持，所以写这个文件的过程是带语法高亮的，错误提示也会比较直观。
4.2 调试配置：让断点调试零启动成本
很多开发者吐槽"调试配置太麻烦"，其实是因为没有把 launch.json 的结构吃透。t3code 沿用 VS Code 的调试协议，对 Node.js/Chrome 调试有原生支持。下面给出一份能直接用的 launch.json，适用 Next.js 项目的客户端和服务端调试：
{ "version": "0.2.0", "configurations": [ { "type": "node", "request": "launch", "name": "Next.js: Debug Server", "runtimeExecutable": "npm", "runtimeArgs": ["run", "dev"], "console": "integratedTerminal", "serverReadyAction": { "pattern": "started server on .+, url: (https?://.+)", "uriFormat": "%s", "action": "debugWithChrome" } }, { "type": "chrome", "request": "launch", "name": "Next.js: Debug Chrome", "url": "http://localhost:3000", "webRoot": "${workspaceFolder}" } ] }第一段配置的作用是，按 F5 启动 t3code 内置的任务启动 npm run dev，然后监测终端输出里是否出现 "started server on ..." 的正则模式。一旦匹配到，就自动打开 Chrome/Edge 调试器，把断点挂到浏览器端。这比手动开两个调试器要顺滑太多。
如果遇到调试连接失败的情况，百分之九十是端口变了——Next.js 默认 3000，如果被占用会自动切到 3001。这时候改 URL 就行。另一个高频问题是 Chrome 调试需要你自己先装一个对应的调试扩展，t3code 默认可能没带，在扩展市场里搜 "Debugger for Chrome" 安装一下就好。
4.3 与 Git 工作流的整合
代码编辑器和版本控制的配合，决定了日常开发的顺畅度。t3code 内置了 Git 面板、行内变更提示、冲突编辑器，以及一个非常好用的时间线视图。
时间线视图藏在资源管理器的底部，它会按时间倒序列出当前文件的所有本地修改记录，包括每次保存的快照。如果你误改了一段代码但没提交，时间线还能翻回保存前的状态，这个功能在"我发现刚才手贱删了很多代码但是没存盘"的场景下简直是救命稻草。
另一个我每天都会用的操作是Git: Sync Changes。它的行为不是简单地 push，而是会先 pull rebase 再 push，尽量避免产生多余的 merge commit。如果你的团队也在用 Git 协作而且不排斥 rebase，这个命令很适合替代"先 pull 再 push"的两步操作。
当遇到合并冲突时，t3code 的冲突编辑器会以三栏方式显示：当前修改、传入修改、最终结果。你可以逐段选择"接受当前/接受传入/两个都接受"。这套交互比传统手改 <<<<<< 标记要直观太多。我的建议是：合并冲突时不要迷信任何一方的代码，先读懂两边的意图，再决定保留哪一段。
5. 常见问题与排查技巧实录
5.1 扩展装了但始终不生效
这是被问得最多的问题之一。现象：扩展商店里搜到了插件，点安装，进度条跑完，但使用时根本看不到效果，比如某个语法高亮没出现，或者某个命令不存在。
排查步骤先确认扩展确实装对了位置。打开命令面板执行Extensions: Show Installed Extensions，看列表里有没有目标扩展。如果能看到，再去看它的启用状态，有未启用（灰色）或禁用状态（带禁用图标）的说明被手动禁用或加载失败。
如果扩展确实在列表里且状态正常，但行为怪异，最常见的原因是扩展版本和你下载的 t3code 主版本不兼容。打个比方，某些扩展明确支持 VS Code 1.85+，而你的 t3code 如果基于较老版本线，加载时可能会报"扩展需要更高版本"的错。这时候要做的不是找替代品，而是把 t3code 升级到对应版本线，一般就能解决。
还有一种情况是工作区配置覆盖了扩展想要生效的设置。比如你装了 prettier 扩展，但工作区的 settings.json 里editor.formatOnSave: false，那保存时自然不会自动格式化。排查方法是点击Prettier扩展的设置页，把默认格式配置和用户设置对齐。
5.2 终端输出中文乱码的解法
在 Windows 上使用 t3code 内置终端时，偶尔会碰到中文乱码现象，本质是终端编码集与 Windows 控制台代码页不匹配。t3code 的终端默认支持 UTF-8，但某些 Windows 环境（尤其老系统代码页在 GBK 下）会出现乱码。
我的建议是把终端 profile 的编码参数显式设置成 UTF-8，方法是在 settings.json 中加入：
"terminal.integrated.profiles.windows": { "PowerShell": { "source": "PowerShell", "env": { "PYTHONIOENCODING": "utf-8", "LANG": "zh_CN.UTF-8" } } }这样即便是 Python 的 print 输出，也会被强制转成 UTF-8，乱码概率大大降低。如果这样还乱，检查一下操作系统本身的系统区域设置是否开了 Beta 版全球语言支持。这个选项在 Windows 10/11 的"区域设置"里，勾选"使用 Unicode UTF-8 提供全球语言支持"后，很多终端乱码问题会从根上消失。
5.3 性能卡顿的定位方法
编辑器用久了变卡是常见问题。t3code 本身经过轻量化裁剪，基础性能比原版 VS Code 还要轻快一些，但如果装了重量级插件，还是会卡。判断卡顿点要从三方面入手：扩展数、文件监听规模和渲染负载。
- 扩展数方面，进命令面板执行
Developer: Show Running Extensions，能看到每个扩展的 CPU 时间占比。哪个扩展排在耗时榜第一，大概率就是罪魁祸首。如果是某个很重的大型语言模型助手类插件，可以按需启用而不是默认开启。 - 文件监听方面，t3code 默认会对打开的工作区递归监听文件变化，如果你的 node_modules 也被监听，很容易造成 CPU 持续高占用。在 files.watcherExclude 里排除掉大型目录：
"files.watcherExclude": { "**/node_modules/**": true, "**/dist/**": true }- 渲染负载方面，如果你开了很复杂的自定义主题、大量装饰器或 minimap，视觉效果丰富的同时也会拖慢渲染。我习惯关闭 minimap、平滑滚动等功能来提升手感。
5.4 同步多台电脑配置的操作路径
前面我提到已经把User/目录纳入 Git，这里展开讲整个流程。首先把配置目录~/.config/t3code/User/初始化成一个 Git 仓库，然后按需忽略不需要同步的内容：
cd ~/.config/t3code/User/ git init echo "globalStorage/" > .gitignore echo "workspaceStorage/" >> .gitignore echo "logs/" >> .gitignore git add . git commit -m "init t3code config sync"globalStorage 和 workspaceStorage 是本地状态，不同机器上内容可能冲突，所以不纳入同步。扩展列表则要手动同步：在旧机器执行code --list-extensions，把输出保存到文件；新机器执行cat extensions.txt | xargs -L1 code --install-extension来一次性安装所有扩展。
这个方法有个明显优势：它不依赖厂商同步服务，完全是 Git 可控的，可以自由推送到你自己的私有远程仓库，也可以打包发给同事。如果你想更进一步，还可以用 GitHub Actions 在推送后自动做一遍配置校验或生成文档，不过这属于进阶玩法了。
我自己在实践这个方案的过程中踩到的坑是：两台机器的操作系统不同（比如一台 Arch Linux，一台 macOS），部分扩展只能在 Windows 或 Linux 上运行，所以扩展清单不要全量同步，推荐先对比一下平台差异再做精简。
5.5 设置同步后主题消失的真相
同步完配置后，很多人的第一反应是打开新机器发现主题没了，只剩默认浅色主题，然后以为同步失败。其实问题出在主题扩展还没装上。主题样式并不是编辑器内置的，而是由独立扩展提供的，比如比较火的冷门主题扩展、One Dark Pro、Dracula、Ayu 等等。你同步了 settings.json，确实包含了"workbench.colorTheme": "One Dark Pro"这个偏好设置，但如果新机器上没装 One Dark Pro 扩展，编辑器就只能回退到内置默认主题。
所以正确的同步姿势是：先安装扩展清单，再同步 settings.json；或者说，two 者必须同时完成。如果已经同步了配置文件但没装扩展，最简单的处置方法是在扩展市场里搜这个主题名，装好后主题会立刻自动应用回来。
这个坑也提醒我们，settings.json 里的很多配置都依赖实体扩展的存在。如果你的配置里写死了某些字体名，而在新机器上没装对应的字体包，也会出现字体回退。多设备同步这事，要严格遵循"先装扩展和字体，再灌配置"的顺序。
6. 进阶技巧与个人化实践
6.1 基于 Task 的自动化命令定制
t3code 的任务系统（Tasks）允许你把编译、测试、部署等命令固化成可一键触发的工作流，这在多步命令的情况下尤其有用。它的配置文件是工作区根目录下的.vscode/tasks.json。
举一个我实际使用的例子：我给一个前后端分离的仓库配置了一个组合任务，按一下快捷键就能依次完成开发服务器启动和测试监听：
{ "version": "2.0.0", "tasks": [ { "label": "dev: fullstack", "dependsOn": ["dev: server", "dev: client"], "dependsOrder": "parallel" }, { "label": "dev: server", "type": "shell", "command": "npm run dev --workspace=server", "isBackground": true, "problemMatcher": [] }, { "label": "dev: client", "type": "shell", "command": "npm run dev --workspace=client", "isBackground": true, "problemMatcher": [] } ] }注意isBackground设为 true 是因为 dev 服务器会一直挂起，不会自然退出，如果不标记为 background，任务系统会以为命令卡住了。dependsOrder设为 parallel 可以让两个服务并行启动，不用等一个完再开另一个，节省等待时间。
任务系统的价值不只是方便，更重要的是它把项目启动步骤固化下来，新人加入团队时不用翻 README 猜命令，直接运行任务即可。这也是 t3code 在团队协作场景下体现出的一个实用性亮点。
6.2 让用户片段与任务联动起来
如果你已经定义了一组项目级别的代码片段和任务，不妨把它们组合进快捷操作。比如我定义了一个任务叫 "Create Component"，它会读取一个剪贴板内容，然后自动生成组件的目录、文件和基础样式，接着用代码片段填内容。这种联动操作并不是 t3code 特有的能力，但它依赖 t3code 对任务系统和文件系统操作的高配合度，实际做下来体验很顺。
实现思路是：任务命令里调用一段 shell 脚本，脚本接受文件名参数，创建对应的目录和文件，文件名可以先在命令面板里输入，任务系统会把输入内容传给你定义的变量。这样从"我要写新组件"到"落地文件已生成"不超过十秒，比手动右键新建再逐个打 import 语句高效得多。
我个人建议每个工作流重度使用者在 t3code 上花一到两天时间，专门把平时重复最多的三五个操作固化成片段和任务，长期回报率极高。
6.3 双链笔记与代码库的融合
写代码的人一半时间在写文档。t3code 的 Markdown 编辑体验加上双链笔记能力，可以打造个人知识库和代码注解库。它的 Markdown 预览支持 Mermaid 图表（注意：我说的是编辑器内置的预览支持 Mermaid，不是让你在博文里用），齿轮图表也能链接到其他 Markdown 文件，实现类似知识库的双链效果。
我习惯在项目目录下维护一个 notes/ 文件夹，里面用 Markdown 记录开发周报、架构决策、踩坑日志等。因为它在同一个工作区里，所以可以直接引用项目代码文件路径做链接，也可以利用 t3code 的资源管理器快速定位。这种把文档和代码放在同一棵目录树里的模式，减少了上下文切换，让我写文档时不用跳出去开另一个笔记软件。
6.4 清理扩展：少即是多
说到进阶，不如聊一次"反向操作"。很多用户（包括以前的我）看到扩展就装，几乎不挑。结果编辑器越用越臃肿，启动速度越来越慢，菜单也被各种扩展塞得密密麻麻。后来我做了一次大扫除，把自己装的扩展从 60 个减到 20 个左右，只留下真正的刚需：
- 语言支持类：ESLint、Prettier、Tailwind CSS IntelliSense、Prisma
- 效率增强类：Path Intellisense、Error Lens、GitLens（或 GitLens 的轻量替代品）
- 辅助工具类：Live Server、Markdown All in One、Bracket Pair Colorizer 的替代方案
- 美观类：一个主题、一个图标主题
清理之后，最直接的体感是启动速度明显提升，Ctrl+Shift+P 命令面板的搜索列表也清爽了，因为不再有大量扩展塞进命令列表里。这里想分享一条心得：扩展不是越多越好，你真正高频用的功能其实就一双手数得过来。把扩展减到核心圈之后，t3code 的性能和可维护性都会上一个台阶。
7. 个人使用心得与建议
7.1 迁移到 t3code 的最佳时机
迁移时机这件事，我的建议是"趁项目不忙的时候做"。如果手头有大项目刚上线、每天都有一堆热修复要处理，这时候再去折腾编辑器迁移就是在给自己埋雷。但如果正处在两个阶段的间隙，或者刚开新项目、还没堆积历史包袱，那就是迁移的黄金窗口。
不要一次性全量迁移所有插件和配置。先搭一个最小可用环境，满足日常编码需求，然后在一周内边用边补充。这样既能保持生产力不中断，也能避免一次性搬运一堆用不上的扩展。
7.2 围绕编辑器搭建一套个人工作流
走完整个 t3code 的深度定制后，我的感受是它远比一个"换壳 VS Code"要值得深挖，当你在配置层面理解它、在任务和片段层面塑造它、在 Git 层面管理它之后，它实际上会演变成一套非常个人化的开发基础设施。
如果你本身已经习惯 VS Code 的快捷键与扩展生态，t3code 的学习成本几乎为零，你只需要花点时间适应它的配置目录结构和扩展管理方式。如果你是从零开始，这套编辑器的配置项也足够友好，给了你一个清晰的骨架去慢慢长出自己的配置。
整篇文章写到这里，如果你已经决定尝试，我最后再分享一个小小的技巧：第一次启动 t3code 后，先别急着装插件，花十分钟把设置 JSON 过一遍，理解每个高频配置项的含义——这个动作本身就是在为效率买单。配置是编辑器的一部分，理解配置才能掌握效率的主动权。
