sublime text划词翻译插件失效主因是事件监听缺陷与api调用不当：on_selection_modified无法捕获快捷键选词等场景，须组合监听；并发请求需用sublime.set_timeout_async+threadpoolexecutor限流；中英文混合分词须正则粗分并定位光标；注释翻译应弃插件改用build system调外部命令。
没有稳定可用的“好用翻译插件”——Package Control 上所有主流划词翻译插件均已失效或不可靠，强行安装只会卡在空白面板或报 429/403 错误。
为什么 on_selection_modified 监听不到划词动作
Sublime Text 不暴露系统级划词事件，所谓“划词即译”全靠插件轮询 on_selection_modified。但这个事件在很多常见场景下根本不会触发：
- 用
Ctrl+Shift+Right快速选词（Windows 默认行为）→ Sublime 不发该事件，需额外监听on_post_text_command并过滤move类命令 - 刚切换到新视图时立即划词 →
on_activated中读取view.sel()总是空，必须用sublime.set_timeout延迟 50ms - 选区实际为空（仅光标定位）→ 必须双重校验：
len(view.sel()) > 0 and not view.sel()[0].empty()
并发调用多个翻译 API 的正确姿势
不能直接用 threading.Thread 或 asyncio，Sublime 插件运行在主线程，阻塞 = 编辑器卡死。必须用 sublime.set_timeout_async 封装异步任务，并手动控流：
- 用
concurrent.futures.ThreadPoolExecutor(max_workers=2)限制并发数，防百度/有道返回429 Too Many Requests - 每个请求必须设
timeout=8，并捕获requests.exceptions.Timeout和requests.exceptions.ConnectionError - DeepL 的
text参数要urllib.parse.quote编码；有道必须传原始 UTF-8 字节流；百度返回trans_result是 list，DeepL 返回的是 dict —— 解析前先response.json()再判结构
中英文混合文本分词总切错怎么办
view.word() 按空白和标点切分，对 "hello世界123" 这类串会返回整块，但用户真实意图可能是只译 “hello” 或 “世界”。必须放弃内置方法，改用正则粗分：
- 用
re.findall(r'[a-zA-Z]+|[\u4e00-\u9fff]+|\d+', text)得到语言块列表 - 结合
view.sel()[0].begin()光标位置，反向匹配最近一块作为目标词 - 若选区首字符是 ASCII 字母、末字符是中文（如
"func注释"），大概率是跨语言误选，应自动收缩至首个连续字母段或汉字段 - 禁用
view.expand_to_scope('string')—— 它在字符串或注释内会把引号、转义符一起吞进去，导致翻译结果带多余符号
想快速翻译代码注释，别碰插件
所谓“实时翻译注释”的插件（如旧版 SublimeText-Translate）本质是定时扫 comment scope 发请求，问题极多：
- 悬停就调用 → 几秒内触发服务端限流，后续全返回空
- 无法区分
// 单行和/* 多行块 */，常把整个函数体当注释翻译 - 遇到 emoji 或全角标点直接抛
UnicodeDecodeError - 用
urllib同步阻塞 → 编辑器假死
真正可行的路只有一条：用 Build System 接外部命令行工具。例如配一个 Translate.sublime-build，内容为：
{ "shell_cmd": "trans -brief -e google -s auto -t zh : '${selected_text}'", "selector": "comment" }——选中注释后按 Ctrl+B，快且稳。注意 ${selected_text} 是 Sublime 内置变量，不选中就为空，别指望它自动识别注释上下文。
