Sublime Text划词翻译不触发的根本原因是其不支持系统级划词事件监听，需插件通过on_selection_modified事件双重校验选区有效性，并延迟50ms读取以确保稳定性。
划词翻译功能在 Sublime Text 中为何总不触发
Sublime Text 本身不提供系统级划词事件监听，所谓“划词即译”实际依赖插件主动捕获 on_selection_modified 事件并判断当前是否处于有效选中文本状态。常见失效原因包括：用户未真正选中文字（仅光标定位）、选区为空、或插件未监听到视图焦点切换后的首次选中。
实操建议：
- 确保插件在
EventListener的on_selection_modified回调中加了if len(view.sel()) > 0 and not view.sel()[0].empty():双重校验 - 避免在
on_activated中直接触发翻译——此时选区可能尚未稳定，应延迟 50ms 再读取view.sel()[0] - 中文 Windows 下若使用 Ctrl+Shift+Right 等快捷键选词，Sublime 默认不会触发
on_selection_modified，需额外监听on_post_text_command并过滤move类命令
如何安全地并发调用多个翻译 API（如 DeepL + 百度 + 有道）
并发请求不是简单开多线程，Sublime 插件运行在主线程（Python 3.3+ 的 sublime_plugin 不支持 threading 阻塞），必须用 sublime.set_timeout_async 封装异步任务，并手动控制并发数与错误熔断。
实操建议：
- 用
concurrent.futures.ThreadPoolExecutor(max_workers=2)限制同时发起的请求数，避免被百度/有道限流返回429 Too Many Requests - 每个 API 调用必须设超时（
requests.get(..., timeout=8)），且捕获requests.exceptions.Timeout和requests.exceptions.ConnectionError - DeepL 的
text参数需 URL 编码，但有道要求原始 UTF-8 字节流 POST；百度 API 返回的trans_result是 list，DeepL 返回的是 dict —— 解析前务必先response.json()再判结构
中英文混合文本的划词边界识别为什么总切错
Sublime 的 view.word() 默认按空白和标点切分，对 “hello世界123” 这类字符串会返回整个区域，但用户真实意图可能是只选 “world” 或 “世界”。需要自定义分词逻辑，而非依赖内置方法。
实操建议：
- 用正则
r'[a-zA-Z]+|[\u4e00-\u9fff]+|\d+'对选区内容做粗粒度分块，再结合光标位置反向匹配最近一块 - 调用前检查选区首尾字符：若
text[0]是 ASCII 字母且text[-1]是中文，则大概率是跨语言误选，应自动收缩至首个连续字母段或汉字段 - 禁用
view.expand_to_scope('string')类自动扩展——它在注释或字符串内会污染上下文，导致翻译结果带引号或转义符
插件配置文件 Preferences.sublime-settings 如何正确加载多 API 密钥
Sublime 不允许插件直接读取项目根目录下的 .env，所有密钥必须显式写入 Package Control 管理的插件 settings 文件，且需预设默认空值防止启动报错。
实操建议：
- 在插件目录下新建
Translator.sublime-settings，内容含"baidu_app_id": "", "deepl_auth_key": ""等字段，确保 JSON 合法无注释 - 运行时用
sublime.load_settings('Translator.sublime-settings').get('deepl_auth_key', '')读取，绝不可用open()手动读文件——Sublime 会因沙箱策略拒绝访问 - 密钥明文存储风险高，建议在设置项中加提示：“如需加密，请配合
keyring库自行修改get_api_key()方法”——但不要内置，避免引入非标准依赖
划词解析和 API 联动本身不难，难的是在 Sublime 的事件模型约束下让每一步都可预测：选区是否真存在、API 是否已配好、响应是否来得及渲染——这些环节一旦漏掉校验，插件就会静默失败，连日志都不抛。别指望用户去看 Console，他们只会关掉插件。
