求助：Rails无法检测文件变更，config.reload_classes_only_on_change致服务器过慢

这确实是Rails 5.2版本搭配Active Storage时的一个已知性能坑，算不上严格意义上的Bug，但确实会导致你遇到的服务器变慢、图片加载超时问题。

为什么会变慢？ #

当你把config.reload_classes_only_on_change = false打开时，Rails会在每一个请求都重新加载所有应用类——而Active Storage涉及大量文件IO、附件关联逻辑、以及和云存储/本地磁盘的交互类，这些类被反复重载时，再加上Vagrant共享文件夹本身的IO延迟，就会把请求耗时拉到10-40秒这么夸张。

这是Bug吗？ #

更准确地说，这是版本特定的性能兼容性问题。Rails 6.0及以后版本重构了类加载和自动重载机制，优化了Active Storage的加载逻辑，这个问题在新版本里已经被缓解了。

不用重启服务器检测文件变更的替代方案 #

给你几个实用的解决办法，按优先级排序：

• 用Spring Listen替代全局重载
  Spring是Rails默认的预加载工具，它的listen功能可以精准监听文件变更，只重载修改过的类，不会全局重新加载所有代码。
  启动方式很简单：

  spring listen
  rails s
  

  这样既不用修改reload_classes_only_on_change，也能实现文件变更自动重载，性能比全局禁用好太多。

• 优化Vagrant的文件同步方式
  Vagrant默认的共享文件夹IO性能很差，换成NFS或者rsync能大幅提升文件变更检测和读写速度。比如在你的Vagrantfile里配置NFS：

  config.vm.synced_folder ".", "/vagrant", type: "nfs", mount_options: ["rw", "vers=3", "tcp", "nolock"]
  

  配置后重启Vagrant，文件同步的延迟会显著降低，配合Rails的默认重载机制也能流畅工作。

• 开启开发缓存（谨慎使用）
  运行rails dev:cache可以开启开发环境的缓存，这会减少Active Storage的重复初始化开销，但代价是部分修改可能不会实时生效，需要手动清除缓存（再次运行rails dev:cache），适合对性能要求高但修改频率低的场景。

• 升级到Rails 6.0+
  如果项目允许的话，升级到Rails 6.0或更高版本是一劳永逸的办法——新版本的自动重载机制更高效，Active Storage也有专门的性能优化，全局禁用reload_classes_only_on_change的性能问题基本不会再出现。

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