Rails 6搭配webpacker处理数十万资源时编译速度极慢问题咨询

• 你对Rails资产路径的定位确实存在误解：app/assets/images/属于Rails资产管道（Sprockets）和webpacker默认的扫描处理目录，放入该目录的所有文件都会在服务启动、assets:precompile执行阶段被遍历，工具会自动为文件生成哈希戳、做格式校验、关联资源引用逻辑，75万张图片的全量扫描处理会直接把任务阻塞，这就是预编译跑一整夜、重启后页面加载耗时飙升的核心原因。
• 运行过程中拷贝资源无异常的原因是：服务启动完成后资产管道的全量扫描逻辑已经执行完毕，不会主动增量遍历目录下的新增未注册文件，因此不会触发额外负载，但只要服务重启就会重新执行全量扫描，问题必然复现。

• 把所有谷歌地图瓦片图整体移出资产目录，放到项目根目录的public/路径下，比如新建public/map_tiles/目录存放所有瓦片资源。该目录的资源会直接静态对外暴露，不会经过资产管道、webpacker的任何处理，访问路径直接对应域名/map_tiles/[子路径]/xxx.png，完全适配谷歌地图覆盖图的调用逻辑。
• 清理资产相关配置：如果之前手动配置过预编译包含瓦片图的规则直接删除，若用webpacker处理前端图片资源，在config/webpacker.yml中添加规则排除非业务静态资源的路径，避免webpacker做无效遍历。
• 不需要对瓦片图做任何重命名、目录结构调整，直接整文件夹迁移即可，后续执行rails assets:precompile只会处理业务相关的JS、CSS、少量业务图标，编译速度会恢复正常。

• 建议配置Nginx直接托管public/map_tiles目录，瓦片图的请求完全不经过Rails进程处理，静态资源响应性能会提升10倍以上。
• 如果瓦片图有版本更新需求，可以在public/map_tiles下按版本号建子目录，访问时带版本号路径即可避免用户浏览器缓存旧资源，不需要使用资产管道的哈希戳功能。

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