部署生产版本时next/image致Heroku崩溃，免费版正常求排查

核心原因推测 #

付费dyno的严格资源限制和免费dyno的宽松/弹性调度差异，加上next/image本地图片优化的内存消耗，导致生产版触发OOM崩溃。

可能的差异点 #

• 资源限制执行强度不同
  Heroku免费dyno的内存限制（标称512M）实际执行宽松，短时间内存溢出时不会立即终止进程；而付费dyno会严格执行阈值，一旦内存占用触达512M就直接Kill进程。免费版处理图片时可能也超过了剩余内存，但Heroku没触发崩溃，付费版则严格执行规则。
• CPU调度与并发效率差异
  免费dyno CPU调度优先级低、速度慢，图片优化（CPU密集型）的处理节奏慢，内存释放能跟上；付费dyno CPU性能更强，图片优化进程速度更快，内存瞬间冲高超过剩余阈值（512M-280M=232M）。
• 缓存状态差异
  免费版长期运行，next/image的优化结果已缓存到Redis，无需重复处理；生产版是全新环境，没有缓存，首次请求需要批量优化图片，内存占用叠加后溢出。
• 配置/依赖差异
  检查生产版next.config.js：是否关闭了images.unoptimized（免费版可能误开启跳过优化）、images.domains/remotePatterns是否包含更多需要优化的图片源，导致处理量更大；另外付费版的JawsDb/Redis客户端可能加载了额外依赖，占用更多启动内存，留给图片优化的剩余空间不足。
• 请求触发的优化逻辑差异
  浏览器请求会附带Accept头（支持WebP等格式），next/image会额外生成多格式图片，内存消耗更高；而免费版测试时可能用curl（无对应头）只生成原图格式，内存消耗低。生产版用curl请求图片崩溃，可能是图片本身尺寸过大，单张优化就耗尽剩余内存。

排查建议 #

• 临时在next.config.js中设置images: { unoptimized: true }，跳过本地优化，测试是否还崩溃，验证问题根源。
• 通过Heroku日志查看崩溃前的内存变化：在代码中添加console.log(process.memoryUsage())打印图片优化前后的内存数据，或用heroku logs --tail实时监控。
• 对比免费版和生产版的next.config.js、package-lock.json，确保配置和依赖版本完全一致。
• 测试单张极小尺寸图片的请求，看是否崩溃，判断是单图优化内存不足还是多图并发导致。

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