pagedown/pageup默认不控制建议列表翻页，仅用于编辑器滚动；需用ctrl+pagedown/ctrl+pageup（macos用cmd+pagedown/up）且焦点必须在已展开的补全框内。
代码建议列表弹出后，按 PageDown / PageUp 为什么没反应？
VSCode 默认不把 PageDown 和 PageUp 绑定到建议列表翻页上——它们只对编辑器视图滚动生效，对 IntelliSense 弹窗无效。这是最常被误以为“快捷键坏了”的原因。
真正控制建议列表翻页的是：Ctrl+PageDown（下一页）和 Ctrl+PageUp（上一页），但前提是列表已展开且焦点在建议框内（即你刚按下 Ctrl+Space 或输入触发了补全）。
- 若列表未聚焦（比如你点了编辑器其他位置再按 Page 键），快捷键完全不生效
- macOS 用户需用
Cmd+PageDown/Cmd+PageUp，不是Fn+↓等模拟键 - 某些键盘无物理
PageUp/PageDown键（如 MacBook），必须通过Fn+↑/Fn+↓触发，且 VSCode 需识别为原生事件（部分外接键盘驱动会拦截）
选中建议时，Enter 和 Tab 的行为差异在哪？
Enter 插入当前高亮项并关闭列表；Tab 插入当前高亮项但保持列表打开，方便连续补全（比如链式调用 obj.method().prop）。
这个区别直接影响编码节奏：习惯狂按 Enter 的人容易打断补全流，而依赖 Tab 的人在多级属性访问时更顺滑。
-
Tab在有多个同名重载（如函数签名不同）时，还会自动跳转到下一个参数占位符 - 如果当前建议是 snippet（带占位符的模板），
Tab会进入第一个占位符；Enter则直接插入完整 snippet 并退出 - 自定义 keybinding 中若覆盖了
acceptSelectedSuggestion，可能意外禁用Tab的“保持打开”逻辑
如何让箭头键 + Enter 精准命中目标项，而不是被折叠/过滤干扰？
VSCode 的建议列表默认启用模糊匹配和动态过滤，输入过程中列表实时收缩，导致方向键移动位置偏移——你以为光标在第 3 行，实际高亮的是第 1 行的某子匹配项。
关键控制点在设置里：editor.suggest.showMethods、editor.suggest.showVariables 等开关影响可见项数量；而 editor.quickSuggestions 决定是否自动触发，间接影响初始列表完整性。
- 临时规避：按
Ctrl+Space强制唤出完整列表，再用方向键导航（此时过滤暂停） - 长期方案：关闭
editor.suggest.filterGracefully（设为false），让匹配更严格，减少“看似选中实则跳变” - 插件冲突常见于 Prettier 或 ESLint 扩展，它们可能监听
acceptSelectedSuggestion事件并提前消费掉Enter，导致插入失败
editor.suggestSelection 设为 first 还是 recentlyUsed 更可靠？
设为 first 每次都默认高亮第一项，适合确定性高的场景（如固定 API）；recentlyUsed 则按历史使用频率排序，对项目内高频词友好，但首次输入时仍 fallback 到字母序。
真正影响“精准选中”的其实是排序权重本身：VSCode 会合并语言服务返回的排序与本地缓存，而 TypeScript 语言服务器的 sortText 字段优先级高于 VSCode 自身逻辑。
- 若你常在同一个文件反复补全相同方法，
recentlyUsedByPrefix比recentlyUsed更准（它按前缀分组记忆） - 设为
first后，Enter总是插入首项，但如果你用方向键手动移动过，该设置就失效了——它只管初始高亮 - 某些扩展（如 Auto Import）会注入自己的 suggest provider，并强制覆盖排序，此时修改
editor.suggestSelection无效
Enter 按下，可能被 4 层事件监听器拦截或改写。调试时别只查 keybinding，先看 Developer: Toggle Developer Tools 里有没有 extension host 报错，再检查语言服务器日志。
