接入redux-wrapper的Next.js SSR页面访问MongoDB的相关问题

问题1：死代码消除未生效的原因 #

Next.js的死代码消除仅对静态可判定的分支+Next.js特殊标记的服务端专属函数生效。
你直接把MongoDB逻辑写在getServerSideProps里时，Next.js打包阶段会将整个getServerSideProps函数及其依赖完全从客户端bundle中剥离，因此不会触发依赖缺失报错。
但如果你把MongoDB相关导入写在Redux共享代码（action、reducer、store初始化文件）的顶层，哪怕你加了typeof window === 'undefined'的运行时判断，Webpack依赖解析阶段也会先将mongodb模块全量引入，再做后续死代码消除，此时客户端打包环境没有dns等Node原生模块，就会提前抛出依赖缺失错误。

问题2：使用redux-wrapper报错的原因&修复方案 #

普通Next.js项目中getServerSideProps是独立的服务端逻辑，和客户端代码完全隔离。但在with-redux-wrapper的架构下，你大概率是在getServerSideProps中调用了Redux的action来拉取MongoDB数据：

• 如果对应的action函数定义在客户端、服务端共享的Redux代码文件中，且文件顶层导入了mongodb，就会把服务端依赖带进客户端打包流程。

正确修复方案：

1. 完全解耦服务端数据查询逻辑和共享Redux代码：将MongoDB连接、查询逻辑封装在仅服务端调用的工具层（比如单独放在/lib/server/mongo.js路径下），不要在任何共享的Redux文件中导入该工具层
2. 在getServerSideProps中直接导入MongoDB工具层查询数据，再dispatch纯对象的普通Redux action把查询结果存入store，不要在Redux action内部执行MongoDB操作
3. 若必须在服务端专属的Redux逻辑中调用MongoDB，改用动态导入而非顶层导入：

if (typeof window === 'undefined') {
  const { MongoClient } = await import('mongodb')
  // 执行服务端逻辑
}

这种方式Webpack会将mongodb标记为服务端专属的动态依赖，不会打包进客户端bundle。

关于webpack注入空模块的hack说明 #

该方案在你能100%保证服务端依赖的代码永远不会在客户端执行的前提下是安全可用的，但存在明显缺陷：它相当于掩盖了依赖导入的问题，后续如果有代码改动不小心在客户端触发了相关逻辑，只会抛出运行时错误而非编译时报错，排查成本更高，不推荐作为长期解决方案。

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