技术博客
不是 Sublime 本身慢，而是 Package Control 默认从境外服务器（packagecontrol.io 和 github.com）拉取插件索引和源码，国内直连常出现超时、DNS 解析失败或连接重置——表现为命令面板里选中 Package Control: Install Package 后，界面一直显示 Loading…，几秒到几分钟都不出列表。
不装 CLI 工具、不运行 npm init -y 或 npx tailwindcss init，tailwind.config.js 就不会凭空出现。很多新手卡在“为什么 class 不生效”，实际是压根没这个配置文件。
低带宽下 composer install 卡住，本质是默认的并发数（2）和重试次数（3）不适合弱网——它会反复超时、阻塞、重连，反而拖慢整体进度。不是网络不行，是策略太“刚”。
因为默认行为会访问 packagist.org（或你配置的仓库）拉取包元数据、下载 ZIP 或通过 Git 克隆，同时还会校验 composer.lock 中记录的 dist URLs 和 commit hash。只要 DNS、HTTPS 连接或证书验证任一环节断开，就会报 Could not fetch、failed to open stream 或 SSL certificate problem。
不会自动清空，但行为取决于锁文件和依赖声明。只要 composer.lock 存在且没被删，composer update 默认只更新满足 composer.json 版本约束的包，并复用 lock 文件里记录的精确版本（除非你指定要升级某包）。真正“重装 vendor”的其实是 composer install 在没有 lock 文件时的行为——它会按 composer.json 解析最新兼容版本，结果反而更不可控。
因为默认每次运行都是干净容器，vendor/ 和 Composer 的全局缓存（~/.composer/cache）全丢。不手动干预，composer install 就得重新下载、解压、安装所有包，动辄 2–5 分钟。
不能直接下安装包就开干——Termux的PHP默认不带curl和json扩展，缺一个composer就卡在“Class not found”或“cURL extension is missing”。
很多人以为只要在 XML 里写上 schemaLocation，解析器就会自动联网下载或按路径读取 XSD 来校验——这是错的。schemaLocation 只是一个提示（hint），它本身不触发任何加载行为。是否使用、如何使用，完全取决于你用的解析器和它的配置方式。
不是插件的问题，是 Chrome 本身从 v110+ 起默认禁用了本地 file:// 协议下的 XML 解析样式表（XSLT）和部分解析逻辑。你双击打开一个 test.xml，看到的是纯文本甚至报错 XML Parsing Error: not well-formed，大概率是因为文件编码没被正确识别，或者 Chrome 根本没走 XML 解析器——它只是当普通文本渲染了。
它本质是个静态站点生成器，不是运行时服务。你跑一次 bin/satis build，它就扫一遍 composer.json 里写的包，拉代码、打标签、生成一堆 packages.json 和压缩包链接——然后就结束了。没有后台进程，不监听端口，也不自动更新。