Sublime Text 4插件耗时操作必须异步处理，因TextCommand.run在主线程同步执行，直接调用阻塞操作会导致UI冻结；正确做法是子线程处理数据、用sublime.set_timeout回主线程安全更新视图。
Sublime Text 4 的插件不能在主线程长时间阻塞，否则 UI 会卡死——所有耗时操作（如文件读写、网络请求、正则全局匹配）必须异步处理，否则用户点击无响应是常态。
为什么 sublime_plugin.TextCommand.run 不能直接做耗时操作
Sublime 的命令执行上下文是同步的，run 方法在主线程调用，且必须快速返回。一旦你在里面调用 time.sleep(1)、requests.get() 或遍历超大文件，编辑器立刻冻结，连光标都不闪。
-
edit对象只在run执行期间有效，离开函数就失效，不能存到线程里再用 - UI 更新（比如状态栏提示、弹窗）只能在主线程触发，子线程里调用
sublime.status_message()会静默失败 - View 对象不是线程安全的，多线程并发读写同一
view可能引发崩溃或文本错乱
如何正确发起异步任务并安全更新视图
核心模式：启动子线程干活 → 用 sublime.set_timeout() 回主线程 → 在主线程里用 view.run_command() 或 view.replace() 修改内容。
- 不要在线程里直接调用
view.replace()或view.insert() - 把需要修改的数据（如替换范围、新文本）作为参数传回主线程，由
TextCommand再执行 - 示例片段：
import sublime
import sublime_plugin
import threading
<p>class AsyncSearchReplaceCommand(sublime_plugin.TextCommand):
def run(self, edit):</p><h1>启动后台线程，不阻塞 UI</h1><pre class='brush:php;toolbar:false;'> threading.Thread(target=self._do_search_and_replace, args=(self.view,)).start()
def _do_search_and_replace(self, view):
# 模拟耗时搜索（实际可能是 requests 或 re.findall）
import time; time.sleep(0.5)
regions = view.find_all(r'\bTODO\b')
# 准备好数据，交给主线程处理
sublime.set_timeout(lambda: self._apply_replacements(view, regions), 0)
def _apply_replacements(self, view, regions):
# 这里在主线程，可以安全使用 edit
edit = view.begin_edit()
for r in reversed(regions): # 从后往前，避免 offset 偏移
view.replace(edit, r, 'FIXME')
view.end_edit(edit)</pre>
sublime.set_timeout 和 sublime.set_timeout_async 怎么选
set_timeout 是主线程延迟回调，set_timeout_async 是异步线程池回调（Sublime 4 新增），二者用途截然不同。
立即学习“Python免费学习笔记（深入）”；
- 需要更新 UI（改状态栏、弹窗、改视图）→ 必须用
sublime.set_timeout(..., 0) - 只是想“稍后执行一段纯计算逻辑”，且不碰 View / edit / sublime API → 可用
sublime.set_timeout_async - 注意：
set_timeout_async的回调里依然不能调用view.replace()，它只是换了个线程池，不是主线程
插件中监听配置变更的可靠方式
用户可能随时改 Preferences.sublime-settings 或插件专属配置，但 load_settings('MyPlugin.sublime-settings') 返回的对象不会自动响应变更。
- 必须手动注册监听：
sublime.load_settings('MyPlugin.sublime-settings').add_on_change('my_plugin', callback) - 回调函数会在配置保存后触发，但仍在主线程，可安全调用
sublime.status_message() - 务必在插件卸载时调用
clear_on_change('my_plugin')，否则造成内存泄漏和重复触发 - 常见坑：在
__init__里监听，但插件类实例可能被 GC，导致回调找不到对象 → 推荐把回调定义为模块级函数
异步最难的不是写线程，而是厘清哪段代码必须在主线程、哪段可以放后台、以及数据怎么安全传递——漏掉任何一个 edit 生命周期或 view 线程约束，插件就会间歇性崩溃或静默失效。
