VSCode启动参数是调试、隔离或绕过行为的底层控制手段，非新版功能开关；如--enable-profiler-ui启FPS监控与性能面板，--prof-startup与--trace-renderer生成启动性能日志，--no-sandbox与--remote-debugging-port启用远程调试，但Copilot CLI等内置功能无需参数。
VSCode 启动参数不是用来“测试新版功能”的开关，而是调试、隔离或绕过特定行为的底层控制手段；所谓“新版功能”得看具体指什么——如果是 1.118 版本刚发布的 Copilot CLI 或 Chronicle 历史追踪，它们默认启用，无需额外参数；但像帧率监控、启动性能分析这类隐藏能力，才真得靠命令行参数打开。
启用帧率监控和性能面板（--enable-profiler-ui）
这个参数能让你在编辑器右下角看到实时 FPS，开发者工具里也会多出 Performance 标签页，适合观察 UI 渲染是否卡顿。
- 必须先关闭所有 VSCode 实例，否则参数不生效
- 执行
code --enable-profiler-ui后，按Cmd+Shift+I（macOS）或Ctrl+Shift+I（Windows/Linux）打开开发者工具，切换到 Performance 面板 - 它不会自动记录，需手动点击录制按钮；停止后可查看主线程/渲染器线程耗时分布
- 注意：该参数仅影响当前实例，不改变设置，也不保存为默认行为
强制生成启动性能日志（--prof-startup --trace-renderer）
当你怀疑 VSCode 启动慢、卡在“Loading extensions...”或白屏时间长，这两个参数会生成可分析的 trace 文件，比肉眼观察靠谱得多。
-
--prof-startup记录从进程创建到窗口显示的全过程 -
--trace-renderer单独捕获渲染进程的详细事件（如 layout、paint、composite） - 日志默认输出到
${user-data-dir}/logs/下，文件名含时间戳，可用 Chrome 的chrome://tracing打开分析 - 组合使用更有效：
code --disable-extensions --prof-startup --trace-renderer，先排除扩展干扰再抓底层数据
绕过图形限制启用远程调试能力（--no-sandbox + --remote-debugging-port）
Copilot CLI 远程控制依赖 Chromium 的远程调试协议，但 VSCode 默认禁用该端口；想本地验证类似能力（比如用手机网页连上当前编辑器），需要显式放开。
-
code --no-sandbox --remote-debugging-port=9222启动后，访问http://localhost:9222就能看到可调试页面列表 -
--no-sandbox有安全风险，仅限可信环境临时使用，别设为默认启动项 - 该端口与 Chrome DevTools 兼容，但 VSCode 自身不提供 Web UI，你看到的是底层渲染器页面，不是编辑器界面
- Chronicle 本地历史追踪的数据不通过此端口暴露，它走的是 VSCode 内部 API，无法用这种方式“测试”
为什么不能用启动参数开启 Copilot CLI 或 TypeScript 7.0 支持？
这些是版本内置特性，不是运行时开关。1.118 已默认集成 Copilot CLI，只要登录账号、开启 Copilot 设置，copilot-cli 命令就能用；TypeScript 7.0 支持则取决于你项目里 typescript 包的版本和 tsconfig.json 中的 compilerOptions.target，和 code 命令无关。
最容易被忽略的一点：VSCode 不会把启动参数写进设置，也不会持久化。每次想复现，都得重新敲命令——别指望配置一次就一劳永逸。
