作为现代开发者，把 Windows 系统老旧的蓝底 PowerShell 5.1 升级为跨平台、高性能的 PowerShell Core (pwsh 7.x) 是提升效率的第一步。
但是，当你满怀期待地打开 VS Code，准备享受极速的命令行体验时，大概率会被微软官方的 PowerShell 插件 坑得晕头转向。
本文记录了从老版本迁移到 pwsh 时必踩的“三大连环坑”，并给出了最优雅的终极解决方案。
💣 坑一：“喧宾夺主”的专属插件终端
你明明在 VS Code 的 settings.json 里把默认终端设置成了 pwsh，但每次打开项目，底部总会莫名其妙弹出一个名为 PowerShell Extension 的终端。
背后的真相：
VS Code 的标准集成终端和这个插件终端是完全物理隔离的。
官方的 PowerShell 插件为了提供 .ps1 脚本的断点调试和高级语法树分析，会在后台强行拉起一个专属于它的“特供沙盒终端”。它根本不关心你的默认设置是什么，开局就会强行抢占你的屏幕视野。
💣 坑二：极具误导性的“文字游戏” (找不到 pwsh 选项)
当你试图在插件的“会话菜单 (Show Session Menu)”里手动切换到新版 pwsh 时，你会绝望地发现列表里根本没有 pwsh 这个词。
背后的真相： 这是微软糟糕的命名逻辑导致的。在插件的认知里：
- 老古董 (5.1 版)：带有前缀，叫做
Windows PowerShell (x64)。 - 现代版 (7.x 版 pwsh)：去掉了 Windows 前缀，直接尊称为正统的
PowerShell (x64)。
所以，当菜单显示 Current session: PowerShell (x64) 时，它其实已经在使用你的新版 pwsh 引擎了，只是这个隐晦的名字欺骗了所有人。
💣 坑三：环境变量的“平行宇宙” (配置文件隔离)
最让人崩溃的是：你明明在系统里配好了 Anaconda、NVM 的环境变量，在自己新建的 pwsh 终端里运行完美，但一进那个插件专属终端，所有命令全部变成“未找到”。
背后的真相：宿主 (Host) 隔离机制。 PowerShell 会根据运行的外壳不同，读取不同的配置文件（Profile）：
- 普通终端读取：
Microsoft.PowerShell_profile.ps1 - 插件终端读取：
Microsoft.VSCode_profile.ps1
这意味着你的环境配置被强行分成了“两套房”，互不相通。
—
🛠️ 终极解决方案
面对这套极其混乱的设计，我们有两种极客级的解法：
方案 A：一劳永逸打通“平行宇宙” (全宿主统一)
如果你确实需要写复杂的 PowerShell 脚本，不能卸载插件，那么请启用上帝视角的配置文件：
- 在终端执行
notepad $PROFILE.CurrentUserAllHosts。 - 将你所有的环境变量（如 Python、Node.js 路径）写入这个全局文件。
- 清空那两个带前缀的旧文件。 从此，无论是普通终端还是插件终端，都会乖乖读取同一套环境变量。
方案 B：直接卸载/禁用插件 (强烈推荐前端与后端开发者)
如果你日常写的是 TypeScript、Node.js、Python 或 C++，仅仅是拿终端来跑 npm run、git 或者编译命令。
请果断在扩展面板中将官方的 PowerShell 插件“禁用”或“卸载”！
- 你会失去什么？ 几百行
.ps1脚本的代码补全和断点调试。 - 你将得到什么？ 一个极其清爽的 VS Code。按
Ctrl +弹出的将是纯粹、干净、极速启动的原生pwsh` 集成终端，再也没有任何插件来干预你的工作流。
总结： 工具是为开发者服务的，不要让庞杂的官方插件绑架了你纯粹的代码环境。清理掉不必要的包袱，你的代码世界会清爽得多。
Leave a comment