Sublime多行光标本身不致内存溢出，但叠加大量光标后执行正则替换、全量查找或跨行编辑极易引发PCRE回溯或渲染卡死；根本原因是Ctrl+Shift+L依赖选区是否含换行符，末行未选中\n会导致光标坍缩至第一行末尾。
Sublime 多行光标本身不会直接触发内存溢出，但它是高危操作链的起点——一旦叠加大量光标后执行正则替换、全量查找或跨行编辑，就极易引爆 PCRE 回溯或渲染线程卡死。这不是配置调得不够，而是操作路径踩进了引擎设计的雷区。
为什么 Ctrl+Shift+L 后一输内容就只出现在第一行
根本原因不是光标“消失”，而是光标早已坍缩：Ctrl+Shift+L 生成多光标依赖选区是否包含换行符。最后一行没选中 \n，它就当单行处理，所有光标堆在第一行末尾。
- 鼠标拖选时，必须把光标拖到行尾换行符位置（哪怕看不见，多拖一格）
- 列编辑更可靠：
Ctrl+Alt+↑/↓锁定列位置，缩进不一致也不影响 - 双击词后按
Ctrl+D匹配，比拖选更可控；想跳过某处，按Ctrl+K再按Ctrl+D -
drag_text默认开启会劫持Ctrl+Click，必须在用户设置里加"drag_text": false并完全重启 Sublime
大文件里多光标 + 正则 = 崩溃，怎么绕开
大于 5MB 的文件，只要开启 . matches newline 或用 .* 类模式，PCRE 引擎就会指数级回溯，内存瞬间飙到 2GB+。调大 large_file_size 没用，它只控制“能否打开”，不干预正则执行。
- 先用
Ctrl+Shift+F（Find in Files）定位目标行，Where填具体路径如src/ -node_modules/，禁用. matches newline - 点
Find All→Copy All，粘贴到新标签页——你只处理几百行，不是整个大文件 - 在新页用
Ctrl+H安全替换；确认后手动复制回原位置，或用插件SideBarEnhancements的 “Replace in Files” 分批写入 - 绝对禁用这些正则：
^.*$、"[^"]*"、{.*?}、含(?s)且搭配.*的组合
百万行选中就卡死？不是内存问题，是渲染在作怪
崩溃主因是 gutter（行号区）和 line_numbers 开启状态下，Sublime 为每行生成 DOM 节点并尝试渲染高亮、折叠按钮、断点图标——尤其 GitGutter 或 BracketHighlighter 插件还会立刻扫描整段选区做 diff 或括号匹配。
- 选中前务必先按
Ctrl+Shift+P输入Set Syntax: Plain Text回车，停掉语法解析器 - 临时关闭 gutter：
Ctrl+Shift+P→Preferences: Settings – Syntax Specific，加"gutter": false, "line_numbers": false - 别等卡死再救——鼠标拖选前先切语法、关 gutter，这是硬性前置动作
真正危险的从来不是光标数量，而是光标叠加后触发的后续操作。Esc 是唯一能立即清空辅助光标的操作，但更关键的是：别等它失效了才想起验证——只要做过方向键移动、输入、Tab 切换或 Alt+Tab 切出，就该默认光标已不可信。
