这个问题的核心是后续的Chrome启动请求没有被正确传递给已运行的Chrome实例，转而由系统默认浏览器（Edge）接管，常见原因和对应的解决办法如下：

可能的原因 #

• Chrome进程间通信（IPC）失败：当你第一次启动Chrome后，后续调用[system.Diagnostics.Process]::Start("chrome", "URL")时，Windows会尝试让已运行的Chrome实例打开新标签页。但如果Chrome实例还未完全初始化、进程间通信被安全软件拦截，或者存在权限问题，这个请求就会失败，系统会 fallback 到默认浏览器处理URL。
• Windows应用执行别名冲突：Edge可能设置了chrome.exe的应用执行别名，优先级高于真实的Chrome安装路径。虽然第一次调用成功找到了Chrome，但后续调用可能触发了这个别名规则，导致启动Edge。
• PATH环境变量解析问题：如果Chrome的安装路径仅存在于当前PowerShell会话的临时PATH中，后续调用时PATH被意外修改，系统找不到chrome.exe，就会用默认浏览器打开URL。

解决办法 #

1. 使用Chrome的完整路径调用 #

最可靠的方式是直接指定Chrome.exe的完整安装路径，避免系统解析错误：

# 替换为你实际的Chrome安装路径，32位系统可能在Program Files (x86)下
[system.Diagnostics.Process]::Start("C:\Program Files\Google\Chrome\Application\chrome.exe","http://some/path/1")
[system.Diagnostics.Process]::Start("C:\Program Files\Google\Chrome\Application\chrome.exe","http://some/path/2")
[system.Diagnostics.Process]::Start("C:\Program Files\Google\Chrome\Application\chrome.exe","http://some/path/3")

2. 修复Chrome的IPC处理能力 #

检查Chrome的设置：

• 打开Chrome，进入设置 -> 系统 -> 继续运行后台应用，确保这个选项是开启的，这样已有Chrome实例能正确响应新的URL请求。
• 关闭可能拦截Chrome进程通信的安全软件，或者添加Chrome到信任列表。

3. 调整Windows默认应用与别名设置 #

• 进入Windows设置应用 -> 默认应用，将Chrome设置为http/https协议的默认处理程序。
• 进入应用 -> 应用执行别名，找到Microsoft Edge对应的chrome.exe和chrome.exe别名选项，关闭它们，避免Edge劫持Chrome的启动请求。

4. 添加启动延迟 #

如果是因为Chrome未完全初始化导致的IPC失败，可以在脚本中添加短暂延迟，确保第一个Chrome实例启动完成后再执行后续调用：

[system.Diagnostics.Process]::Start("chrome","http://some/path/1")
Start-Sleep -Seconds 2 # 等待2秒让Chrome完全启动
[system.Diagnostics.Process]::Start("chrome","http://some/path/2")
Start-Sleep -Seconds 2
[system.Diagnostics.Process]::Start("chrome","http://some/path/3")

内容的提问来源于stack exchange，提问作者butterflyknife