大文件多光标卡顿源于ctrl+d的增量扫描机制；应改用ctrl+shift+l全量匹配或正则替换，列选择模式因坐标级操作而高效，跨文件同步编辑需谨慎使用并关闭干扰扩展。
大文件里多光标卡顿不是插件问题，是 Ctrl+D 的增量扫描机制在拖慢你——换用 Ctrl+Shift+L 或正则预筛选能立竿见影。
Ctrl+D 在超大文件中为什么越按越卡
Ctrl+D 每次都从当前光标位置向后线性扫描，跳过字符串、注释、正则字面量里的匹配项，还要做语义合法性判断（比如不把 user 和 username 混在一起）。这个过程在 10MB+ 的日志或生成代码里会明显变慢，尤其当你连按 5 次以上时，VS Code 实际做了 5 轮独立扫描。
实操建议：
- 如果目标词明确且上下文干净（比如全是变量名），直接双击选中它，再按
Ctrl+Shift+L——它是一次性全量索引，不跳过、不判断，只匹配字面量，速度稳定 - 若必须用 Ctrl+D，按到第 3–4 次就停，用
Ctrl+U撤回误选，再手动Alt+Click补几个关键位置，比硬撑到卡死更省时间 - 禁用「Editor: Quick Suggestions」和「Suggest: Show Words From Other Documents」这类补全干扰项，它们会让 Ctrl+D 响应延迟更明显
列选择模式下删/输内容反而更快的真相
列选择（Shift+Alt+拖拽）本质是坐标级操作：VS Code 不解析文本，只按行列号生成光标。这意味着它完全绕过语法树、不触发任何语言服务，哪怕你在 5 万行 JSON 里框选第 3 列，响应也是毫秒级。
但要注意：
- 松手后光标落在每行的**绝对列号**上，如果某行该列是空格或制表符，
Delete会真删掉它——建议先Ctrl+Z留退路，或提前用Ctrl+H把混用的 tab 替换为统一空格 - 列选择状态下按
End不跳到行尾，而是停在矩形右边界；这说明你已脱离“行逻辑”，别指望方向键能智能避让缩进 - 想给多行开头加前缀？列选择起始列 + 输入比
Ctrl+Alt+↑更稳——后者依赖各行缩进对齐，一旦有 tab 和空格混用，光标就会错位
什么时候该切到正则替换，而不是硬刚多光标
多光标只管“在哪输”，不管“输什么”。一旦你要改结构（比如删前缀、加问号链式调用、补引号），它就开始漏改、误改、反复试错。
典型场景和对应解法：
- 把
data.user.name全改成user?.name：搜data\.(\w+\.\w+)，替为$1?.name——Ctrl+D只能删data.，但可能把data.items也删了 - 给所有未引号的 key 补单引号：
(\s+)([a-zA-Z_]\w*)(\s*:)→$1'$2'$3——多光标无法识别“前面是空格、后面是冒号”这个上下文 - 已存在多光标时开
Ctrl+H：默认仍作用于全文；如需只改光标范围，先鼠标选中那几行，再开替换面板——这是设计，不是 bug
跨文件同步编辑的真实代价
Ctrl+Shift+Alt+↑/↓ 看似酷炫，但它会在每个打开的编辑器标签页相同行列位置加光标。问题在于：VS Code 不校验这些位置是否可编辑（比如是只读文件、被锁的配置、或折叠区域），也不区分语言模式（JS 文件里输 const，CSS 文件里也会跟着输）。
所以：
- 只在 3–5 个高度同构的文件（如一组 React 组件模板）中启用，别用在 node_modules 或混合语言项目里
- 输之前先按
Esc清掉所有非目标光标，或用Ctrl+Shift+P→「Remove Secondary Cursors」快速清理 - 真正需要跨文件批量改结构时，用
Ctrl+Shift+H全局查找替换更安全——它支持文件类型过滤（files to include: *.ts）和正则上下文锚定
最常被忽略的一点：多光标性能瓶颈往往不在“加光标”动作本身，而在你加完之后又去调用格式化命令（比如 Prettier）、保存触发 ESLint、或切换输入法导致光标焦点丢失。关掉自动保存、暂停格式化扩展、用英文输入法操作，比换快捷键更有效。
