QuickPick 选中后不触发回调，主因是用户取消导致返回 undefined，需显式判断；多选时返回数组而非字符串；匹配 description/detail 需手动启用对应选项；性能卡顿源于同步耗时操作，应提前缓存或分页；样式定制应使用官方 API 而非直接操作 DOM。
QuickPick 选中后不触发回调？检查 thenable 链和 undefined 返回
调用 window.showQuickPick 后，用户点了选项但你的 .then() 没执行，大概率是 QuickPick 被取消（比如按 Esc 或点空白处）——此时返回值为 undefined，而你没做判断就直接解构或调用方法，导致静默失败。
正确做法是显式检查返回值：
const result = await window.showQuickPick(items); if (result === undefined) return; // 用户取消，不继续 // 后续逻辑
另外注意：如果你用了 canSelectMany: true，返回的是 string[] | undefined，不是单个字符串，类型不匹配也会让后续逻辑出错。
多字段模糊搜索失效？开启 matchOnDescription 和 matchOnDetail
默认情况下，showQuickPick 只匹配 item 的 label 字段。如果你的 item 包含 description（如邮箱）或 detail（如提交次数），但用户输入关键词搜不到，是因为匹配未覆盖这些字段。
必须手动启用：
quickpick.matchOnDescription = truequickpick.matchOnDetail = true
这两个配置需在创建 QuickPick 实例后、调用 show() 前设置。常见错误是写在 showQuickPick(items, options) 的第二个参数里——该参数只接受有限字段（如 placeHolder, ignoreFocusOut），不支持 matchOnXxx。
QuickPick 性能卡顿？避免在 items 中做同步耗时操作
如果你的 items 数组是通过遍历大文件、解析 Git 日志或调用 fs.readFileSync 构建的，QuickPick 弹出前会明显卡住，因为整个数组必须在调用 showQuickPick 前就准备好。
优化方向：
- 把耗时操作提前到命令触发初期，缓存结果（比如存在闭包变量或
context.globalState中） - 对列表做分页或懒加载（例如先展示最近 50 个 contributor，加“加载更多”项）
- 用
async+Promise.resolve()包裹 item 构造逻辑，至少不让 UI 线程阻塞（但不能解决数据延迟问题）
VS Code 不支持原生异步 items，所以“边滚动边加载”的效果需自行模拟。
QuickPick 样式或行为异常？别直接改 DOM，用官方 API 控制
有人尝试用 document.querySelector 去改 QuickPick 的弹层样式，或监听键盘事件拦截回车——这不仅无效（QuickPick 是独立沙箱 UI），还可能被 VS Code 下个版本彻底禁用。
可控的定制点只有：
-
placeHolder：输入框提示文字 -
ignoreFocusOut：设为true可防止失焦关闭（慎用，影响 UX） -
canSelectMany：是否允许多选（返回数组） -
onDidAccept/onDidHide：事件钩子，比.then()更早响应
真正需要深度定制（比如带图标、分组、动态过滤）时，应考虑换用 QuickInput API，它比 showQuickPick 底层、灵活，但也更复杂——多数场景没必要跨这道坎。
