崩溃由Unicode控制字符（如U+202E、U+FEFF）触发语法解析器无限循环或栈溢出，非语法未识别；可通过Show Scope Name确认，正则[\u2000-\u206F\uFEFF]定位，禁用highlight_line和draw_white_space临时规避，且不可忽略Default包。
高亮崩溃时右下角仍显示语法名，说明不是Plain Text问题
这种崩溃和语法未识别完全不同：文件右下角明明写着JavaScript或XML，但一滚动、一输入、甚至只是光标移入含特殊Unicode字符（如U+202E、U+FEFF、U+2060等零宽字符）的行，整个编辑器就卡死或闪退。这不是语法包没加载，而是Sublime内部语法解析器在遇到某些Unicode控制字符时触发了无限循环或栈溢出。
先用Developer: Show Scope Name确认是否真由Unicode触发
把光标停在疑似有问题的字符上（比如一个看不见的分隔符、从网页复制来的“智能引号”、或带BOM的段落开头），按Ctrl+Shift+P输入Developer: Show Scope Name回车。如果输出里出现invalid.illegal或长时间无响应，基本锁定是语法引擎被异常字符卡住。
- 常见诱因字符：
\u202E（RTL覆盖）、\uFEFF（BOM）、\u2060（Word Joiner）、\u00AD（Soft Hyphen） - 特别注意从PDF、微信、Notion复制过来的文本，极易混入这类字符
- 用正则
[\u2000-\u206F\uFEFF]全局搜索可快速定位（需开启regex模式）
禁用highlight_line和draw_white_space临时规避
这两个设置会让Sublime对每一行做额外渲染分析，恰好放大Unicode控制字符的副作用。在Preferences → Settings – User里加这两行：
"highlight_line": false, "draw_white_space": "none"
重启后观察是否还崩溃。如果稳定了，说明问题出在渲染层而非语法解析本身——此时可保留该配置，或改用"draw_white_space": "selection"折中。
ignored_packages里别禁用Default
很多人为了“提速”会把Default包加入ignored_packages，但这会导致Sublime跳过内置的Unicode安全过滤逻辑（比如对\u202E的自动转义处理）。检查你的用户设置里是否有：
"ignored_packages": ["Default", "Vintage"]
删掉"Default"，然后执行Ctrl+Shift+P → Reload Syntax Definitions。这是最常被忽略却最关键的一步——没有Default包，连基础的Unicode字符边界检测都失效。
真正难搞的不是字符本身，而是它们和语法高亮规则的交互方式：同一个\u202E，在JS里可能只让括号配对错乱，在XML里却直接让整个<tag>解析器挂掉。所以别指望一键修复，得先定位字符位置，再判断它落在哪条语法规则的敏感区。
