我平时打开VS Code的第一件事，不是写代码，而是先按下Ctrl+。很多人看到这个动作会觉得奇怪：写代码就写代码，终端不是单独开一个更方便吗？但恰恰是这个内置在编辑器里的终端，让我从VS Code 1.0时代一直用到了今天，而且越用越顺手。今天想聊的“终端中的 VS Code”，其实包含两层意思：一是在VS Code里面用集成终端干活，二是反过来，在终端里敲一条code`命令快速打开VS Code。不管你是刚装好VS Code的新手，还是已经用了几年的老用户，这篇文章都值得花五分钟看完，因为它讲的不是某个冷门功能，而是日常开发里最容易被忽略、却最能提升效率的那部分工作流。
1. 为什么要在VS Code里用终端：一个编辑器和命令行的“综合体”
1.1 集成终端的定位：一个编辑器里长出的命令行
我先说结论：VS Code内置终端本质上就是一个终端模拟器，它被嵌进了编辑器界面里，可以在Windows下跑PowerShell或cmd，在macOS和Linux下跑bash或zsh。但它的价值远不止“能敲命令”这么简单，它最重要的特点是和编辑器共享上下文。
你打开集成终端时，它默认会直接进入当前工作区的根目录，省去了cd到项目目录这一步。你在编辑器里打开了一个Python文件，终端里已经准备好运行脚本；你在写前端，终端里跑着npm run dev，编辑器里同步编辑代码。两边不会互相抢焦点，你不用在编辑器窗口和独立终端窗口之间来回切。这种“上下文不割裂”的体验，用习惯了之后很难再退回单独开终端的模式。
为什么很多人一开始不习惯集成终端？我观察到一个很现实的原因：大家最早接触终端是在系统自带的黑色窗口里，习惯把终端当作一个独立工具，而不是编辑器的一部分。但实际开发里，终端的作用是执行命令、编译、跑测试、看日志，这些动作和编辑代码本来就是紧紧绑在一起的。把终端放进编辑器里，实际上是把“写代码”和“跑代码”两条线合并到了一起，少了很多窗口切换的损耗。
1.2 它到底是怎么工作的：内置终端的技术原理
很多人以为集成终端只是把系统终端“嵌”在窗口里，其实实现上不是简单套壳。VS Code内置终端在Windows上基于Windows的终端API（conpty）和伪终端机制，在Linux和macOS上基于posix的ptty接口。它本质上是一个前端终端模拟器，负责把你敲的按键传给底层Shell，再把Shell返回的输出流渲染成界面上的文字。这套机制的好处是：你用的是系统完整的Shell环境，支持所有原生命令和工具，不会因为进了VS Code就缺胳膊少腿。
同时，因为渲染工作发生在VS Code内部，它还能额外做一些原生终端做不到的事。比如在输出里识别文件路径和行号，按下Ctrl+点击就能跳转到对应代码；再比如自动识别颜色，让编译器的日志带上正确的高亮。这些能力都不是“套壳终端”能做出来的，需要编辑器对输出流做二次解析。
还有一点非常重要：集成终端会继承VS Code启动时的环境变量。这意味着你在VS Code里配置过Python解释器路径、编译工具链、Node版本管理器，终端里通常也能直接用。反过来说，如果你在系统环境变量改了东西，VS Code不会立刻感知，需要彻底重启才能同步。这个点很多人不知道，后面第5章我会专门讲怎么排查。
1.3 什么场景适合用它，什么场景推荐外挂终端
集成终端不是万能的，我自己也会在几个场景下主动切回独立终端。
先说适合用集成终端的地方：日常开发里的命令操作，包括跑构建、跑测试、git操作、查看日志、执行临时脚本。这类操作往往是短时的、和当前工作区强相关的，用集成终端最顺手。像写Python、C++、嵌入式、前端这类需要频繁“编辑-编译-看报错”循环的场景，强烈建议全程用内置终端。
不太适合的情况也有：一是需要长时间挂着的交互式终端会话，比如通过SSH连到服务器做实时运维，这时候终端窗口不能随便关，VS Code的标签页太多反而容易误关；二是重度依赖终端复用器（比如tmux）的老手，他们在独立终端里保留了一整套多窗口会话体系，迁移成本较高。第三种是终端里要跑大量花哨的TUI界面（比如一些对话式工具、图表仪表盘），VS Code内置终端的渲染偶尔会出现刷新跟不上，体验不如专门的终端工具（比如Tabby这类第三方终端模拟器）。
所以我的建议不是非此即彼，而是把这俩当成互补：日常开发交给集成终端，长会话和特殊场景保留一个独立终端作为后备。
2. 快速上手：让内置终端更好用的几个基础配置
2.1 打开终端、切换Shell与设置默认Shell
打开集成终端最常用的快捷键是Ctrl+`（Windows和Linux）或Ctrl+`（macOS）。也可以从菜单View -> Terminal打开。终端打开之后，你会看到右上角有个下拉箭头，点开可以新建终端、拆分终端，或者选择不同的终端Profile。
这里要花点时间讲一下默认Shell配置，因为这是新手最容易卡住的地方。Windows下VS Code默认会选用系统配置的默认终端（通常是PowerShell），如果你装了WSL、Git Bash或者其他Shell，它们会出现在Profile列表里。你希望默认打开WSL还是PowerShell，可以在设置里搜terminal.integrated.defaultProfile.windows，然后在下拉框里选一个。macOS对应defaultProfile.osx，Linux对应defaultProfile.linux。
我个人的使用习惯是：Windows上日常用PowerShell，遇到WSL项目时单独开一个WSL Profile；macOS上默认zsh不动。不要小看这一步，很多“终端打开报错”“命令找不到”的问题，其实是默认Shell选错了路径导致的。
2.2 字体、字号、滚动回看：终端舒适度三件套
终端用起来舒不舒服，三个基础设置很关键：字号、字体和滚动回看行数。
字号设置搜terminal.integrated.fontSize，默认14，码农一般调到15或16，看日志不费眼。字体我推荐用等宽字体，比如Consolas、Menlo、JetBrains Mono，设置项是terminal.integrated.fontFamily。这里有个小细节：有些中文字体在终端里会让对齐出问题，如果发现表格和缩进对不齐，多半是字体回退到了中文字体，可以在字体家族里显式加上英文等宽字体，中英文混排会正常很多。
滚动回看（scrollback）是很多人忽略的参数，设置项是terminal.integrated.scrollback，默认是1000行，意思是你最多能往上看1000行输出。跑一次大型构建或者看一个持续输出的日志，1000行根本不够。我一般会改成5000或者10000，代价是稍微多吃点内存，但对于查历史报错来说非常值。实测下来，几万行的日志配合搜索功能，比直接翻系统日志文件省事多了。
2.3 多终端布局与快捷键
一个终端窗口很多时候不够用。前端项目里，你可能要同时跑一个开发服务器、一个接口服务、时不时再看一眼git状态。VS Code内置终端支持创建多个终端实例，并排或者上下分屏。
常用快捷键我整理一下：Ctrl+`切换终端面板开关；Ctrl+Shift+（反引号）新建终端；Ctrl+Shift+5拆分终端（也可以点击终端右上角的拆分图标）；Ctrl+PageUp/PageDown在多个终端标签之间切换。macOS上对应的是Cmd+系列，方向上一样。
后面我会专门讲多终端的进阶玩法，这里先记住一个点：每个终端标签可以单独设置名字和颜色。在终端标签上右键，选择“Rename”，把终端改成一个有意义的名字，比如“api-server”、“build-log”，这样终端一多也不会晕。这算是我最常安利给别人的一个细节操作。
3. 让终端和编辑器形成联动：几个被人忽略的高效操作
3.1 在终端里用code命令打开VS Code
聊完了编辑器里的终端，现在反向操作一下：在普通的系统终端里，怎么用一个命令直接打开VS Code？
这个功能的关键是VS Code安装时提供的code命令行工具。安装VS Code之后，在macOS上可以通过Cmd+Shift+P打开命令面板，搜索“Shell Command: Install 'code' command in PATH”执行一次，之后在任意终端里输入code .就能用VS Code打开当前目录。Windows下一般安装时自动勾选了PATH选项，如果没生效，可以手动把VS Code的安装目录加进系统PATH。
code命令最常用的几个参数我也分享下：
code . # 打开当前目录 code -r . # 在当前窗口打开，不新开窗口 code -n . # 强制启动新窗口 code file.txt # 打开指定文件 code -g package.json:10:20 # 定位到文件第10行第20列-g这个参数看报错日志时特别好用，比如编译器告诉你“line 12, column 4”，你可以直接跳到那个位置，比手动翻文件快得多。之前有人问“linux终端怎么换到上一行”，其实就是方向键↑调出历史命令，想迅速回到某个历史命令然后用Ctrl+R反向搜索，比一条一条翻要快。
3.2 在集成终端里快速执行当前文件
编辑器里的终端还有一层联动很多人没用上：在VS Code里打开一个脚本文件，右键选择“在终端中运行活动文件”（Run Active File），它会直接用对应的解释器执行当前文件。比如打开的是Python文件，它会调用当前选中的Python解释器；打开的是Node.js文件，它会调用node运行。
这个功能背后的原理是VS Code会根据文件关联和语言扩展，自动选择运行器。它的好处是连cd都省了，甚至不用管解释器的绝对路径，因为VS Code已经帮你把环境和文件匹配好了。
顺带提一个常见问题：如果发现右键没有“运行活动文件”，或者跳过定义（Go to Definition）不可用，大多数时候不是VS Code坏了，而是对应的语言服务扩展没有正确加载。先看右下角有没有提示加载中，再检查Language Server相关输出，如果加载失败，切换一下默认解释器版本往往能解决。
3.3 用Tasks把“命令”变成“工作流”
Tasks是很多人说不出口但特别核心的功能。你可以把一条或一组终端命令保存下来，下次直接按Ctrl+Shift+B运行，输出还会被问题匹配器解析，编译错误能直接跳转到代码位置。
举个最简单的例子，用VS Code配置C++编译：
{ "version": "2.0.0", "tasks": [ { "label": "build cpp", "type": "shell", "command": "g++", "args": ["-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.out"], "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"] } ] }保存为.vscode/tasks.json，按Ctrl+Shift+B就能编译当前C++文件。如果编译报错，问题面板里会列出错误行，点击就会跳转到源代码Position。嵌入式开发里配置STM32环境时也一样：把编译命令封装成一个Task，再把错误输出交给对应的problemMatcher，就能完全脱离命令行手动翻错的痛苦。
Tasks不仅可以编译，任何“重复执行的命令”都值得放进去：打包、跑测试、启动本地服务、清理临时文件。它本质上是在帮你把终端命令沉淀成项目级的工作流，团队新人也通过Tasks快速接手。
3.4 在WSL和远程开发中使用终端
越来越多的开发场景跑在WSL（Windows Subsystem for Linux）里，VS Code对WSL的支持属于“装个扩展就能用”的级别。装好Remote - WSL扩展后，你在VS Code里远程打开WSL里的代码目录，集成终端会自动变成WSL的bash环境，文件系统、运行环境完全一致，和本地开发没有区别。
这里有个值得注意的小点：在WSL中打开的VS Code，其实跑在X号进程上，但它依然可以调用VS Code的命令行工具code方便地打开窗口。如果代码在WSL里，本地Windows和WSL之间通过\wsl$路径访问，容易发生路径混用问题。我的建议是：凡是WSL项目，全程就用WSL窗口打开，不要切来切去。远程SSH（Remote - SSH）也是同理，登录到远端机器之后，终端就是远端Shell，本地终端只是中转。
4. 终端复用与多项目工作流：从“开一堆窗口”到“一个面板管理”
4.1 终端复用是干什么的：先理解再上手
“终端复用”这个词听起来有点玄，其实含义很直白：在一个终端窗口里管理多个会话，让你不用开满屏的终端窗口，也能并行跑多件事。Linux下经典的tmux就是这个用途，Web上也有Tabby这类第三方终端工具，本质上都是让终端会话更有序。
VS Code集成终端里的“复用”思路不太一样，它没有做完整的tmux式会话管理，但通过多终端实例、命名、颜色和分屏布局，可以达到接近的效果。我的经验是：不用过度追求技术名词，先把“多终端并行+命名分类”这套思维建立起来，效率已经能提升一截。
举个例子，之前在跑一个前后端分离的项目时，我的终端面板会长这样：
- 终端1（命名api，红色标签）：跑后端服务，比如
python manage.py runserver - 终端2（命名web，绿色标签）：跑前端
npm run dev - 终端3（命名db，蓝色标签）：跑数据库客户端或迁移命令
- 终端4（命名git，默认色）：偶尔看状态、提交
这四个终端都收拢在VS Code底部，我可以一眼看清所有进程状态，还能通过快捷键随时跳到任意一个。如果某次更新导致fbackend挂掉，报错直接就在终端里，我切过去就能处理，不用一遍遍点开系统任务管理器找进程。
4.2 VS Code里的多终端管理技巧
多终端实例的创建方式我上面提过，这里再细化几个非常实用的小技巧：
- 拆分方向和位置：点终端右上角的拆分按钮，可以选择左右拆分或上下拆分。从左到右的拆分适合同时看两组输出，上下拆分适合在空间紧张的窄面板里看日志。
- 命名终端变量：终端标签右键重命名，同时可以给终端设置一个颜色标签。颜色是区分多终端最直观的手段，比名字还显眼。
- 切换快捷键：
Ctrl+PageUp和Ctrl+PageDown在终端标签之间切换，Windows和Linux通用。macOS上是Cmd+PageUp/PageDown或触控板手势。 - 在多个终端之间复制粘贴：注意普通快捷键
Ctrl+C是复制，但在终端里它通常是中断信号，复制要选中文字后自动复制或用Ctrl+Shift+C。这个坑连老手都会偶尔踩。
还有一个很容易踩坑的点：关闭一个终端时，Ctrl+Shift+W或标签上的关闭按钮，会直接结束对应进程。如果你在跑一个重要的服务，手滑关了终端，进程就被杀掉了。我现在习惯了“先停服务再关终端”的顺序，哪怕多一步也觉得踏实。
4.3 用自动任务串联前端与后端
前面说Tasks能把命令变成工作流，这里我用一个真实的场景把它串起来。
假设一个全栈项目，后端需要uvicorn跑FastAPI，前端需要vite跑开发服务器。你可以建一个.vscode/tasks.json，定义两个后台任务：
{ "version": "2.0.0", "tasks": [ { "label": "start-backend", "type": "shell", "command": "uvicorn main:app --reload --port 8000", "isBackground": true }, { "label": "start-frontend", "type": "shell", "command": "npm run dev", "isBackground": true }, { "label": "start-all", "dependsOn": ["start-backend", "start-frontend"], "dependsOrder": "parallel" } ] }然后在终端面板里选中start-all运行，两个服务会同时在独立的终端里启动。这样你再也不用记住“先启动后端再启动前端”的顺序，一条命令搞定。配合终端面板的布局，前后端日志各占一块区域，肉眼很方便对比。
这套玩法适合所有需要跑多进程的项目，把它们固化下来之后，减少记忆成本，也降低了因为“少启动一个服务”导致的迷之问题。如果你平时有RPA、批处理或复杂脚本链，同样可以按这个思路拆解。
5. 常见报错与排查技巧实录
5.1 Windows下conpty启动失败与winpty残留问题
聊终端离不开报错。在Windows上，不少人都遇到过类似这样的报错：“终端进程启动失败: 启动期间发生本机异常(无法启动 conpty)。已移除 winpty。”这句报错一般意味着VS Code的终端后端（conpty）无法正常初始化，而老旧的winpty兼容层被移除后留下了残局。
这类问题的常见原因有几个：一是Windows的ConPTY功能失效，可能和系统补丁、终端服务、第三方远程桌面工具冲突有关；二是VS Code的配置被污染，settings.json里残留了一些旧的terminal.integrated配置；三是用户在安装或卸载其他终端工具时破坏过系统终端环境。
排查路径我建议按顺序试：
- 完全退出VS Code，再重新打开，很多时候临时性的conpty异常重启就好。
- 尝试在系统里单独打开PowerShell或cmd，确认系统终端本身可用。如果系统终端也不正常，说明不是VS Code的问题，是系统终端环境坏了。
- 打开
settings.json（命令面板搜索“Preferences: Open User Settings (JSON)”），检查是否有过时的terminal.integrated.windowsEnableConpty或winpty相关配置，有就删掉。 - 将VS Code更新到最新版，老版本的conpty实现可能会有已知问题。
- 最后再考虑安全软件或远程工具冲突，必要时把VS Code加入白名单。
顺带说一句，如果只是想临时绕过conpty问题，可以在设置里搜索terminal.integrated.windowsEnableConpty关掉，但这会影响现代终端的部分渲染能力，我不太推荐长期使用，它更适合作为一个判断手段。
5.2 终端突然闪退与默认Shell找不到
另一种常见情况是打开终端之后立刻闪退，或者显示错误：“The terminal process terminated with exit code: 1”。这个问题通常是默认Shell本身启动失败导致的。比如Windows上默认Shell设成了某种未安装的Profile，或者路径被改动过。
我先建议看一眼设置里terminal.integrated.defaultProfile.windows选的是哪一项。如果不确定，点开终端面板右侧的下拉箭头，手动切换一个Profile看能不能启动。如果能启动，说明之前的Profile有问题。Windows下最常见的坑是PowerShell执行策略限制，解决办法是把PowerShell的执行策略改为RemoteSigned或Unrestricted。macOS/Linux下则要留意zshrc或bashrc里是否有会提前退出的命令，比如误写了exit或有语法错误。
如果闪退发生在刚升级VS Code之后，可以试着清空终端的缓存状态，路径在VS Code设置里的“Terminal: Integrated: Cwd”有时也会导致启动目录异常。检查一下启动目录是不是一个被删除的位置。
5.3 中文乱码与编码不一致
“中文乱码”“编码不一致”是终端里一个永恒话题。出现乱码的根源是程序输出的字节流编码和终端渲染时的编码不一致。Windows默认很多程序输出GBK编码，而VS Code集成终端默认UTF-8，两边对不上就会花。
解决方案不外乎几种：
- 在PowerShell里手动执行
chcp 65001切换代码页到UTF-8，通常能让大部分程序输出正常。 - 设置环境变量强制Python输出UTF-8：
PYTHONIOENCODING=utf-8，在系统环境变量里配置即可。 - 如果只是某次临时查看日志，可以在终端里执行
type file.txt | Out-File -Encoding utf8把输出重新编码。
另外，VS Code本身对文件编码也有感知，打开文件时右下角会显示当前编码（比如UTF-8还是GBK）。如果读到中文乱码，可以点击右下角编码区域重新选择。这里多说一句：乱码问题与其反复转换，不如统一从源头控制，把项目的所有文件编码都定成UTF-8，终端的代码页也固定为UTF-8，能少掉90%的乱码烦恼。
5.4 终端与编辑器环境不一致问题排查
你可能会遇到一种很奇怪的现象：编辑器里Python解释器选对了版本，但是终端里python --version却显示另一个版本；或者VS Code里能正常编译，终端里却报“command not found”。这其实不是“VS Code坏了”，而是环境上下文不同导致的。
VS Code的Python扩展会记录一个解释器路径，它和系统PATH里的python可能是两回事。集成终端使用系统PATH和启动时的环境变量，如果终端里运行的python版本和扩展选的不一致，实际上是代码和命令跑在两个不同环境里。
排查思路很简单：先在VS Code里打开一个终端，敲python --version看一眼，再在编辑器状态栏或者命令面板里看Python解释器版本，两个对齐了就一致。如果不一致，可以用命令面板执行“Python: Select Interpreter”重新选择，或者直接把系统的环境变量PATH对齐。
还有个更隐蔽的情况：你修改了系统环境变量，但VS Code是修改前启动的，终端自然拿不到新值。遇到这种，通杀方案就是完全退出VS Code（包括托盘图标）再重新打开，不要只刷新窗口。
5.5 报错排查速查表
我把上面几个典型问题整理成一个速查表，方便遇到问题时快速定位。
| 现象 | 常见原因 | 首选排查手段 |
|---|---|---|
| conpty启动失败/winpty残留 | conpty后端异常，配置污染 | 重启VS Code，清理settings.json，更新版本 |
| 终端闪退/退出码1 | 默认Shell损坏或执行策略限制 | 手动切换Profile，关闭执行策略限制 |
| 中文乱码 | 输出编码与终端编码不一致 | chcp 65001，设置PYTHONIOENCODING=utf-8 |
| 解释器版本不一致 | 扩展解释器和系统PATH不同 | 重新选择解释器，重启VS Code |
| 命令找不到 | PATH未更新或默认Shell错误 | 检查PATH，确认默认Shell正确 |
这张表解决80%的终端入门问题，我自己也经常用它当备忘录。
6. 把AI编程助手接进终端：新式开发工作流
6.1 为什么AI编程助手越来越喜欢命令行
最近两年，AI编程工具从网页问答逐渐走向命令行。像Claude Code这类以CLI方式运行的AI编程助手，直接在终端里启动，在项目目录里分析代码、执行命令、修改文件。为什么AI编程助手偏爱终端？因为终端是最接近文件系统和Shell环境的入口，它可以直接读取项目结构、调用编译命令、运行测试，不需要人工把代码复制粘贴到网页里。
更重要的是，在终端里运行的AI助手可以和“用户执行命令”无缝衔接。你让它“帮我看看测试为什么挂了”，它能自己跑测试命令、读报错、提出修复。这个工作流天然适合放在VS Code集成终端里，因为你既能看到AI执行的每一步命令输出，又能随时手动干预，比纯粹的黑盒网页交互可控得多。
6.2 在VS Code集成终端中运行CLI助手
要在VS Code集成终端里运行这类CLI助手，前提是先确认运行时环境。绝大多数CLI助手依赖Node.js或者Python运行时，所以第一步是确认node --version和python --version能正常输出版本。
接着按官方说明安装对应的命令行工具，不同助手安装方式略有差异，但大致是两步：全局安装CLI包，然后在项目目录里启动。启动之后，CLI助手通常会要求做一次身份认证，认证之后就能读取当前项目文件、理解项目结构。它会自动获取当前工作目录，因此你最好先确定已经在正确的项目目录里再启动助手。
这里有一个很关键的权限问题：CLI助手会执行终端命令，所以你要给它明确的允许范围。一般它会询问是否允许运行某个命令或修改文件，有经验的开发者通常只允许它执行和当前项目强相关的东西，比如跑测试、编译、格式化。不建议一开始就放开所有权限，尤其是涉及敏感信息的操作。
6.3 组合工作流示例：助手执行命令并修bug
我描述一个典型场景，大家感受一下这套组合工作流的价值。
假设一个Python项目里有个接口测试一直报错，你不想自己逐行看堆栈。你先在集成终端里启动CLI助手，输入一句“接口测试挂了，帮我排查原因”。助手会先列出当前项目里的相关文件，自己定位到测试文件，然后执行一条命令跑测试，把报错输出读下来。它会发现是某个函数参数类型不一致导致的问题，给出修改建议，并询问是否直接改代码。你确认后，它直接编辑文件，然后再次运行测试，直到通过。
整个过程里，你只需要在VS Code的集成终端里观察它执行的每一条命令。它跑的是什么、改了什么文件、为什么失败，每一步都有记录。这就是“终端中的VS Code”这种模式进入新阶段的样子：终端不再是纯手工敲命令的地方，而是人和AI助手共同操作项目的交互台。
顺手说一下相关的热搜问题“Claude Code如何直接执行终端命令”：本质上就是这种CLI助手自带执行Shell命令的能力，你在对话里给出意图，它自己决定调用什么终端命令，输出经过解析后被它用来决策。这是一个相对新的模式，但底层依然建立在终端的“输入命令—读取输出”之上。
我用这种组合工作流一段时间后，最大的体会是：它并没有取代人，而是把“看报错—改代码—再跑”的循环缩短了。我第一次完整跑通“CLI助手+终端+编辑器”的闭环，是在一个大型旧项目里修测试，过去可能要看半天日志，现在几分钟就能定位到问题文件。当然，它也要求你对终端有基本掌控，至少知道它执行了哪些命令，否则出了问题可能更难收拾。
结尾
聊了这么多，其实我最想说的是：VS Code里的集成终端不是一个次要功能，它是把编辑器和命令行揉在一起的粘合剂。很多从“老派开发方式”走过来的朋友，总觉得终端就该黑底白字独占一个窗口，但我觉得，工具是为人服务的，效率优先。现在我所有开发命令几乎都收拢在VS Code集成终端里，加上Task、多终端、CLI助手这些配套，一个窗口搞定一切，那种感觉真的很爽。如果你还没试过在VS Code里正经跑一阵子终端，我建议你坚持一周，尽量把所有命令都放在那里面执行，几天后肯定会回来感谢这句话。
