ctrl+shift+l 光标错位因按换行符切分且无视中英文字符宽度差异；解决需统一utf-8编码、清理尾部空格、按home键对齐光标。
Ctrl+Shift+L 在中英文混排文件里为什么光标错位？
它只按换行符切分，不识别字符宽度差异。中文在 Sublime 里占两个字节显示宽度，ASCII 字符占一个，但 Ctrl+Shift+L 生成光标时完全无视这个——它只是把选区里每个 \n 前的位置原样标记为光标点。结果就是：同一列的中文和英文视觉上对不齐，光标却硬落在“字符数相同”的位置。
常见现象：
- 选中 5 行含中文的日志，按 Ctrl+Shift+L 后，所有光标看起来横向偏移
- 输入 //，有的行缩进被覆盖，有的行开头多出空格
- 解决办法：先用
Ctrl+Shift+P→ 输入Convert to UTF-8确保编码统一（GBK 文件极易触发错位） - 再运行
Trim Trailing White Space清掉每行末尾空格/制表符，避免光标落在不可见字符上 - 最后按
Home把所有光标拉到行首（不是点击，是按键），再开始编辑
正则匹配 + Alt+Enter 在混合文本中总漏掉某些行？
根本原因不是正则写错了，而是 Alt+Enter 只作用于当前「有效匹配项」——如果某行因编码问题、BOM 头或不可见控制字符导致正则引擎无法解析，它就直接跳过，不生成光标，后续所有光标索引会整体偏移。
典型场景：
- 日志里有 GET /api/user?id=123 HTTP/1.1 和 GET /api/user?id=中文 HTTP/1.1
- 正则 GET\s+([^"]+) 在 UTF-8 下能捕获前者，但在 GBK 文件里后者可能被截断成乱码，匹配失败
- 务必先确认文件编码：右下角状态栏看是否显示
UTF-8，不是就点它 →Reopen with Encoding→UTF-8 - 测试正则时，先点
Find All（不是Replace All），看左下角是否显示命中行数，与你预期一致 - 若仍有漏匹配，改用更宽松模式：
GET\s+([^\r\n]+)，避开双引号边界限制
Alt+拖拽列选择在中英文混排表格里为何视觉错位？
Sublime 的列选择是纯坐标定位，按屏幕字符列数算，不是按视觉对齐。中文字符在非等宽字体下实际渲染宽度≈2个 ASCII 字符，但编辑器仍按“1个字符”计数，拖拽时自然错位。
错误操作：
- 用系统默认字体（如微软雅黑）直接 Alt+拖拽 对齐 IP 地址列
- 结果：中文行光标落在第 10 列，英文行落在第 15 列，输入时彻底混乱
- 强制使用等宽字体：Preferences → Settings → 加入
"font_face": "Fira Code"或"Consolas" - 优先用正则重建结构：比如
^(\S+)\s+(\S+)\s+(\S+)→$1|$2|$3，把混排字段转成竖线分隔，再列编辑 - 实在要拖拽，先全选目标列区域 →
Ctrl+Shift+P→Align Columns（需安装插件），再Alt+拖拽
Ctrl+D 匹配中文变量名时频繁失效？
Ctrl+D 默认启用 match_whole_word: true，而中文没有单词边界（\b），所以它其实是在匹配“前后都是空白或行首/行尾”的字符串片段。一旦中文变量夹在括号、点号或标点里，就直接被过滤掉。
例如：
- 想改 用户信息.user_name 中的 用户信息，双击后按 Ctrl+D，下一个匹配可能是 用户信息：（冒号后有空格），但 用户信息. 就跳过了
- 临时关闭整词匹配：打开查找面板
Ctrl+H→ 取消勾选左下角\b图标（Word Boundary） - 或改用
Alt+F3全局匹配，它不依赖单词边界，但注意上限约 10000 处，超量静默丢弃 - 更稳的做法：先用正则
用户信息(?=[.\s]|$)精准锚定，Alt+Enter选中后再Ctrl+Shift+L拆光标
最易被忽略的是 drag_text 开关——只要没在用户设置里写 "drag_text": false，Ctrl+Click 在中文环境里大概率拖动文本而非加光标，这点在远程桌面或触控板上尤其致命。
