Ubuntu 已安装 jekyll 时，Bundler 为何找不到 colorator？

结论

Bundler 负责解析和安装项目依赖，但不会自动隔离系统 Ruby、系统 gem 和用户安装的 gem。这里的错误表示，Bundler 安装 colorator-1.1.0 时，无法从当前使用的 gem 来源获取可安装文件。这并不能说明该版本在 RubyGems.org 上不存在，也不能说明系统目录中存在的 gem 一定能被当前 Bundler 使用。

Ubuntu 的 Jekyll 包与通过 gem 安装的 Jekyll、Bundler 同时存在，值得优先排查。卸载系统 Jekyll 后，教程步骤恢复正常；此前 Bundler 也提示本地 jekyll-4.3.2 的依赖元数据与远端版本不同。不过，这些现象还不能确定安装失败具体由路径、元数据还是版本交互引起。

为什么 Bundler 没有自动隔离

Bundler 根据项目的 Gemfile 和锁文件解析依赖，并将依赖安装到当前 RubyGems 环境配置的位置。它不是 Ruby 版本管理器或容器，也不会默认屏蔽操作系统提供的 Ruby 和 gem。

这里出现了几种可能来自不同来源的路径和版本：错误栈来自 /home/alan/gems/.../bundler-4.0.1，colorator 也出现在 /usr/share/rubygems-integration/all/gems/；系统 Jekyll 的版本是 4.3.2+dfsg-1，通过 gem 安装的 Jekyll 则是 4.4.1。这些信息说明环境中存在多种安装来源，但仅凭路径和版本，无法判断 Bundler 实际使用了哪份 gem 规格或安装配置。

日志还显示，本地 listen-3.9.0 和 jekyll-4.3.2 的依赖元数据与远端同版本的信息不同，因此 Bundler 忽略了这两个本地规格。这可能与不同来源的 gem 混用有关，但日志没有证明它们直接导致了 colorator 安装失败。

建议的排查与处理

先确认当前命令实际使用的 Ruby、gem 和 Bundler，以及 gem 搜索路径：

which ruby
ruby -v
which gem
gem env
which bundle
bundle -v
gem list jekyll bundler colorator

检查项目中的 Gemfile 和 Gemfile.lock，确认 Jekyll 与 colorator 的解析结果。然后查看当前 RubyGems 环境的安装目录和搜索路径，避免混用系统包目录、用户目录和其他 Ruby 环境。

较稳妥的做法是为项目使用独立的 Ruby 环境，例如通过 Ruby 版本管理器安装和管理 Ruby，再在该环境中安装 Bundler 和项目依赖。这样，系统 apt 包由系统管理，项目 gem 则由项目所用的 Ruby 环境管理。如果继续使用 Ubuntu 提供的 Ruby，尽量遵循该系统的 RubyGems 集成方式，避免在多个全局或用户级目录中安装同名 gem。

整理环境后，在项目目录重新运行：

bundle install

如果仍然失败，可根据 gem env 显示的目录、bundle config list 的配置和完整错误日志，继续确认 Bundler 从哪里查找和安装 gem。仅凭 colorator 目录存在，无法判断当前 Bundler 能否使用其中的包。

关于文档与注意事项

给出的材料只提到 Jekyll 文档建议避免以 root 用户安装 RubyGems 包，无法据此确认文档是否专门讨论了 apt 包与用户级或全局 gem 混用的情况。实践中，应明确由谁管理 Ruby 和 gem，并尽量让一个项目使用单一、隔离的 Ruby 环境，这样比依赖系统包与 RubyGems 包恰好兼容更容易排查问题。

备注：内容仅供参考。