Ruby 3.0.3环境下未require 'date'可调用DateTime.now的原因排查

核心原因：依赖库间接加载了date标准库 #

Ruby的DateTime类属于date标准库，默认情况下不会自动加载。你的第一个项目能直接调用DateTime.now，必然是某个依赖库或其依赖链中的代码间接执行了require 'date'，导致该库被提前加载。

从Gemfile差异来看，第一个项目中的aws-sdk-s3及其依赖（如aws-sdk-core）是最可能的触发源：AWS SDK在处理签名、时间戳等逻辑时需要日期处理能力，因此会主动加载date库；而新项目中的gqli及其依赖无此类需求，所以不会自动加载该库。

统一Gemfile后问题仍存在的可能原因 #

即使Gemfile内容一致，以下情况也会导致两个项目的行为差异：

• 依赖版本差异：Gemfile.lock中的依赖版本不同，比如aws-sdk-s3或其依赖（如aws-sdk-core）的旧版本会加载date，新版本则不会；
• 加载顺序/初始化逻辑差异：
  1. 项目启动代码不同：第一个项目可能通过Bundler.require(:default)加载了所有默认组的依赖，而新项目可能只加载了部分组，或加载时机更晚，导致调用DateTime.now时date库还未被加载；
  2. 初始化脚本差异：第一个项目的config/boot.rb或其他启动文件中，提前加载了某个间接依赖date的库；
• 环境配置差异：两个项目的.bundle/config、RUBYOPT环境变量等配置不同，影响了依赖加载行为。

排查步骤 #

1. 追踪date库的加载源
   在第一个项目的入口文件（如启动脚本）开头添加以下代码，运行后即可看到触发date加载的具体文件和调用栈：

   TracePoint.new(:require) do |tp|
     if tp.path.include?('date')
       puts "=== date库被加载 ==="
       puts "触发文件: #{tp.path}"
       puts "调用栈:\n#{tp.caller_locations.map(&:to_s).join("\n")}"
     end
   end.enable
   

2. 对比Gemfile.lock
   直接对比两个项目的Gemfile.lock，重点查看aws-sdk-s3、aws-sdk-core及其依赖的版本差异；
3. 检查启动逻辑
   对比两个项目的启动代码，确认Bundler.require的调用方式、加载的组是否一致，是否有提前加载其他依赖的逻辑。

总结 #

这类问题本质是第三方依赖的隐式加载行为导致的差异，而非Ruby版本或Docker环境的问题。如果需要确保新项目也能无需手动require使用DateTime，建议在项目入口处主动添加require 'date'，避免依赖第三方库的不确定行为。

内容的提问来源于stack exchange，提问作者joyfuljoy