sublime text 没有 chaindownloader 配置项，它并非 package control 的合法配置键；实际需求是解决插件（如 emmet）依赖 pyv8 等二进制包下载失败的问题，需手动安装依赖或改用无需 js 引擎的替代方案。
Sublime Text 本身没有 ChainDownloader 这个内置功能或配置项——它不是 Package Control 的合法配置键，也不是任何官方文档、源码或插件生态中定义的机制。你看到的“ChainDownloader”大概率是混淆了术语，实际想解决的是：当某个插件（如 Emmet）因依赖 PyV8 下载失败而卡住时，如何让 Package Control “连带下载并安装依赖包”，或者“自动处理多级依赖链”。
为什么找不到 ChainDownloader 配置？
Package Control 的设计不支持运行时解析和递归下载第三方依赖。它只负责从 channel_v3.json 列表里拉取已打包好的插件 ZIP（即“单层分发”）。像 PyV8 这类二进制依赖，压根不在 channel 索引里，而是由插件作者在 __init__.py 中硬编码下载逻辑，再调用 Python 的 urllib 或系统命令去抓取——这一步完全脱离 Package Control 控制。
-
ChainDownloader不是 Package Control 的配置字段，加到Package Control.sublime-settings里会被忽略 - 搜索 Package Control 源码（v4.0+）或文档，查不到该关键词
- 部分老教程误将“多阶段下载行为”描述为“链式下载”，进而虚构出这个配置名
真正起作用的是 downloader_precedence 和后端选择
影响依赖能否下载成功的，是 Package Control 底层用哪个工具发 HTTP 请求。PyV8 失败常因 wininet（Windows 默认）不支持重定向或证书校验太严；换成 curl 就能绕过。
- macOS/Linux 用户优先设
"osx": ["curl", "urllib"]，确保curl在前 - Windows 用户若企业环境有代理，必须显式切换：
"downloader": "urllib"（wininet对代理支持差） -
curl能正确处理 302 跳转、自签名证书（加-k）、HTTP/2，而wininet容易静默失败 - 改完配置需重启 Sublime，否则不生效
Emmet 类插件的“依赖链”必须手动闭环
以 Emmet + PyV8 为例：Package Control 安装 Emmet 后，Emmet 自己会尝试加载 PyV8 模块；找不到就报 unable to download PyV8。这不是 Package Control 没下载，而是它根本没义务下——PyV8 不是插件，是独立二进制。
- 必须手动下载对应平台/Python 版本的
pyv8-win64-p3.zip等包（推荐 Gitee 镜像） - 解压后内容要放进
Packages/PyV8/（文件夹方式），且内部必须含__init__.py+pyv8.dll（Win）或pyv8.so（Linux） - 文件夹名严格为
PyV8（首字母大写，大小写敏感），放错位置或命名错误都会导致ImportError - ST3 用户别用标
p38的包——ST3 内置 Python 是 3.3，ABI 不兼容
更省事的替代路径：绕过依赖链本身
如果你只需要 Emmet 的 HTML/CSS 展开功能（95% 的使用场景），完全不需要 PyV8。现代方案更干净：
- 升级到 Sublime Text 4：原生弃用 PyV8，Emmet 2 直接跑在 JS 引擎上，无额外依赖
- ST3 用户可换用
Emmet 2（非官方但社区维护），它用纯 Python 实现核心语法，删掉了所有 JS 补全逻辑 - 禁用 Emmet 的 JS 功能（在
Emmet.sublime-settings里关掉"enable_javascript_snippets"），也能避免触发 PyV8 加载
真正的难点从来不在“怎么配一个不存在的 ChainDownloader”，而在于识别哪些失败是 Package Control 的责任，哪些是插件作者把依赖管理做进了运行时逻辑——后者只能手动补位，或换方案。
