使用Next.js dynamic懒加载组件逻辑反而降低Lighthouse性能是什么原因？

• Context封装的额外开销：你实现的dynamicWithLoader为每个组件单独创建了React Context实例，还额外增加了Provider组件层级和动态组件包裹层。React在协调渲染阶段需要处理更多的组件实例、执行Context的消费/ Provider值比对逻辑，当你在大量组件上应用该逻辑时，这部分CPU开销会被放大，在移动弱设备上足以抵消包体积减小带来的收益。
• next/dynamic本身的运行时成本：即便设置了ssr: false且全程未触发逻辑包加载，next/dynamic内部仍然需要执行加载状态判断、loading组件渲染调度等内置逻辑，每个动态组件实例都会运行一遍这套逻辑，大量使用时累计的JS执行耗时会明显上升。
• 多余的组件层级与判断开销：额外增加的LoadToggle组件条件分支、多层props透传比对，也会增加每一轮渲染的计算成本，积少成多拖慢性能。

• 用Chrome DevTools的Performance面板分别录制两个版本的初始渲染过程，对比「脚本执行」阶段的耗时分布，重点查看是否有大量Context相关、dynamic组件相关的函数调用占用了过高比例的CPU时间。
• 暂时移除自定义的dynamicWithLoader封装，用最小实现的原生动态导入做对比测试，如果性能回升，即可判定是自定义封装的开销过大。
• 统计两个版本初始渲染阶段挂载的React组件总数量，确认懒加载版本是否存在组件实例数翻倍的情况。

1. 废弃当前的Context封装，砍掉不必要的组件层级和Context开销。
2. 不要用next/dynamic做条件触发的懒加载，改用手动控制原生import()的加载时机，初始阶段直接渲染纯标记组件，完全避免next/dynamic的内置运行时开销，示例实现如下：

// 优化后的组件入口
import { useEffect, useState, useRef } from 'react'
import PureMarkup from './PureMarkup'

export default function LazyInteractComponent(props) {
  const [Controller, setController] = useState(null)
  const loadTriggered = useRef(false)
  const { openPopin } = props

  useEffect(() => {
    // 仅满足触发条件时才加载交互逻辑
    if (openPopin && !loadTriggered.current) {
      loadTriggered.current = true
      import('./Controller').then(mod => setController(() => mod.default))
    }
  }, [openPopin])

  return Controller ? <Controller {...props} /> : <PureMarkup {...props} />
}

3. 只对单包体积超过3KB的重量级组件（如轮播、弹窗、富文本编辑器等）做交互逻辑拆分，轻量组件的拆分收益远抵不上额外的运行时开销。
4. 给纯标记组件添加React.memo缓存，避免不必要的重渲染，进一步降低性能开销。

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